date:20240221

On Wednesday, February 21, 2024 at 6:50:52 PM UTC-5 Peter Fletcher wrote:

There were essentially no issues with the 4.x->5.x update. What I wasn't
prepared for was an update *from 5.01 to 5.02* clobbering everything *that
was previously working in 5.01*. I don't think that it is reasonable to
expect the user to carefully (re-)read all the documentation before
doing/allowing a 'second decimal place' update.

peter, it would be helpful if you could describe a bit more about your
configuration.

are you running with hardware that required separate installation (e.g.,
sdr) or hardware drivers or kernel modules?

are you running multiple instances of weewd?

are your reports all within a single directory tree, or are they scattered?

did you implement the various report locations using symlinks, or is it all
explicitly declared within your weewx config file?

did you have any issues with weewx integration to a local web server? if
so, how did you configure that?

do you have ssh or other configurations for remote access that were
affected by the permissions changes? where are those located, and how are
they used?

i'm working on a handful of adjustments to the deb/rpm packaging that will
hopefully avoid some of the issues you ran into. so description of systems
that are more extensive than just 'apt install' are very helpful. in
hindsight, we probably should have done the root-to-weewx change in the
5.0.0 release, not a dot-dot. it was not until 5.0 went out that we
realized how many *more* issues there would be if some people end up with
weewx running as root while others run unprivileged.

apologies for the disruption it caused.

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/e6900174-65a8-40da-9b3d-b31fc5ed9686n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

I understand what you are saying. However, all the discussion that I read 
was about the change from V4.x to V5.x. I was very careful when I did that 
update, created a total system backup first, and was fully prepared to sort 
out issues. I have, in any event, been using systemd for many things, 
including weewx, for a very long time. There were essentially no issues 
with the 4.x->5.x update. What I wasn't prepared for was an update *from 
5.01 to 5.02* clobbering everything *that was previously working in 5.01*. 
I don't think that it is reasonable to expect the user to carefully 
(re-)read all the documentation before doing/allowing a 'second decimal 
place' update.

I have used the wee_xyz utilities so rarely, that I would need to look up 
how to do anything with them, anyway. I would expect to do the same with 
weectl.

My existing installation includes a number of custom skins and custom 
services. There would be *much* more than copying over the db involved in 
the ''clean install' approach, though I did think of doing that after 
everything fell apart.

On Wednesday, February 21, 2024 at 5:52:14 PM UTC-5 vince wrote:

> FWIW - you 'could' have remained on your old version basically forever if 
> you were so inclined.
>
> But to reply
>
> On Wednesday, February 21, 2024 at 2:18:49 PM UTC-8 Peter Fletcher wrote:
>
> That was one of the *many* permissions-related problems caused by the 
> update! Changing the registered user of a complex program that reads and 
> writes many files in many places, without making sure that the user knows 
> the consequences 
>
>
> Disagree.  Documented many many times and places from changelog to the 
> upgrade guide to FAQ and dozens of threads here over almost a year of 
> alpha/beta/release-candidate changes and improvements that resulted from 
> that testing.   The docs were totally redone and enhanced and are now very 
> easily searchable.  Same for the wiki.  Same for the FAQ. 
>
> The switch to running unprivileged is also implementing a decade+ design 
> goal to move away from running as root to the longstanding industry best 
> practice of running as a non-privileged user.  That in itself makes it 
> worth the pain to remove that legacy risk.
>  
> And what does the user need to learn new ?  Two things.  Use of systemd 
> for startup (the os's essentially force this) and the replacement of 
> wee_xyz utilities with an integrated weectl utility (very very well 
> documented for almost a year now).
>
> And where does the user have to possibly salt to taste ?  Two places.   
> Access to serial/usb ports and privs to write to their webserver document 
> root.  Just like every other unprivileged app that does either.
>
> ... the new registered user didn't have access to the serial port. 
>
>
> Hmmm - the user has to properly configure their os to let the 
> non-privileged user access the peripherals.  This is surprisingly difficult 
> given almost infinite variability of the possible os configurations and the 
> variety of devices that connect to those systems.  But the logs clearly say 
> permission denied when this happens and the how to fix it is very very well 
> documented for many months.
>
> Run debug=1.  See permission denied.  Search the forums/docs/wiki/faq for 
> folks who have been there before and what they did.
>
>  
>
> The crt problem was as you said and was the second one to surface after 
> the first had been fixed. Subsequent to fixing that, I had to correct the 
> access rights to the folders corresponding to a number of 'sites' that my 
> copy of weewx creates.
>
>
> Yes - the onus is on the user to integrate their weather station software 
> with their user-configured webserver.  That has always been their job.
>
> FWIW:
>
>- a clean new installation of v5 works right out of the box on 
>debian(ish) os and a raspi (which is debian-based) with no edits required
>- if you are on a pi specifically, the default 'pi' user gets access 
>to serial/usb from the default os for free so no work is required there
>- running the packaged variant frequently requires 'one time' work to 
>salt to taste, so to speak.  Weewx is no different than any other app in 
>this respect.
>
>  Again - this is a major upgrade that is 'optional' although recommended. 
>  In itself making the switch to running unprivileged is reason enough to 
> work a little 'once'.
>
> Or save your db, do a clean installation of v5, copy your db into place, 
> and start it up.  It will almost certainly work.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9ad0e558-d790-426e-a803-428e0fdccafan%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

2024-02-21 Thread vince

FWIW - you 'could' have remained on your old version basically forever if
you were so inclined.

But to reply

On Wednesday, February 21, 2024 at 2:18:49 PM UTC-8 Peter Fletcher wrote:

That was one of the *many* permissions-related problems caused by the
update! Changing the registered user of a complex program that reads and
writes many files in many places, without making sure that the user knows
the consequences

Disagree. Documented many many times and places from changelog to the
upgrade guide to FAQ and dozens of threads here over almost a year of
alpha/beta/release-candidate changes and improvements that resulted from
that testing. The docs were totally redone and enhanced and are now very
easily searchable. Same for the wiki. Same for the FAQ.

The switch to running unprivileged is also implementing a decade+ design
goal to move away from running as root to the longstanding industry best
practice of running as a non-privileged user. That in itself makes it
worth the pain to remove that legacy risk.

And what does the user need to learn new ? Two things. Use of systemd for
startup (the os's essentially force this) and the replacement of wee_xyz
utilities with an integrated weectl utility (very very well documented for
almost a year now).

And where does the user have to possibly salt to taste ? Two places.
Access to serial/usb ports and privs to write to their webserver document
root. Just like every other unprivileged app that does either.

... the new registered user didn't have access to the serial port.

Hmmm - the user has to properly configure their os to let the
non-privileged user access the peripherals. This is surprisingly difficult
given almost infinite variability of the possible os configurations and the
variety of devices that connect to those systems. But the logs clearly say
permission denied when this happens and the how to fix it is very very well
documented for many months.

Run debug=1. See permission denied. Search the forums/docs/wiki/faq for
folks who have been there before and what they did.

The crt problem was as you said and was the second one to surface after the
first had been fixed. Subsequent to fixing that, I had to correct the
access rights to the folders corresponding to a number of 'sites' that my
copy of weewx creates.

Yes - the onus is on the user to integrate their weather station software
with their user-configured webserver. That has always been their job.

FWIW:

- a clean new installation of v5 works right out of the box on
debian(ish) os and a raspi (which is debian-based) with no edits required
- if you are on a pi specifically, the default 'pi' user gets access to
serial/usb from the default os for free so no work is required there
- running the packaged variant frequently requires 'one time' work to
salt to taste, so to speak. Weewx is no different than any other app in
this respect.

Again - this is a major upgrade that is 'optional' although recommended.
In itself making the switch to running unprivileged is reason enough to
work a little 'once'.

Or save your db, do a clean installation of v5, copy your db into place,
and start it up. It will almost certainly work.

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/59e332d3-dd94-4d3c-bdd1-84b4b3e42b74n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

That was one of the *many* permissions-related problems caused by the 
update! Changing the registered user of a complex program that reads and 
writes many files in many places, without making sure that the user knows 
the consequences of and necessary fixes for this makes changing horses in 
midstream look like a reasonable and appropriate thing to do! The first 
problem was that the new registered user didn't have access to the serial 
port. The crt problem was as you said and was the second one to surface 
after the first had been fixed. Subsequent to fixing that, I had to correct 
the access rights to the folders corresponding to a number of 'sites' that 
my copy of weewx creates.

Life was made substantially more difficult because my ISP has just changed 
how it manages FTP connections, and there are problems with the new 
implementation, so when things went wrong with the FTP-uploaded sites I 
originally blamed them on the ISP's FTP issues.

The crt extension puts its output in a subfolder of /var/www/html, whence 
weewx FTPs it to a different site (not one hosted by my regular ISP).

I was using V 0.21 of crt, but have now updated to V 0.23.

On Wednesday, February 21, 2024 at 4:02:39 PM UTC-5 matthew wall wrote:

> On Wednesday, February 21, 2024 at 3:54:31 PM UTC-5 Peter Fletcher wrote:
>
> It turns out that there were some other privilege problems, resulting from 
> the 5.02 update, but I managed to get journalctl to show me the detailed 
> error logs, which it apparently keeps, and /var/log/messages apparently 
> doesn't. The previous crt exceptions were, indeed, in journalctl's logs and 
> they allowed me to identify and fix the rest. I think that everything is 
> now really sorted, but a nominally minor utility update, liable to be 
> included in a routine apt full-upgrade, should not create this big a mess!
>
>
> peter,
>
> based on the logs you found, is this what happened:
>
> - crt extension could not write to the file it wanted to write to
> - when it tried to report the problem, the crt extension died, because the 
> 'traceback' function it tried to call no longer exists
>
> where does your crt extension put its output?
>
> have you updated to the latest crt extension?  (v0.23)
>
> m 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/476c457a-da65-4e59-921e-0f1746221f56n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

On Wednesday, February 21, 2024 at 3:54:31 PM UTC-5 Peter Fletcher wrote:

It turns out that there were some other privilege problems, resulting from 
the 5.02 update, but I managed to get journalctl to show me the detailed 
error logs, which it apparently keeps, and /var/log/messages apparently 
doesn't. The previous crt exceptions were, indeed, in journalctl's logs and 
they allowed me to identify and fix the rest. I think that everything is 
now really sorted, but a nominally minor utility update, liable to be 
included in a routine apt full-upgrade, should not create this big a mess!


peter,

based on the logs you found, is this what happened:

- crt extension could not write to the file it wanted to write to
- when it tried to report the problem, the crt extension died, because the 
'traceback' function it tried to call no longer exists

where does your crt extension put its output?

have you updated to the latest crt extension?  (v0.23)

m 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7c320776-a3e1-4225-9bf4-33eb6e9c3770n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

It turns out that there were some other privilege problems, resulting from 
the 5.02 update, but I managed to get journalctl to show me the detailed 
error logs, which it apparently keeps, and /var/log/messages apparently 
doesn't. The previous crt exceptions were, indeed, in journalctl's logs and 
they allowed me to identify and fix the rest. I think that everything is 
now really sorted, but a nominally minor utility update, liable to be 
included in a routine apt full-upgrade, should not create this big a mess!

On Wednesday, February 21, 2024 at 1:47:30 PM UTC-5 Peter Fletcher wrote:

> I'm blessed if I know why the log doesn't show anything about the crashes. 
> The crash information I showed earlier was actually from systemctl status, 
> after the second crash occurred (the first one reported the serial port 
> access failure). I cannot find a way to get the same detail in the history 
> from journalctl, and the log I am giving you is from running:
> sudo grep weewxd /var/log/messages >weewx0.log
> This may omit important detail lines, if they don't contain the string: 
> 'weewxd'
>
>
> On Wednesday, February 21, 2024 at 10:33:11 AM UTC-5 Tom Keffer wrote:
>
>> Glad it's working for you, but why were there log entries of the crt 
>> exception the first time, but not the last? 
>>
>> If a thread is exiting without telling us why, that's a bug. Looking 
>> through the crt code, the write to the disk is protected by an exception 
>> clause, so it should have caught the permissions error and logged it.
>>
>>
>>
>> On Tue, Feb 20, 2024 at 7:21 PM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> That is the entire log from shortly before the update. I am guessing 
>>> that the known bug in crt.py results in the crash not being properly 
>>> reported.
>>>
>>> The good news is that I was able to figure out what was going on. I am 
>>> using crt to produce a file that allows the display of current weather 
>>> conditions on my HOA's website. It is written to a subfolder of its own in 
>>> /var/www/html and uploaded to the HOA site from there by weewx. Again, it 
>>> was the change from weewx running as root to it running as weewx that was 
>>> causing an access privilege error. Simply deleting the old version of the 
>>> file did not solve the problem, but assigning ownership of the relevant 
>>> *subfolder* to weewx:weewx restored normal functionality.
>>> On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:
>>>
 That's the end of the log? Where is the crt error?

 The record timestamped 2024-02-20 20:30:00 was downloaded from the 
 logger at 20:32:22. I would expect the next record to be processed at 
 20:35:16 or so. Did you terminate the program? Is there something later in 
 the log?

 On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
 weewx...@googlegroups.com> wrote:

> Here is the log from before I applied the apt update, through now. 
> This includes one reboot. The last  start was after setting debug=1 in 
> the 
> config file. I hope that it helps you more than it does me!:
>
> Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
> Generated 7 files for report SeasonsReport in 2.52 seconds
> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
> Generated 16 images for report SeasonsReport in 1.47 seconds
> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: 
> Copied 0 files to /var/www/html/weewx
> Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
> Generated 8 files for report PublicReport in 2.19 seconds
> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
> Generated 16 images for report PublicReport in 1.39 seconds
> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: 
> Copied 0 files to /var/www/html/weewx2
> Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
> ftpgenerator: Ftp'd 1 files in 0.75 seconds
> Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine: 
> ftpgenerator: Ftp'd 22 files in 10.12 seconds
> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
> record 2024-02-20 18:25:00 EST (1708471500) to database 'weewx.sdb'
> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
> record 2024-02-20 18:25:00 EST (1708471500) to daily summary in 
> 'weewx.sdb'
> Feb 20 18:25:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
> Generated 7 files for report SeasonsReport in 2.53 seconds
> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
> Generated 16 images for report SeasonsReport in 1.41 seconds
> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.reportengine: 
> Copied 0 files to /var/www/html/weewx
> Feb 20 18:25:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
> Generated

Re: [weewx-user] Re: Two of Same/Similar Model AcuRite 5n1 on Single Host - Station Identification Conflict?

2024-02-21 Thread p q

I wonder if it would be easier to use SDR on one sensor unit and USB for
the other so that way you know which you're getting. I am not familiar with
weewx-multi, so maybe I'm talking crap.



On Wed, Feb 21, 2024 at 12:02 PM matthew wall  wrote:

> hi patrick,
>
> unfortunately, every acurite station looks the same - there is no unique
> identifier that lets you distinguish one station from another via the USB
> interface.
>
> if chaney instruments had done it right, they would have burned a serial
> number into each device, not just idProduct and idVendor.
>
> in lieu of an identifier for each device, another approach is to
> distinguish devices based on their locations in the usb tree.  if you could
> do that, then you could conceivably plug them into a usb hub that has ports
> whose addresses are repeatable across reboots (that might even apply to the
> usb 'hub' built in to the computer).
>
> i am not sure whether this is possible, but it would be a fun little
> project to determine the feasibility.  and it is probably easier now that
> libusb is not as volatile as it was 10 years ago.
>
> when you initiate communication with a HID (which is how the acurite and
> other usb-based stations present themselves), you specify idProduct and
> idVendor, then take the first one that shows up.  if a device has a unique
> identifier, you can match on that too (the ws28xx transceviers are an
> example of this.  some, but not all, USB-to-serial converters are too, but
> they are not HID).  it *might* be possible to use the usb tree information
> to distinguish devices.  or maybe the HID interface lets you enumerate them
> - not sure whether the libusb and pyusb layers even let you determine
> whether there are multiple devices that match.
>
> m
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/1ef9de61-4b62-4818-8dd1-eec25bade230n%40googlegroups.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAA1SM21%3DsTXnOE6o%3DXibdHTareiGFzOxt5%2B224RDwgCz9fuhOA%40mail.gmail.com.

Re: [weewx-user] Re: Vaisala WXT520 automatic mode

the failure in delta_rain has been fixed as of commit d64d397 and release 
0.7 of the wxt5x0 driver

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b07aae84-0c2b-4e92-a252-dc8c3d86d5b9n%40googlegroups.com.

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

2024-02-21 Thread gjr80

On Thursday 22 February 2024 at 00:57:58 UTC+10 Thomas Hackler wrote:

Do you mean that I should change this part in my weewx.conf:

[[StandardReport]]
skin = neowx-material

in

[Neowx-Material-Report]]
skin = neowx-material


Yes, the actual name is unimportant, but something descriptive will be 
useful when reading logs etc in the future.(I note a missing '[', I am 
guessing this is a copy/paste issue)
 

Weewx will have no problem that there is no entrance [[StandardReport]] 
anymore ?


No problem at all. WeeWX has no particular requirements of report stanza 
names other than within a given [StdReport] stanza the report names must be 
unique. Convention is to give the report a meaningful name, usually 
something that relates to the skin being used or purpose of the report.
 

the reason of the different driver version could be that I got this driver 
from a german weather station forum and it is not a one from you.

https://www.pc-wetterstation.de/forum/viewtopic.php?f=26&t=10333

not all sensors where supported in the past and so this modified version 
were made


No problem, I was merely pointing out that the version of the driver being 
used appears to be based on the v0.4.2 driver, but the current driver 
version is v0.6.0 (actually v0.6.1 as of yesterday). There have been a 
number of bug fixes and new features introduced since v0.4.2, but knowing 
nothing about v0.4.2KW I suggested that you might want to find a more 
recent version from whatever source you wish.


I plan to install a complete new and clean system for my raspberry pi, then 
I would go further with driver version 0.6.0
I hope that this cause no problems with the database and all the things


Unlikely to be any problems, though if extra sensors were added to v0.4.2KW 
and they use a different naming convention/default mapping compared to the 
same sensors in say v0.6.1 then there could be issues. It really depends on 
what 'extras'  were added to v0.4.2KW.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6a23a0a0-6333-47fd-9584-2eb23e326ec6n%40googlegroups.com.

[weewx-user] Re: Two of Same/Similar Model AcuRite 5n1 on Single Host - Station Identification Conflict?

hi patrick,

unfortunately, every acurite station looks the same - there is no unique
identifier that lets you distinguish one station from another via the USB
interface.

if chaney instruments had done it right, they would have burned a serial
number into each device, not just idProduct and idVendor.

in lieu of an identifier for each device, another approach is to
distinguish devices based on their locations in the usb tree. if you could
do that, then you could conceivably plug them into a usb hub that has ports
whose addresses are repeatable across reboots (that might even apply to the
usb 'hub' built in to the computer).

i am not sure whether this is possible, but it would be a fun little
project to determine the feasibility. and it is probably easier now that
libusb is not as volatile as it was 10 years ago.

when you initiate communication with a HID (which is how the acurite and
other usb-based stations present themselves), you specify idProduct and
idVendor, then take the first one that shows up. if a device has a unique
identifier, you can match on that too (the ws28xx transceviers are an
example of this. some, but not all, USB-to-serial converters are too, but
they are not HID). it *might* be possible to use the usb tree information
to distinguish devices. or maybe the HID interface lets you enumerate them
- not sure whether the libusb and pyusb layers even let you determine
whether there are multiple devices that match.

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/1ef9de61-4b62-4818-8dd1-eec25bade230n%40googlegroups.com.

[weewx-user] Re: Two of Same/Similar Model AcuRite 5n1 on Single Host - Station Identification Conflict?

2024-02-21 Thread vince

Probably depends on your os, but see if you can get there via some os 
magic. 

pi@pi4:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial 
Port [pl2303] <=== my serial2usb
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@pi4:~$ ls -lgd /dev/serial/*/*
lrwxrwxrwx 1 root 13 Dec 14 15:55 
/dev/serial/by-path/platform-fd50.pcie-pci-:01:00.0-usb-0:1.2:1.0-port0 
-> ../../ttyUSB0

I only have one connected usb device but dmesg when I unplug/plug it in 
looks like:

# run 'dmesg | grep -i usb' and look at the output
[504700.602816] usb 1-1.2: new full-speed USB device number 4 using xhci_hcd
[504700.707235] usb 1-1.2: New USB device found, idVendor=0557, 
idProduct=2008, bcdDevice= 3.00
[504700.707250] usb 1-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[504700.707257] usb 1-1.2: Product: USB-Serial Controller
[504700.707263] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[504700.719949] usb 1-1.2: pl2303 converter now attached to ttyUSB0  <=== 
my serial2usb

My 'guess' is that if you run the same commands you will find two things 
under /dev/serial with enough differences to tell them apart.  You might 
need to do this a little experimentally and compare 'dmesg' outputs with 
one then the other connected.  But you should find unique stable 
identifiers under /dev/serial to try.

On my ubuntu box I see /dev/serial/by-path used and I use that device in my 
Home Assistant setup.  Works well there.  I 'suspect' that weewx.conf could 
handle a /dev/serial/ if you could map what's where.

I did find one reference that might help in cooking up udev rules, but it's 
pretty cryptic unless you read through it a few times.  Then it's only 
kinda cryptic :-)
https://groups.google.com/g/hbrobotics/c/QgJ84KHnrYs

On Wednesday, February 21, 2024 at 11:17:24 AM UTC-8 Patrick Whaley wrote:

> Hi. I have two AcuRite 5n1 weather stations (model #'s 01536 and 02064), 
> each connected to it's own host computer and successfully running weewx 5.   
> Additionally 
> they both are setup to upload data to Wunderground, and generate an MQTT 
> topic. One also uploads to CWOP.  
>
> The host computers obtain sensor data via the USB data on the AcuRite 
> display units.
>
> I would prefer to have both weather stations connected to a single host 
> computer, so I attempted to do this via the 'How to run multiple 
> instances of WeeWX' instructions in the link: 
> https://github.com/weewx/weewx/wiki/weewx-multi
>
> Per the instructions I was able to configure weewx to successfully run the 
> stations with the same functionality as when they are connected to 
> dedicated hosts, albeit only one station can be connected to the host 
> computer at a time or I have the issues described below. 
>
> One station's configuration is named 'yardA' (the AcuRite model# 01536 
> unit) and the other is named 'yardB' (the AcuRite model #02064 unit).
>
> With both stations plugged into the host computers USB ports:
> 1. When running both 'yardA' and 'yardB' at the same time, both stations 
> report data, but the data that is reported for both stations is exactly the 
> same.
>
> 2. When starting only 'yardA', weewx cannot 'pick' the model# 01536 unit 
> versus 'picking' the  model# 02064 unit.  
>
> 3. Likewise when starting only 'yardB', weewx cannot 'pick' the model# 
> 02064 unit versus 'picking' the  model# 01536 unit.
>
> I have some suspicion the issue is being caused by using two of the exact 
> same AcuRite sensor units and both connected via USB.
>
> I unplugged/re-plugged both units to USB and ran 'dmesg' to see if there 
> is any distinguishing device information between the two units. Based on 
> this simple test I'm not seeing anything specific that would let weewx 
> distinguish between these two AcuRite's as different devices (although I am 
> far from being knowledgeable on most anything weewx/linux/python/etc.)
>
>
> [   78.637352] usb 1-1.3: new low-speed USB device number 5 using xhci_hcd
> [   78.743717] usb 1-1.3: New USB device found, idVendor=24c0, 
> idProduct=0003, bcdDevice= 0.20
> [   78.743738] usb 1-1.3: New USB device strings: Mfr=0, Product=2, 
> SerialNumber=0
> [   78.743750] usb 1-1.3: Product: Chaney Instrument
> [   78.754195] input: Chaney Instrument as 
> /devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0004/input/input5
> [   78.754819] hid-generic 0003:24C0:0003.0004: input,hidraw0: USB HID 
> v1.11 Device [Chaney Instrument] on usb-:01:00.0-1.3/input0
>
> [   94.512418] usb 1-1.2: new low-speed USB device number 6 using xhci_hcd
> [   94.619178] usb 1-1.2: New USB device found, idVendor=24c0, 
> idProduct=0003, bcdDevice= 0.20
> [   94.619201] usb 1-1.2: New USB device strings: Mfr=0, Product=2, 
> SerialNumber=0
> [   94.619213] usb 1-1.2: Product: Chaney I

Re: [weewx-user] Re: Vaisala WXT520 automatic mode

2024-02-21 Thread awe

Yes, seems to be an old problem. 
I wonder how people using a Vaisala WXT520 has made it work without 
crashing. 

The code, in the driver, that I think is an issue, is probably this, 
however I am not a python programmer, so I have no idea how to fix it: 









*537 @staticmethod538 def _delta_rain(rain, last_rain):
539 if last_rain is None:540 loginf("skipping rain 
measurement of %s: no last rain" % rain)541 return None
542 if rain < last_rain:543 loginf("rain counter 
wraparound detected: new=%s last=%s" %544(rain, 
last_rain))545 return rain546 return rain - 
last_rain*

On Wednesday, February 21, 2024 at 4:36:37 PM UTC+1 Tom Keffer wrote:

> Looks like the author of the extension forgot to check whether the value 
> of "rain" could be None. This appears to be a known issue, but hasn't been 
> fixed. See https://github.com/matthewwall/weewx-wxt5x0/issues/8
>
>
>
> On Wed, Feb 21, 2024 at 1:18 AM awe  wrote:
>
>> I got the same issue with the wxt5x0 running on a Raspberry with the 
>> latest everything. 
>>
>> Did you find a fix? 
>>
>>
>>
>> Feb 21 06:31:56 hpii weewxd[427]: DEBUG user.wxt5x0: raw: 30 52 30 2C 44 
>> 6D 3D 30 38 38 44 2C 44 78 3D 31 30 36 44 2C 53 6D 3D 32 2E 31 53 2C 53 78 
>> 3D 32 2E 37 53 2C 54 61 3D 33 35 2E 36 46 2C 55 61 3D 36 38 2E 38 50 2C 50 
>> 61 3D 32 39 2E 33 32 49 2C 52 63 3D 30 52 32 2C 54 61 3D 33 35 2E 36 46 2C 
>> 55 61 3D 36 38 2E 38 50 2C 50 61 3D 32 39 2E 33 32 49 0D 0A
>> Feb 21 06:31:57 hpii weewxd[427]: ERROR user.wxt5x0: parse failed for 
>> b'Rc' (b'0R2'):could not convert string to float: b'0R'
>> Feb 21 06:31:57 hpii weewxd[427]: DEBUG user.wxt5x0: parsed: 
>> {'wind_dir_avg': 88.0, 'wind_dir_max': 106.0, 'wind_speed_avg': 
>> 0.93878401, 'wind_speed_max': 1.207008, 'temperature': 
>> 2.001, 'humidity': 68.8, 'pressure': 992.889548, 'rain': None}
>> Feb 21 06:31:57 hpii weewxd[427]: INFO weewx.engine: Main loop exiting. 
>> Shutting engine down.
>> Feb 21 06:31:57 hpii weewxd[427]: INFO weewx.engine: Shutting down 
>> StdReport thread
>> Feb 21 06:31:57 hpii weewxd[427]: DEBUG weewx.engine: StdReport thread 
>> has been terminated
>> Feb 21 06:31:57 hpii weewxd[427]: DEBUG user.wxt5x0: close serial port 
>> /dev/ttyAMA0
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: Caught unrecoverable 
>> exception:
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   '<' not 
>> supported between instances of 'NoneType' and 'float'
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   Traceback 
>> (most recent call last):
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File 
>> "/usr/share/weewx/weewxd.py", line 166, in main
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:  
>>  engine.run()
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 204, in run
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   for 
>> packet in self.console.genLoopPackets():
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File 
>> "/etc/weewx/bin/user/wxt5x0.py", line 501, in genLoopPackets
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   packet 
>> = self._data_to_packet(data)
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File 
>> "/etc/weewx/bin/user/wxt5x0.py", line 532, in _data_to_packet
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:  
>>  packet['rain'] = self._delta_rain(
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File 
>> "/etc/weewx/bin/user/wxt5x0.py", line 542, in _delta_rain
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   if 
>> rain < last_rain:
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   TypeError: 
>> '<' not supported between instances of 'NoneType' and 'float'
>> Feb 21 06:31:57 hpii weewxd[427]: Traceback (most recent call last):
>> Feb 21 06:31:57 hpii weewxd[427]:   File "/usr/share/weewx/weewxd.py", 
>> line 265, in 
>> Feb 21 06:31:57 hpii weewxd[427]: main()
>> Feb 21 06:31:57 hpii weewxd[427]:   File "/usr/share/weewx/weewxd.py", 
>> line 166, in main
>> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   Exiting.
>> Feb 21 06:31:57 hpii weewxd[427]: engine.run()
>> Feb 21 06:31:57 hpii weewxd[427]:   File 
>> "/usr/share/weewx/weewx/engine.py", line 204, in run
>> Feb 21 06:31:57 hpii weewxd[427]: for packet in 
>> self.console.genLoopPackets():
>> Feb 21 06:31:57 hpii weewxd[427]:   File "/etc/weewx/bin/user/wxt5x0.py", 
>> line 501, in genLoopPackets
>> Feb 21 06:31:57 hpii weewxd[427]: packet = self._data_to_packet(data)
>> Feb 21 06:31:57 hpii weewxd[427]:   File "/etc/weewx/bin/user/wxt5x0.py", 
>> line 532, in _data_to_packet
>> Feb 21 06:31:57 hpii weewxd[427]:

[weewx-user] Two of Same/Similar Model AcuRite 5n1 on Single Host - Station Identification Conflict?

2024-02-21 Thread Patrick Whaley

Hi. I have two AcuRite 5n1 weather stations (model #'s 01536 and 02064),
each connected to it's own host computer and successfully running weewx 5.
Additionally
they both are setup to upload data to Wunderground, and generate an MQTT
topic. One also uploads to CWOP.

The host computers obtain sensor data via the USB data on the AcuRite
display units.

I would prefer to have both weather stations connected to a single host
computer, so I attempted to do this via the 'How to run multiple instances
of WeeWX' instructions in the link:
https://github.com/weewx/weewx/wiki/weewx-multi

Per the instructions I was able to configure weewx to successfully run the
stations with the same functionality as when they are connected to
dedicated hosts, albeit only one station can be connected to the host
computer at a time or I have the issues described below.

One station's configuration is named 'yardA' (the AcuRite model# 01536
unit) and the other is named 'yardB' (the AcuRite model #02064 unit).

With both stations plugged into the host computers USB ports:
1. When running both 'yardA' and 'yardB' at the same time, both stations
report data, but the data that is reported for both stations is exactly the
same.

2. When starting only 'yardA', weewx cannot 'pick' the model# 01536 unit
versus 'picking' the model# 02064 unit.

3. Likewise when starting only 'yardB', weewx cannot 'pick' the model#
02064 unit versus 'picking' the model# 01536 unit.

I have some suspicion the issue is being caused by using two of the exact
same AcuRite sensor units and both connected via USB.

I unplugged/re-plugged both units to USB and ran 'dmesg' to see if there is
any distinguishing device information between the two units. Based on this
simple test I'm not seeing anything specific that would let weewx
distinguish between these two AcuRite's as different devices (although I am
far from being knowledgeable on most anything weewx/linux/python/etc.)

[ 78.637352] usb 1-1.3: new low-speed USB device number 5 using xhci_hcd
[ 78.743717] usb 1-1.3: New USB device found, idVendor=24c0,
idProduct=0003, bcdDevice= 0.20
[ 78.743738] usb 1-1.3: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 78.743750] usb 1-1.3: Product: Chaney Instrument
[ 78.754195] input: Chaney Instrument as
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:24C0:0003.0004/input/input5
[ 78.754819] hid-generic 0003:24C0:0003.0004: input,hidraw0: USB HID
v1.11 Device [Chaney Instrument] on usb-:01:00.0-1.3/input0

[ 94.512418] usb 1-1.2: new low-speed USB device number 6 using xhci_hcd
[ 94.619178] usb 1-1.2: New USB device found, idVendor=24c0,
idProduct=0003, bcdDevice= 0.20
[ 94.619201] usb 1-1.2: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 94.619213] usb 1-1.2: Product: Chaney Instrument
[ 94.629809] input: Chaney Instrument as
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:24C0:0003.0005/input/input6
[ 94.630554] hid-generic 0003:24C0:0003.0005: input,hidraw3: USB HID
v1.11 Device [Chaney Instrument] on usb-:01:00.0-1.2/input0

I'm grateful in advance for suggestions anyone has on how make my multiple
AcuRite station setup work on a single host computer.

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/e11687c5-0776-417a-b8c9-adff013664b4n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

I'm blessed if I know why the log doesn't show anything about the crashes. 
The crash information I showed earlier was actually from systemctl status, 
after the second crash occurred (the first one reported the serial port 
access failure). I cannot find a way to get the same detail in the history 
from journalctl, and the log I am giving you is from running:
sudo grep weewxd /var/log/messages >weewx0.log
This may omit important detail lines, if they don't contain the string: 
'weewxd'


On Wednesday, February 21, 2024 at 10:33:11 AM UTC-5 Tom Keffer wrote:

> Glad it's working for you, but why were there log entries of the crt 
> exception the first time, but not the last? 
>
> If a thread is exiting without telling us why, that's a bug. Looking 
> through the crt code, the write to the disk is protected by an exception 
> clause, so it should have caught the permissions error and logged it.
>
>
>
> On Tue, Feb 20, 2024 at 7:21 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> That is the entire log from shortly before the update. I am guessing that 
>> the known bug in crt.py results in the crash not being properly reported.
>>
>> The good news is that I was able to figure out what was going on. I am 
>> using crt to produce a file that allows the display of current weather 
>> conditions on my HOA's website. It is written to a subfolder of its own in 
>> /var/www/html and uploaded to the HOA site from there by weewx. Again, it 
>> was the change from weewx running as root to it running as weewx that was 
>> causing an access privilege error. Simply deleting the old version of the 
>> file did not solve the problem, but assigning ownership of the relevant 
>> *subfolder* to weewx:weewx restored normal functionality.
>> On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:
>>
>>> That's the end of the log? Where is the crt error?
>>>
>>> The record timestamped 2024-02-20 20:30:00 was downloaded from the 
>>> logger at 20:32:22. I would expect the next record to be processed at 
>>> 20:35:16 or so. Did you terminate the program? Is there something later in 
>>> the log?
>>>
>>> On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Here is the log from before I applied the apt update, through now. This 
 includes one reboot. The last  start was after setting debug=1 in the 
 config file. I hope that it helps you more than it does me!:

 Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
 Generated 7 files for report SeasonsReport in 2.52 seconds
 Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
 Generated 16 images for report SeasonsReport in 1.47 seconds
 Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
 0 files to /var/www/html/weewx
 Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report PublicReport in 2.19 seconds
 Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
 Generated 16 images for report PublicReport in 1.39 seconds
 Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
 0 files to /var/www/html/weewx2
 Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
 ftpgenerator: Ftp'd 1 files in 0.75 seconds
 Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine: 
 ftpgenerator: Ftp'd 22 files in 10.12 seconds
 Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
 record 2024-02-20 18:25:00 EST (1708471500) to database 'weewx.sdb'
 Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
 record 2024-02-20 18:25:00 EST (1708471500) to daily summary in 'weewx.sdb'
 Feb 20 18:25:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
 Generated 7 files for report SeasonsReport in 2.53 seconds
 Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
 Generated 16 images for report SeasonsReport in 1.41 seconds
 Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
 0 files to /var/www/html/weewx
 Feb 20 18:25:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report PublicReport in 2.19 seconds
 Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
 Generated 16 images for report PublicReport in 1.40 seconds
 Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
 0 files to /var/www/html/weewx2
 Feb 20 18:25:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
 ftpgenerator: Ftp'd 1 files in 0.76 seconds
 Feb 20 18:25:36 bullseyepi weewxd[447]: INFO weewx.reportengine: 
 ftpgenerator: Ftp'd 22 files in 11.08 seconds
 Feb 20 18:30:21 bullseyepi weewxd[447]: INFO weewx.manager: Added 
 record 2024-02-20 18:30:00 EST (1708471800) to database 'weewx.sdb'
 Feb 20 18:

[weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

Tom

Many thanks, solved!

sudo usermod -aG dialout weewx.

All up and working fine on the new RPi 5 having followed your magnificent 
guide here:  Moving Weewx to new PC (google.com) 


Regards

Dave

On Wednesday 21 February 2024 at 16:00:54 UTC Dave McCreath wrote:

> I also ran dmesg with the serial adaptor inserted and the following are 
> the last six lines of output: 
>
> [ 1596.869545] usb 3-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [ 1596.869548] usb 3-1: Product: CP2102 USB to UART Bridge Controller
> [ 1596.869551] usb 3-1: Manufacturer: Silicon Labs
> [ 1596.869553] usb 3-1: SerialNumber: 0001
> [ 1596.870446] cp210x 3-1:1.0: cp210x converter detected
> [ 1596.873368] usb 3-1: cp210x converter now attached to ttyUSB0
> On Wednesday 21 February 2024 at 13:18:38 UTC Dave McCreath wrote:
>
>> Ville
>>
>> Many thanks for your support.  As requested output of ls /dev/
>>
>> is here:
>>
>> DMac@WeeWX:~ $ ls /dev/
>> autofs   loop1 ram6tty24  tty58  vcsu1
>> blockloop2 ram7tty25  tty59  vcsu2
>> bsg  loop3 ram8tty26  tty6   vcsu3
>> btrfs-controlloop4 ram9tty27  tty60  vcsu4
>> bus  loop5 random  tty28  tty61  vcsu5
>> cachefiles   loop6 rfkill  tty29  tty62  vcsu6
>> cec0 loop7 rtc tty3   tty63  vcsu7
>> cec1 loop-control  rtc0tty30  tty7   vga_arbiter
>> char mappersda tty31  tty8   vhci
>> console  media0sda1tty32  tty9   vhost-net
>> cpu_dma_latency  media1serial  tty33  ttyAMA10   vhost-vsock
>> cuse media2serial0 tty34  ttyprintk  video19
>> disk mem   sg0 tty35  ttyUSB0video20
>> dma_heap mmcblk0   shm tty36  uhid   video21
>> dri  mmcblk0p1 snd tty37  uinput video22
>> fd   mmcblk0p2 spidev10.0  tty38  urandomvideo23
>> full mqueuestderr  tty39  v4lvideo24
>> fuse net   stdin   tty4   vantagevideo25
>> gpiochip0null  stdout  tty40  vcio   video26
>> gpiochip1port  tty tty41  vc-mem video27
>> gpiochip2ppp   tty0tty42  vcsvideo28
>> gpiochip3pps0  tty1tty43  vcs1   video29
>> gpiochip4ptmx  tty10   tty44  vcs2   video30
>> gpiomem0 ptp0  tty11   tty45  vcs3   video31
>> gpiomem1 pts   tty12   tty46  vcs4   video32
>> gpiomem2 ram0  tty13   tty47  vcs5   video33
>> gpiomem3 ram1  tty14   tty48  vcs6   video34
>> gpiomem4 ram10 tty15   tty49  vcs7   video35
>> hwrngram11 tty16   tty5   vcsa   video36
>> i2c-11   ram12 tty17   tty50  vcsa1  video37
>> i2c-12   ram13 tty18   tty51  vcsa2  watchdog
>> initctl  ram14 tty19   tty52  vcsa3  watchdog0
>> inputram15 tty2tty53  vcsa4  zero
>> kmsg ram2  tty20   tty54  vcsa5
>> kvm  ram3  tty21   tty55  vcsa6
>> log  ram4  tty22   tty56  vcsa7
>> loop0ram5  tty23   tty57  vcsu
>>
>> Regards
>>
>> Dave
>>
>>
>> On Wednesday 21 February 2024 at 12:49:42 UTC vhel...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> Plug the USB serial converter with weatherstation plugged to your RPI5.
>>> Check from linux terminal command: ls /dev/ to see is your logger there.
>>> Paste the results of: ls /dev/ here.
>>>
>>> -Ville-
>>>
>>>
>>> keskiviikko 21. helmikuuta 2024 klo 14.38.36 UTC+2 Dave McCreath 
>>> kirjoitti:
>>>
 Recently acquired an RPi 5 and decided this morning to migrate WeeWX 
 over to it from an up to date RPi 4.

 Three attempts, all failed with the same errors.  I have tried with 
 both the USB serial connector inserted and without.  I'm running the RPi 
 headless over VNC and nothing else plugged into it at all apart from the 
 power lead.

 *Log:*

  2024-02-21T12:15:44.944885+00:00 WeeWX weectl[2869]: INFO weectllib: 
 Initializing weectl version 5.0.2
 2024-02-21T12:15:44.945066+00:00 WeeWX weectl[2869]: INFO weectllib: 
 Command line: /usr/share/weewx/weectl.py station reconfigure 
 --config=/etc/weewx/weewx.conf --driver=weewx.drivers.vantage 
 --units=metric --location=Leverington --latitude=52.693 --longitude=0.147 
 --altitude=3,meter --register=y --station-url=
 https://www.wunderground.com/dashboard/pws/ICAMBSLE2 --no-prompt 
 --no-backup
 2024-02-21T12:1

Re: [weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

Dave, you have a permissions problem. See the wiki article How to fix
device permissions

in
particular, *Example: add the weewx user to group defined on a device*
.
If that doesn't help, come back here and we'll figure it out.

Neil, your problem is something completely different and not related to
Dave's. It looks like you solved it in another thread.

-tk

On Wed, Feb 21, 2024 at 8:00 AM Dave McCreath 
wrote:

> I also ran dmesg with the serial adaptor inserted and the following are
> the last six lines of output:
>
> [ 1596.869545] usb 3-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 1596.869548] usb 3-1: Product: CP2102 USB to UART Bridge Controller
> [ 1596.869551] usb 3-1: Manufacturer: Silicon Labs
> [ 1596.869553] usb 3-1: SerialNumber: 0001
> [ 1596.870446] cp210x 3-1:1.0: cp210x converter detected
> [ 1596.873368] usb 3-1: cp210x converter now attached to ttyUSB0
> On Wednesday 21 February 2024 at 13:18:38 UTC Dave McCreath wrote:
>
>> Ville
>>
>> Many thanks for your support.  As requested output of ls /dev/
>>
>> is here:
>>
>> DMac@WeeWX:~ $ ls /dev/
>> autofs   loop1 ram6tty24  tty58  vcsu1
>> blockloop2 ram7tty25  tty59  vcsu2
>> bsg  loop3 ram8tty26  tty6   vcsu3
>> btrfs-controlloop4 ram9tty27  tty60  vcsu4
>> bus  loop5 random  tty28  tty61  vcsu5
>> cachefiles   loop6 rfkill  tty29  tty62  vcsu6
>> cec0 loop7 rtc tty3   tty63  vcsu7
>> cec1 loop-control  rtc0tty30  tty7   vga_arbiter
>> char mappersda tty31  tty8   vhci
>> console  media0sda1tty32  tty9   vhost-net
>> cpu_dma_latency  media1serial  tty33  ttyAMA10   vhost-vsock
>> cuse media2serial0 tty34  ttyprintk  video19
>> disk mem   sg0 tty35  ttyUSB0video20
>> dma_heap mmcblk0   shm tty36  uhid   video21
>> dri  mmcblk0p1 snd tty37  uinput video22
>> fd   mmcblk0p2 spidev10.0  tty38  urandomvideo23
>> full mqueuestderr  tty39  v4lvideo24
>> fuse net   stdin   tty4   vantagevideo25
>> gpiochip0null  stdout  tty40  vcio   video26
>> gpiochip1port  tty tty41  vc-mem video27
>> gpiochip2ppp   tty0tty42  vcsvideo28
>> gpiochip3pps0  tty1tty43  vcs1   video29
>> gpiochip4ptmx  tty10   tty44  vcs2   video30
>> gpiomem0 ptp0  tty11   tty45  vcs3   video31
>> gpiomem1 pts   tty12   tty46  vcs4   video32
>> gpiomem2 ram0  tty13   tty47  vcs5   video33
>> gpiomem3 ram1  tty14   tty48  vcs6   video34
>> gpiomem4 ram10 tty15   tty49  vcs7   video35
>> hwrngram11 tty16   tty5   vcsa   video36
>> i2c-11   ram12 tty17   tty50  vcsa1  video37
>> i2c-12   ram13 tty18   tty51  vcsa2  watchdog
>> initctl  ram14 tty19   tty52  vcsa3  watchdog0
>> inputram15 tty2tty53  vcsa4  zero
>> kmsg ram2  tty20   tty54  vcsa5
>> kvm  ram3  tty21   tty55  vcsa6
>> log  ram4  tty22   tty56  vcsa7
>> loop0ram5  tty23   tty57  vcsu
>>
>> Regards
>>
>> Dave
>>
>>
>> On Wednesday 21 February 2024 at 12:49:42 UTC vhel...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> Plug the USB serial converter with weatherstation plugged to your RPI5.
>>> Check from linux terminal command: ls /dev/ to see is your logger there.
>>> Paste the results of: ls /dev/ here.
>>>
>>> -Ville-
>>>
>>>
>>> keskiviikko 21. helmikuuta 2024 klo 14.38.36 UTC+2 Dave McCreath
>>> kirjoitti:
>>>
 Recently acquired an RPi 5 and decided this morning to migrate WeeWX
 over to it from an up to date RPi 4.

 Three attempts, all failed with the same errors.  I have tried with
 both the USB serial connector inserted and without.  I'm running the RPi
 headless over VNC and nothing else plugged into it at all apart from the
 power lead.

 *Log:*

  2024-02-21T12:15:44.944885+00:00 WeeWX weectl[2869]: INFO weectllib:
 Initializing weectl version 5.0.2
 2024-02-21T12:15:44.945066+00:00 WeeWX weectl[2869]: INFO weectllib:
 Command line: /usr/share/weewx/weectl.py station reconfigure
 --config=

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

Oh, I thought we were talking about upgrading from an alpha version of v5.

Not much difference. Just set up a V5 virtual environment, then point it at
/home/weewx. Follow the directions in the migration guide
.

On Wed, Feb 21, 2024 at 7:44 AM gary@gmail.com 
wrote:

> I understand coming from v5 that would be a way.
> I need to upgrade my v4 setup.py to v5 though.
>
>
> On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:
>
> The pip installs are super easy to back up. Just copy ~/weewx-venv and
> ~/weewx-data and you have everything you need.
>
> Then activate the virtual environment, then "pip install weewx --upgrade".
> It should be that easy. If something fails, just roll things back.
>
> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com 
> wrote:
>
> I've had a test install of v5 since early alphas. Now, it is time to
> upgrade my production install.
> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A
> couple of additional internet uploaders (Windy and WeatherCloud). I run two
> skins, Belchertown and weewx-wdc
>
> All is and has been quite stable. So, I hesitate to poke at it. But, v5 is
> the new standard, so I need to get this done.
>
> I don't see many who have trod this path. How to go about this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/68e9b77e-5d25-492f-bfa5-448ac39b8cedn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEDQXLoh9g1xxAb5kJW%2B74F0%2BrnyazBXnzW7xHfiuPmz9Q%40mail.gmail.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

2024-02-21 Thread 'michael.k...@gmx.at' via weewx-user

I'd do it this way:

- leave your existing installation running

- install v5 the pip way, exactly like described here, including 
provisioning a new station: https://weewx.com/docs/5.0/quickstarts/pip/
- provision the station with default values
- start and verify it
- copy your old weewx.conf over the newly created one
- check your paths in your weewx.conf (WEWWX_ROOT, HTML_ROOT, SKIN_ROOT and 
so on)
- in case of using sqlite: copy your database to ~/weewx-data/archive, 
overwriting the newly created one, if the file names are the same, 
otherwise delete the newly created one, to have things tidy
- install all extensions (drivers, skins, ...) you had before , see: 
https://weewx.com/docs/5.0/utilities/weectl-extension/
- if any, copy all your bin/user files that didn't come with an installer 
to ~/weewx-data/bin/user/

- if your device isn't limited to exclusive access, run weewxd in the venv 
and validate
- if your device is limited to exclusive access, stop the old installation 
and run (the new) weewxd in the venv and validate
- once validated, enjoy

Depending on your hardware, you might want to copy the udev rules and apply 
them (~/weewx-data/util/udev)
Depending on your needs and environment, create and enable systemd scripts 
(~/weewx-data/util/systemd)
gary@gmail.com schrieb am Mittwoch, 21. Februar 2024 um 16:44:02 UTC+1:

> I understand coming from v5 that would be a way.
> I need to upgrade my v4 setup.py to v5 though.
>
>
> On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:
>
> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
> ~/weewx-data and you have everything you need.
>
> Then activate the virtual environment, then "pip install weewx --upgrade". 
> It should be that easy. If something fails, just roll things back.
>
> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
> wrote:
>
> I've had a test install of v5 since early alphas. Now, it is time to 
> upgrade my production install.
> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
> couple of additional internet uploaders (Windy and WeatherCloud). I run two 
> skins, Belchertown and weewx-wdc
>
> All is and has been quite stable. So, I hesitate to poke at it. But, v5 is 
> the new standard, so I need to get this done.
>
> I don't see many who have trod this path. How to go about this?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c576449a-71b4-4c87-aa50-aed752615134n%40googlegroups.com.

[weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

I also ran dmesg with the serial adaptor inserted and the following are the 
last six lines of output: 

[ 1596.869545] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1596.869548] usb 3-1: Product: CP2102 USB to UART Bridge Controller
[ 1596.869551] usb 3-1: Manufacturer: Silicon Labs
[ 1596.869553] usb 3-1: SerialNumber: 0001
[ 1596.870446] cp210x 3-1:1.0: cp210x converter detected
[ 1596.873368] usb 3-1: cp210x converter now attached to ttyUSB0
On Wednesday 21 February 2024 at 13:18:38 UTC Dave McCreath wrote:

> Ville
>
> Many thanks for your support.  As requested output of ls /dev/
>
> is here:
>
> DMac@WeeWX:~ $ ls /dev/
> autofs   loop1 ram6tty24  tty58  vcsu1
> blockloop2 ram7tty25  tty59  vcsu2
> bsg  loop3 ram8tty26  tty6   vcsu3
> btrfs-controlloop4 ram9tty27  tty60  vcsu4
> bus  loop5 random  tty28  tty61  vcsu5
> cachefiles   loop6 rfkill  tty29  tty62  vcsu6
> cec0 loop7 rtc tty3   tty63  vcsu7
> cec1 loop-control  rtc0tty30  tty7   vga_arbiter
> char mappersda tty31  tty8   vhci
> console  media0sda1tty32  tty9   vhost-net
> cpu_dma_latency  media1serial  tty33  ttyAMA10   vhost-vsock
> cuse media2serial0 tty34  ttyprintk  video19
> disk mem   sg0 tty35  ttyUSB0video20
> dma_heap mmcblk0   shm tty36  uhid   video21
> dri  mmcblk0p1 snd tty37  uinput video22
> fd   mmcblk0p2 spidev10.0  tty38  urandomvideo23
> full mqueuestderr  tty39  v4lvideo24
> fuse net   stdin   tty4   vantagevideo25
> gpiochip0null  stdout  tty40  vcio   video26
> gpiochip1port  tty tty41  vc-mem video27
> gpiochip2ppp   tty0tty42  vcsvideo28
> gpiochip3pps0  tty1tty43  vcs1   video29
> gpiochip4ptmx  tty10   tty44  vcs2   video30
> gpiomem0 ptp0  tty11   tty45  vcs3   video31
> gpiomem1 pts   tty12   tty46  vcs4   video32
> gpiomem2 ram0  tty13   tty47  vcs5   video33
> gpiomem3 ram1  tty14   tty48  vcs6   video34
> gpiomem4 ram10 tty15   tty49  vcs7   video35
> hwrngram11 tty16   tty5   vcsa   video36
> i2c-11   ram12 tty17   tty50  vcsa1  video37
> i2c-12   ram13 tty18   tty51  vcsa2  watchdog
> initctl  ram14 tty19   tty52  vcsa3  watchdog0
> inputram15 tty2tty53  vcsa4  zero
> kmsg ram2  tty20   tty54  vcsa5
> kvm  ram3  tty21   tty55  vcsa6
> log  ram4  tty22   tty56  vcsa7
> loop0ram5  tty23   tty57  vcsu
>
> Regards
>
> Dave
>
>
> On Wednesday 21 February 2024 at 12:49:42 UTC vhel...@gmail.com wrote:
>
>> Hi,
>>
>> Plug the USB serial converter with weatherstation plugged to your RPI5.
>> Check from linux terminal command: ls /dev/ to see is your logger there.
>> Paste the results of: ls /dev/ here.
>>
>> -Ville-
>>
>>
>> keskiviikko 21. helmikuuta 2024 klo 14.38.36 UTC+2 Dave McCreath 
>> kirjoitti:
>>
>>> Recently acquired an RPi 5 and decided this morning to migrate WeeWX 
>>> over to it from an up to date RPi 4.
>>>
>>> Three attempts, all failed with the same errors.  I have tried with both 
>>> the USB serial connector inserted and without.  I'm running the RPi 
>>> headless over VNC and nothing else plugged into it at all apart from the 
>>> power lead.
>>>
>>> *Log:*
>>>
>>>  2024-02-21T12:15:44.944885+00:00 WeeWX weectl[2869]: INFO weectllib: 
>>> Initializing weectl version 5.0.2
>>> 2024-02-21T12:15:44.945066+00:00 WeeWX weectl[2869]: INFO weectllib: 
>>> Command line: /usr/share/weewx/weectl.py station reconfigure 
>>> --config=/etc/weewx/weewx.conf --driver=weewx.drivers.vantage 
>>> --units=metric --location=Leverington --latitude=52.693 --longitude=0.147 
>>> --altitude=3,meter --register=y --station-url=
>>> https://www.wunderground.com/dashboard/pws/ICAMBSLE2 --no-prompt 
>>> --no-backup
>>> 2024-02-21T12:15:44.945101+00:00 WeeWX weectl[2869]: ERROR 
>>> weeutil.startup: Cannot load user extensions: No module named 'user'
>>> 2024-02-21T12:15:44.974672+00:00 WeeWX weectl[2869]: INFO 
>>> weectl-station: Using Vantage version 3.6.2 (weewx.drivers.vantage)
>>> 2024-02-21T12:15:45.030191+00:00 WeeWX systemd[1]: Reloading.
>>> 2024-02-21T12:15:45.848292+00:00 WeeWX systemd[1]: Reloading.
>>> 2024-02-21T12:15:46.281844+00:00 WeeWX sy

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

2024-02-21 Thread 'michael.k...@gmx.at' via weewx-user

I did this like dozens of times already, it is that easy.
v5 the pip way is just awesome.

Tom Keffer schrieb am Mittwoch, 21. Februar 2024 um 16:39:47 UTC+1:

> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
> ~/weewx-data and you have everything you need.
>
> Then activate the virtual environment, then "pip install weewx --upgrade". 
> It should be that easy. If something fails, just roll things back.
>
> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
> wrote:
>
>> I've had a test install of v5 since early alphas. Now, it is time to 
>> upgrade my production install.
>> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
>> couple of additional internet uploaders (Windy and WeatherCloud). I run two 
>> skins, Belchertown and weewx-wdc
>>
>> All is and has been quite stable. So, I hesitate to poke at it. But, v5 
>> is the new standard, so I need to get this done.
>>
>> I don't see many who have trod this path. How to go about this?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c3102203-1e41-4938-8925-2ffca92e42a3n%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

2024-02-21 Thread gary....@gmail.com

I understand coming from v5 that would be a way.
I need to upgrade my v4 setup.py to v5 though.

On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:

The pip installs are super easy to back up. Just copy ~/weewx-venv and
~/weewx-data and you have everything you need.

Then activate the virtual environment, then "pip install weewx --upgrade".
It should be that easy. If something fails, just roll things back.

On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com
wrote:

I've had a test install of v5 since early alphas. Now, it is time to
upgrade my production install.
I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A
couple of additional internet uploaders (Windy and WeatherCloud). I run two
skins, Belchertown and weewx-wdc

All is and has been quite stable. So, I hesitate to poke at it. But, v5 is
the new standard, so I need to get this done.

I don't see many who have trod this path. How to go about this?

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/68e9b77e-5d25-492f-bfa5-448ac39b8cedn%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

The pip installs are super easy to back up. Just copy ~/weewx-venv and
~/weewx-data and you have everything you need.

Then activate the virtual environment, then "pip install weewx --upgrade".
It should be that easy. If something fails, just roll things back.

On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com 
wrote:

> I've had a test install of v5 since early alphas. Now, it is time to
> upgrade my production install.
> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A
> couple of additional internet uploaders (Windy and WeatherCloud). I run two
> skins, Belchertown and weewx-wdc
>
> All is and has been quite stable. So, I hesitate to poke at it. But, v5 is
> the new standard, so I need to get this done.
>
> I don't see many who have trod this path. How to go about this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zECZ5Ju02f1sNABnhPK-3NxW40eX%3Dbea4pNCWWUWQchBaQ%40mail.gmail.com.

Re: [weewx-user] Re: Vaisala WXT520 automatic mode

Looks like the author of the extension forgot to check whether the value of
"rain" could be None. This appears to be a known issue, but hasn't been
fixed. See https://github.com/matthewwall/weewx-wxt5x0/issues/8



On Wed, Feb 21, 2024 at 1:18 AM awe  wrote:

> I got the same issue with the wxt5x0 running on a Raspberry with the
> latest everything.
>
> Did you find a fix?
>
>
>
> Feb 21 06:31:56 hpii weewxd[427]: DEBUG user.wxt5x0: raw: 30 52 30 2C 44
> 6D 3D 30 38 38 44 2C 44 78 3D 31 30 36 44 2C 53 6D 3D 32 2E 31 53 2C 53 78
> 3D 32 2E 37 53 2C 54 61 3D 33 35 2E 36 46 2C 55 61 3D 36 38 2E 38 50 2C 50
> 61 3D 32 39 2E 33 32 49 2C 52 63 3D 30 52 32 2C 54 61 3D 33 35 2E 36 46 2C
> 55 61 3D 36 38 2E 38 50 2C 50 61 3D 32 39 2E 33 32 49 0D 0A
> Feb 21 06:31:57 hpii weewxd[427]: ERROR user.wxt5x0: parse failed for
> b'Rc' (b'0R2'):could not convert string to float: b'0R'
> Feb 21 06:31:57 hpii weewxd[427]: DEBUG user.wxt5x0: parsed:
> {'wind_dir_avg': 88.0, 'wind_dir_max': 106.0, 'wind_speed_avg':
> 0.93878401, 'wind_speed_max': 1.207008, 'temperature':
> 2.001, 'humidity': 68.8, 'pressure': 992.889548, 'rain': None}
> Feb 21 06:31:57 hpii weewxd[427]: INFO weewx.engine: Main loop exiting.
> Shutting engine down.
> Feb 21 06:31:57 hpii weewxd[427]: INFO weewx.engine: Shutting down
> StdReport thread
> Feb 21 06:31:57 hpii weewxd[427]: DEBUG weewx.engine: StdReport thread has
> been terminated
> Feb 21 06:31:57 hpii weewxd[427]: DEBUG user.wxt5x0: close serial port
> /dev/ttyAMA0
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: Caught unrecoverable
> exception:
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   '<' not
> supported between instances of 'NoneType' and 'float'
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   Traceback
> (most recent call last):
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File
> "/usr/share/weewx/weewxd.py", line 166, in main
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: 
>  engine.run()
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File
> "/usr/share/weewx/weewx/engine.py", line 204, in run
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   for
> packet in self.console.genLoopPackets():
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File
> "/etc/weewx/bin/user/wxt5x0.py", line 501, in genLoopPackets
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   packet
> = self._data_to_packet(data)
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File
> "/etc/weewx/bin/user/wxt5x0.py", line 532, in _data_to_packet
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: 
>  packet['rain'] = self._delta_rain(
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__: File
> "/etc/weewx/bin/user/wxt5x0.py", line 542, in _delta_rain
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   if rain
> < last_rain:
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   TypeError:
> '<' not supported between instances of 'NoneType' and 'float'
> Feb 21 06:31:57 hpii weewxd[427]: Traceback (most recent call last):
> Feb 21 06:31:57 hpii weewxd[427]:   File "/usr/share/weewx/weewxd.py",
> line 265, in 
> Feb 21 06:31:57 hpii weewxd[427]: main()
> Feb 21 06:31:57 hpii weewxd[427]:   File "/usr/share/weewx/weewxd.py",
> line 166, in main
> Feb 21 06:31:57 hpii weewxd[427]: CRITICAL __main__:   Exiting.
> Feb 21 06:31:57 hpii weewxd[427]: engine.run()
> Feb 21 06:31:57 hpii weewxd[427]:   File
> "/usr/share/weewx/weewx/engine.py", line 204, in run
> Feb 21 06:31:57 hpii weewxd[427]: for packet in
> self.console.genLoopPackets():
> Feb 21 06:31:57 hpii weewxd[427]:   File "/etc/weewx/bin/user/wxt5x0.py",
> line 501, in genLoopPackets
> Feb 21 06:31:57 hpii weewxd[427]: packet = self._data_to_packet(data)
> Feb 21 06:31:57 hpii weewxd[427]:   File "/etc/weewx/bin/user/wxt5x0.py",
> line 532, in _data_to_packet
> Feb 21 06:31:57 hpii weewxd[427]: packet['rain'] = self._delta_rain(
> Feb 21 06:31:57 hpii weewxd[427]:   File "/etc/weewx/bin/user/wxt5x0.py",
> line 542, in _delta_rain
> Feb 21 06:31:57 hpii weewxd[427]: if rain < last_rain:
> Feb 21 06:31:57 hpii weewxd[427]: TypeError: '<' not supported between
> instances of 'NoneType' and 'float'
> Feb 21 06:31:58 hpii systemd[1]: weewx.service: Main process exited,
> code=exited, status=1/FAILURE
> Feb 21 06:31:58 hpii systemd[1]: weewx.service: Failed with result
> 'exit-code'.
> Feb 21 06:31:58 hpii systemd[1]: weewx.service: Consumed 1h 20min 28.253s
> CPU time.
>
> On Friday, April 2, 2021 at 10:43:02 AM UTC+2 Sven Gloor wrote:
>
>>
>> Hello everybody
>>
>> I'm using weewx on a Raspi 3B together with the Vaisala WXT520. The WXT
>> is sending automatic messages (ASCII, 0R1: 3s, 0R2: 15s, 0R3: 60s, 0R0:
>> 60s).
>> After starting weewx everthing looks OK but after sometimes houres,
>> sometimes da

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

Glad it's working for you, but why were there log entries of the crt
exception the first time, but not the last?

If a thread is exiting without telling us why, that's a bug. Looking
through the crt code, the write to the disk is protected by an exception
clause, so it should have caught the permissions error and logged it.



On Tue, Feb 20, 2024 at 7:21 PM 'Peter Fletcher' via weewx-user <
weewx-user@googlegroups.com> wrote:

> That is the entire log from shortly before the update. I am guessing that
> the known bug in crt.py results in the crash not being properly reported.
>
> The good news is that I was able to figure out what was going on. I am
> using crt to produce a file that allows the display of current weather
> conditions on my HOA's website. It is written to a subfolder of its own in
> /var/www/html and uploaded to the HOA site from there by weewx. Again, it
> was the change from weewx running as root to it running as weewx that was
> causing an access privilege error. Simply deleting the old version of the
> file did not solve the problem, but assigning ownership of the relevant
> *subfolder* to weewx:weewx restored normal functionality.
> On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:
>
>> That's the end of the log? Where is the crt error?
>>
>> The record timestamped 2024-02-20 20:30:00 was downloaded from the logger
>> at 20:32:22. I would expect the next record to be processed at 20:35:16 or
>> so. Did you terminate the program? Is there something later in the log?
>>
>> On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Here is the log from before I applied the apt update, through now. This
>>> includes one reboot. The last  start was after setting debug=1 in the
>>> config file. I hope that it helps you more than it does me!:
>>>
>>> Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 7 files for report SeasonsReport in 2.52 seconds
>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator:
>>> Generated 16 images for report SeasonsReport in 1.47 seconds
>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied
>>> 0 files to /var/www/html/weewx
>>> Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 8 files for report PublicReport in 2.19 seconds
>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator:
>>> Generated 16 images for report PublicReport in 1.39 seconds
>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied
>>> 0 files to /var/www/html/weewx2
>>> Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine:
>>> ftpgenerator: Ftp'd 1 files in 0.75 seconds
>>> Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine:
>>> ftpgenerator: Ftp'd 22 files in 10.12 seconds
>>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added record
>>> 2024-02-20 18:25:00 EST (1708471500) to database 'weewx.sdb'
>>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added record
>>> 2024-02-20 18:25:00 EST (1708471500) to daily summary in 'weewx.sdb'
>>> Feb 20 18:25:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 7 files for report SeasonsReport in 2.53 seconds
>>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.imagegenerator:
>>> Generated 16 images for report SeasonsReport in 1.41 seconds
>>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied
>>> 0 files to /var/www/html/weewx
>>> Feb 20 18:25:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 8 files for report PublicReport in 2.19 seconds
>>> Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator:
>>> Generated 16 images for report PublicReport in 1.40 seconds
>>> Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied
>>> 0 files to /var/www/html/weewx2
>>> Feb 20 18:25:25 bullseyepi weewxd[447]: INFO weewx.reportengine:
>>> ftpgenerator: Ftp'd 1 files in 0.76 seconds
>>> Feb 20 18:25:36 bullseyepi weewxd[447]: INFO weewx.reportengine:
>>> ftpgenerator: Ftp'd 22 files in 11.08 seconds
>>> Feb 20 18:30:21 bullseyepi weewxd[447]: INFO weewx.manager: Added record
>>> 2024-02-20 18:30:00 EST (1708471800) to database 'weewx.sdb'
>>> Feb 20 18:30:21 bullseyepi weewxd[447]: INFO weewx.manager: Added record
>>> 2024-02-20 18:30:00 EST (1708471800) to daily summary in 'weewx.sdb'
>>> Feb 20 18:30:24 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 7 files for report SeasonsReport in 3.31 seconds
>>> Feb 20 18:30:26 bullseyepi weewxd[447]: INFO weewx.imagegenerator:
>>> Generated 16 images for report SeasonsReport in 1.62 seconds
>>> Feb 20 18:30:26 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied
>>> 0 files to /var/www/html/weewx
>>> Feb 20 18:30:28 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator:
>>> Generated 8 files for report PublicReport in 2.54 seconds
>>> Feb 20 18:30:30 bullseyepi wee

[weewx-user] How to upgrade from setup.py v4 install to pip v5 install

2024-02-21 Thread gary....@gmail.com

I've had a test install of v5 since early alphas. Now, it is time to 
upgrade my production install.
I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
couple of additional internet uploaders (Windy and WeatherCloud). I run two 
skins, Belchertown and weewx-wdc

All is and has been quite stable. So, I hesitate to poke at it. But, v5 is 
the new standard, so I need to get this done.

I don't see many who have trod this path. How to go about this?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com.

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

2024-02-21 Thread Thomas Hackler

thanks for the detailed help

I changed the order as you suggested

Do you mean that I should change this part in my weewx.conf:

[[StandardReport]]
skin = neowx-material

in

[Neowx-Material-Report]]
skin = neowx-material

Weewx will have no problem that there is no entrance [[StandardReport]] 
anymore ?

the reason of the different driver version could be that I got this driver 
from a german weather station forum and it is not a one from you.

https://www.pc-wetterstation.de/forum/viewtopic.php?f=26&t=10333

not all sensors where supported in the past and so this modified version 
were made

I plan to install a complete new and clean system for my raspberry pi, then 
I would go further with driver version 0.6.0
I hope that this cause no problems with the databse and all the things



gjr80 schrieb am Montag, 19. Februar 2024 um 05:45:00 UTC+1:

> That is a very good log extract. From that extract WeeWX seems to be 
> running just fine with no errors. The lines similar to:
> Feb 18 21:05:40 raspberrypi weewxd[35139]: DEBUG weewx.reportengine: 
> Cannot read localization file /etc/weewx/skins/neowx-material/lang/en.conf 
> for report 'StandardReport': Config file not found: 
> "/etc/weewx/skins/neowx-material/lang/en.conf".
> Feb 18 21:05:40 raspberrypi weewxd[35139]: DEBUG weewx.reportengine:  
> Using defaults instead.
> mean than an English language config file could not be found and the 
> defaults are being used instead. If your skin files are being generated in 
> the correct language you can ignore this.
>
> The neowx-material SyntaxWarnings are exactly that, a warning and do not 
> appear to be causing a problem. If they are causing a problem then you 
> should take this up with the neowx-material author.
>
> If your system is running error free and you are having problems viewing 
> current pages/plots in a browser the first thing to do is to clear the 
> browser cache. How you do this varies from browser to browser.
>
> A few additional comments. First you seem to have the neowx-material skin 
> being run under the StandardReport report. This is not a problem as the 
> report name merely needs to be a unique (compared to other report names) 
> string. However, considering that WeeWX ships with a skin called Standard 
> that is run under a report named StandardReport you might find it less 
> confusing (especially if you need outside help in the future) to give the 
> report that runs the neowx-material skin a more descriptive name, eg 
> Neowx-MaterialReport.
>
> The order of your enabled reports under [StdReport] in weewx.conf appears 
> to be SeasonsReport, FTP, StandardReport (which runs the neowx-material 
> skin). Again this runs without error, but it means you Seasons skin files 
> are generated, your files are uploaded by FTP then the neowx-material 
> skin files are generated. The result is that when the FTP report uploads 
> your files it uploads the just generated Seasons skin file, but it then 
> uploads the previously generated neowx-material skin files. In other 
> words, on you web server you will see the current Seasons skin files but 
> your neowx-material files will always be at least five minutes old. Under 
> [StdReport] the order of the report stanzas matters. I suspect you would 
> be better off changing the order of your enabled reports to SeasonsReport
> , StandardReport,FTP.
>
> Finally, your driver version is 0.4.2KW, I have no idea where you sourced 
> this driver from as I have never released such a version and have no idea 
> what modifications may have been made to the driver. The current Ecowitt 
> gateway (nee GW1000) driver is v0.6.0, so depending on your requirements 
> you might want source a more up to date version.
>
> Gary
> On Monday 19 February 2024 at 06:26:07 UTC+10 Thomas Hackler wrote:
>
>> Thomas Hackler schrieb am Sonntag, 18. Februar 2024 um 21:25:40 UTC+1:
>>
>>> ok thanks, I was not ready for version 5 and start reading the docs
>>> attached there is a 15 minutes log, I guess now is everything working
>>> My edge browser didn't show me the actual pictures from the season skin, 
>>> neo wx is working
>>> but firefox show me both
>>> thanks for the support and documentation (helps to learn a lot)
>>>
>>> gjr80 schrieb am Sonntag, 18. Februar 2024 um 11:01:53 UTC+1:
>>>
 A couple of things. First, you appear to be using systemd and if you 
 are running a WeeWX v5 Debian install you should be using systemctl 
  and 
 to start/stop and otherwise control the WeeWX service.

 Second, your log extract covers just over one minute with WeeWX already 
 running. That really is not enough log for us to be of any help. You need 
 to capture the full WeeWX startup, this contains important config 
 information. You also need a longer log extract, if your archive interval 
 is five minutes then we need to see at least 10 minutes of log.

 Gary

[weewx-user] SOLVED: WeeWX startup on Debian 12 Bookworm with Vantage Pro console using ethernet

2024-02-21 Thread Neil B

This may not be an issue you have encountered yet, but as it affected me, 
this post is for others who may have the same problem.

*Situation*: WeeWX 5.0.2 installed on vanilla Debian 12 (bookwork) with 
*fixed* IP address. Weatherstation hardware is Vantage Pro with an 
*ethernet* interface.

*Issue*: WeeWX fails to start and reports:

*Feb 21 13:53:05 SCADA weewxd[522]: INFO weewx.engine: Loading station type* 


























*Vantage (weewx.drivers.vantage)Feb 21 13:53:05 SCADA weewxd[522]: ERROR 
weewx.drivers.vantage: Socket error while opening port 2 to ethernet 
host >Feb 21 13:53:05 SCADA weewxd[522]: ERROR weewx.engine: Import of 
driver failed: [Errno 101] Network is unreachable (Feb 21 13:53:05 
SCADA weewxd[522]: CRITICAL weewx.engine:   Traceback (most recent 
call last):Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL weewx.engine: 
File "/usr/share/weewx/weewx/drivers/vantage.py",>Feb 21 13:53:05 
SCADA weewxd[522]: CRITICAL weewx.engine:  
 self.socket.connect((self.host, self.port))Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   OSError: [Errno 101] Network 
is unreachableFeb 21 13:53:05 SCADA weewxd[522]: CRITICAL weewx.engine: 
Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL weewx.engine:  
 During handling of the above exception, another exc>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine: Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   Traceback (most recent call 
last):Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL weewx.engine:    
 File "/usr/share/weewx/weewx/engine.py", line 115>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   self.console = 
loader_function(config_dict, sel>Feb 21 13:53:05 SCADA weewxd[522]: 
CRITICAL weewx.engine:  
>Feb 21 13:53:05 SCADA weewxd[522]: 
CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   return 
VantageService(engine, config_dict)Feb 21 13:53:05 SCADA weewxd[522]: 
CRITICAL weewx.engine:  
^^^Feb 21 13:53:05 SCADA weewxd[522]: 
CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   Vantage.__init__(self, 
**config_dict[DRIVER_NAM>Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL 
weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   self.port.openPort()Feb 
21 13:53:05 SCADA weewxd[522]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>Feb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL weewx.engine:   raise 
weewx.WeeWxIOError(ex)Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL 
weewx.engine:   weewx.WeeWxIOError: [Errno 101] Network is 
unreacha>Feb 21 13:53:05 SCADA weewxd[522]: CRITICAL __main__: Unable to 
load driver: [Errno 101] Network is unreachableFeb 21 13:53:05 SCADA 
weewxd[522]: CRITICAL __main__:   Exiting...Feb 21 13:53:05 SCADA 
systemd[1]: weewx.service: Main process exited, code=exited, 
status=4/NOPERMISSIONFeb 21 13:53:05 SCADA systemd[1]: weewx.service: 
Failed with result 'exit-code'.*

*Resolution*:

Even though the correct dependencies were set in the 'weewx.service' file, 
the network was not available in time.  I'd set a static IP address in the '
*/etc/network/interfaces*' file using the standard commands for this.

Solution involved adding an *UP SLEEP *command. Here is the example that 
works for me:

iface enp1s0 inet static
address 192.168.1.242/24
gateway 192.168.1.254
*up sleep 5*

Note: ENP1S0 is my LAN interface name.

Hope this helps any others who come across this.

Neil

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/46307069-8c55-4e58-a768-32e227290cb7n%40googlegroups.com.

[weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

Ville

Many thanks for your support.  As requested output of ls /dev/

is here:

DMac@WeeWX:~ $ ls /dev/
autofs   loop1 ram6tty24  tty58  vcsu1
blockloop2 ram7tty25  tty59  vcsu2
bsg  loop3 ram8tty26  tty6   vcsu3
btrfs-controlloop4 ram9tty27  tty60  vcsu4
bus  loop5 random  tty28  tty61  vcsu5
cachefiles   loop6 rfkill  tty29  tty62  vcsu6
cec0 loop7 rtc tty3   tty63  vcsu7
cec1 loop-control  rtc0tty30  tty7   vga_arbiter
char mappersda tty31  tty8   vhci
console  media0sda1tty32  tty9   vhost-net
cpu_dma_latency  media1serial  tty33  ttyAMA10   vhost-vsock
cuse media2serial0 tty34  ttyprintk  video19
disk mem   sg0 tty35  ttyUSB0video20
dma_heap mmcblk0   shm tty36  uhid   video21
dri  mmcblk0p1 snd tty37  uinput video22
fd   mmcblk0p2 spidev10.0  tty38  urandomvideo23
full mqueuestderr  tty39  v4lvideo24
fuse net   stdin   tty4   vantagevideo25
gpiochip0null  stdout  tty40  vcio   video26
gpiochip1port  tty tty41  vc-mem video27
gpiochip2ppp   tty0tty42  vcsvideo28
gpiochip3pps0  tty1tty43  vcs1   video29
gpiochip4ptmx  tty10   tty44  vcs2   video30
gpiomem0 ptp0  tty11   tty45  vcs3   video31
gpiomem1 pts   tty12   tty46  vcs4   video32
gpiomem2 ram0  tty13   tty47  vcs5   video33
gpiomem3 ram1  tty14   tty48  vcs6   video34
gpiomem4 ram10 tty15   tty49  vcs7   video35
hwrngram11 tty16   tty5   vcsa   video36
i2c-11   ram12 tty17   tty50  vcsa1  video37
i2c-12   ram13 tty18   tty51  vcsa2  watchdog
initctl  ram14 tty19   tty52  vcsa3  watchdog0
inputram15 tty2tty53  vcsa4  zero
kmsg ram2  tty20   tty54  vcsa5
kvm  ram3  tty21   tty55  vcsa6
log  ram4  tty22   tty56  vcsa7
loop0ram5  tty23   tty57  vcsu

Regards

Dave


On Wednesday 21 February 2024 at 12:49:42 UTC vhel...@gmail.com wrote:

> Hi,
>
> Plug the USB serial converter with weatherstation plugged to your RPI5.
> Check from linux terminal command: ls /dev/ to see is your logger there.
> Paste the results of: ls /dev/ here.
>
> -Ville-
>
>
> keskiviikko 21. helmikuuta 2024 klo 14.38.36 UTC+2 Dave McCreath kirjoitti:
>
>> Recently acquired an RPi 5 and decided this morning to migrate WeeWX over 
>> to it from an up to date RPi 4.
>>
>> Three attempts, all failed with the same errors.  I have tried with both 
>> the USB serial connector inserted and without.  I'm running the RPi 
>> headless over VNC and nothing else plugged into it at all apart from the 
>> power lead.
>>
>> *Log:*
>>
>>  2024-02-21T12:15:44.944885+00:00 WeeWX weectl[2869]: INFO weectllib: 
>> Initializing weectl version 5.0.2
>> 2024-02-21T12:15:44.945066+00:00 WeeWX weectl[2869]: INFO weectllib: 
>> Command line: /usr/share/weewx/weectl.py station reconfigure 
>> --config=/etc/weewx/weewx.conf --driver=weewx.drivers.vantage 
>> --units=metric --location=Leverington --latitude=52.693 --longitude=0.147 
>> --altitude=3,meter --register=y --station-url=
>> https://www.wunderground.com/dashboard/pws/ICAMBSLE2 --no-prompt 
>> --no-backup
>> 2024-02-21T12:15:44.945101+00:00 WeeWX weectl[2869]: ERROR 
>> weeutil.startup: Cannot load user extensions: No module named 'user'
>> 2024-02-21T12:15:44.974672+00:00 WeeWX weectl[2869]: INFO weectl-station: 
>> Using Vantage version 3.6.2 (weewx.drivers.vantage)
>> 2024-02-21T12:15:45.030191+00:00 WeeWX systemd[1]: Reloading.
>> 2024-02-21T12:15:45.848292+00:00 WeeWX systemd[1]: Reloading.
>> 2024-02-21T12:15:46.281844+00:00 WeeWX systemd[1]: Started weewx.service 
>> - WeeWX.
>> 2024-02-21T12:15:46.362945+00:00 WeeWX weewxd[3153]: INFO __main__: 
>> Initializing weewxd version 5.0.2
>> 2024-02-21T12:15:46.363060+00:00 WeeWX weewxd[3153]: INFO __main__: 
>> Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
>> 2024-02-21T12:15:46.371965+00:00 WeeWX weewxd[3153]: INFO __main__: Using 
>> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
>> 2024-02-21T12:15:46.372032+00:00 WeeWX weewxd[3153]: INFO __main__: 
>> Located at /usr/bin/python3
>> 2024-02-21T12:15:46.374175+00:00 WeeWX weewxd[3153]: INFO __main__: 
>> Platform Linux-6.1.0-rpi8-rpi-2712-aarch64-with-glibc2.36
>> 2024-02-2

[weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

2024-02-21 Thread vhel...@gmail.com

Hi,

Plug the USB serial converter with weatherstation plugged to your RPI5.
Check from linux terminal command: ls /dev/ to see is your logger there.
Paste the results of: ls /dev/ here.

-Ville-


keskiviikko 21. helmikuuta 2024 klo 14.38.36 UTC+2 Dave McCreath kirjoitti:

> Recently acquired an RPi 5 and decided this morning to migrate WeeWX over 
> to it from an up to date RPi 4.
>
> Three attempts, all failed with the same errors.  I have tried with both 
> the USB serial connector inserted and without.  I'm running the RPi 
> headless over VNC and nothing else plugged into it at all apart from the 
> power lead.
>
> *Log:*
>
>  2024-02-21T12:15:44.944885+00:00 WeeWX weectl[2869]: INFO weectllib: 
> Initializing weectl version 5.0.2
> 2024-02-21T12:15:44.945066+00:00 WeeWX weectl[2869]: INFO weectllib: 
> Command line: /usr/share/weewx/weectl.py station reconfigure 
> --config=/etc/weewx/weewx.conf --driver=weewx.drivers.vantage 
> --units=metric --location=Leverington --latitude=52.693 --longitude=0.147 
> --altitude=3,meter --register=y --station-url=
> https://www.wunderground.com/dashboard/pws/ICAMBSLE2 --no-prompt 
> --no-backup
> 2024-02-21T12:15:44.945101+00:00 WeeWX weectl[2869]: ERROR 
> weeutil.startup: Cannot load user extensions: No module named 'user'
> 2024-02-21T12:15:44.974672+00:00 WeeWX weectl[2869]: INFO weectl-station: 
> Using Vantage version 3.6.2 (weewx.drivers.vantage)
> 2024-02-21T12:15:45.030191+00:00 WeeWX systemd[1]: Reloading.
> 2024-02-21T12:15:45.848292+00:00 WeeWX systemd[1]: Reloading.
> 2024-02-21T12:15:46.281844+00:00 WeeWX systemd[1]: Started weewx.service - 
> WeeWX.
> 2024-02-21T12:15:46.362945+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Initializing weewxd version 5.0.2
> 2024-02-21T12:15:46.363060+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
> 2024-02-21T12:15:46.371965+00:00 WeeWX weewxd[3153]: INFO __main__: Using 
> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
> 2024-02-21T12:15:46.372032+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Located at /usr/bin/python3
> 2024-02-21T12:15:46.374175+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Platform Linux-6.1.0-rpi8-rpi-2712-aarch64-with-glibc2.36
> 2024-02-21T12:15:46.374268+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Locale: 'en_GB.UTF-8'
> 2024-02-21T12:15:46.374299+00:00 WeeWX weewxd[3153]: INFO __main__: Entry 
> path: /usr/share/weewx/weewxd.py
> 2024-02-21T12:15:46.374324+00:00 WeeWX weewxd[3153]: INFO __main__: 
> WEEWX_ROOT: /etc/weewx
> 2024-02-21T12:15:46.374352+00:00 WeeWX weewxd[3153]: INFO __main__: 
> Configuration file: /etc/weewx/weewx.conf
> 2024-02-21T12:15:46.374376+00:00 WeeWX weewxd[3153]: INFO __main__: User 
> module: /etc/weewx/bin/user
> 2024-02-21T12:15:46.374401+00:00 WeeWX weewxd[3153]: INFO __main__: Debug: 
> 0
> 2024-02-21T12:15:46.374584+00:00 WeeWX weewxd[3153]: INFO weewx.engine: 
> Loading station type Vantage (weewx.drivers.vantage)
> 2024-02-21T12:15:46.379577+00:00 WeeWX weewxd[3153]: ERROR weewx.engine: 
> Import of driver failed: [Errno 2] could not open port /dev/ttyUSB0: [Errno 
> 2] No such file or directory: '/dev/ttyUSB0' ( 'serial.serialutil.SerialException'>)
> 2024-02-21T12:15:46.382885+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   Traceback (most recent call last):
> 2024-02-21T12:15:46.384033+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine: File 
> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 322, in open
> 2024-02-21T12:15:46.384085+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   self.fd = os.open(self.portstr, os.O_RDWR | 
> os.O_NOCTTY | os.O_NONBLOCK)
> 2024-02-21T12:15:46.384112+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:    
>  ^^
> 2024-02-21T12:15:46.384136+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   FileNotFoundError: [Errno 2] No such file or 
> directory: '/dev/ttyUSB0'
> 2024-02-21T12:15:46.384173+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   
> 2024-02-21T12:15:46.384196+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   During handling of the above exception, another 
> exception occurred:
> 2024-02-21T12:15:46.384219+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   
> 2024-02-21T12:15:46.384240+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   Traceback (most recent call last):
> 2024-02-21T12:15:46.384261+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine: File "/usr/share/weewx/weewx/engine.py", line 
> 115, in setupStation
> 2024-02-21T12:15:46.384285+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:   self.console = loader_function(config_dict, 
> self)
> 2024-02-21T12:15:46.384311+00:00 WeeWX weewxd[3153]: CRITICAL 
> weewx.engine:  
> ^^
> 2024-02-21T12:15:46.384339+00:00 W

[weewx-user] Re: Install of WeeWX 5.0.2 on RPI 5 Failed

2024-02-21 Thread Neil B

I've just had a similar issue with the VANTAGE on Ethernet. All was fine 
with me on a Raspberry Pi 4, but I updated to a full Debian Bookwork mini 
PC over the weekend and now Weewx won't start. In a previous post Tom and 
others helped by putting in a file to allow the network to start before 
Weewx kicked in. However, on a fresh install on vanilla Debian, the 
directories/files don't exist as they did on the PI. This is my error log:

Feb 21 12:40:25 SCADA systemd[1]: Started weewx.service - WeeWX.
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Initializing weewxd 
version 5.0.2
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Command line: 
/usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Using Python 3.11.2 
(main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Located at 
/usr/bin/python3
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Platform 
Linux-6.1.0-18-amd64-x86_64-with-glibc2.36
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Locale: 'en_GB.UTF-8'
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Entry path: 
/usr/share/weewx/weewxd.py
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: WEEWX_ROOT: /etc/weewx
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Configuration file: 
/etc/weewx/weewx.conf
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: User module: 
/etc/weewx/bin/user
Feb 21 12:40:26 SCADA weewxd[520]: INFO __main__: Debug: 1
Feb 21 12:40:26 SCADA weewxd[520]: DEBUG __main__: Initializing engine
Feb 21 12:40:26 SCADA weewxd[520]: INFO weewx.engine: Loading station type 
Vantage (weewx.drivers.vantage)
Feb 21 12:40:26 SCADA weewxd[520]: DEBUG weewx.drivers.vantage: Driver 
version is 3.6.2
Feb 21 12:40:26 SCADA weewxd[520]: DEBUG weewx.drivers.vantage: Option 
loop_request=1
Feb 21 12:40:26 SCADA weewxd[520]: ERROR weewx.drivers.vantage: Socket 
error while opening port 2 to ethernet host >
Feb 21 12:40:26 SCADA weewxd[520]: ERROR weewx.engine: Import of driver 
failed: [Errno 101] Network is unreachable (
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 Traceback (most recent call last):
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 self.socket.connect((self.host, self.port))
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 OSError: [Errno 101] Network is unreachable
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: 
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:   During 
handling of the above exception, another exc>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: 
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 Traceback (most recent call last):
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/engine.py", line 115>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 self.console = loader_function(config_dict, sel>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 return VantageService(engine, config_dict)
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
^^^
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 Vantage.__init__(self, **config_dict[DRIVER_NAM>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 self.port.openPort()
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/drivers/vantage.py",>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 raise weewx.WeeWxIOError(ex)
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL weewx.engine:  
 weewx.WeeWxIOError: [Errno 101] Network is unreacha>
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL __main__: Unable to load 
driver: [Errno 101] Network is unreachable
Feb 21 12:40:26 SCADA weewxd[520]: CRITICAL __main__:   Exiting...
Feb 21 12:40:26 SCADA systemd[1]: weewx.service: Main process exited, 
code=exited, status=4/NOPERMISSION
Feb 21 12:40:26 SCADA systemd[1]: weewx.service: Failed with result 
'exit-code'.

On Wednesday 21 February 2024 at 12:38:36 UTC Dave McCreath wrote:

> Recently acquired an RPi 5 and decided this morning to migrate WeeWX over 
> to it from an up to date RPi 4.
>
> Three attempts, all failed wi

[weewx-user] Install of WeeWX 5.0.2 on RPI 5 Failed