weewx v5.0.1 upgrade problem

899 views
Skip to first unread message

Mks Mk

unread,
Feb 6, 2024, 4:29:56 AMFeb 6
to weewx-user
The system was running weewx v5.0.0 with no issue then we did the upgrade to v5.0.1 (sudo apt update) and weewx failed to run.
we downgraded weewx to v5.0.0 but it did not work this time, so we went back to v4.10.2 and it run just fine.
did the upgrade again and got the same error.so we are back to v4.10.2
we tested the sdr hardware using rtl_433 and it is working fine.
we are not sure of what to do next!

log:
weewxd[2386]: INFO __main__: Starting up weewx version 5.0.1
weewxd[2386]: INFO weewx.engine: Using binding 'wx_binding' to database 'weewx.sdb'
weewxd[2386]: INFO weewx.manager: Starting backfill of daily summaries
weewxd[2386]: INFO weewx.manager: Daily summaries up to date
weewxd[2386]: INFO weewx.engine: Starting main packet loop.
weewxd[2386]: ERROR user.sdr: rtl_433 version 23.11-41-g06b03b7a branch master at 202402051043 inputs file rtl_tcp RTL-SDR
weewxd[2386]: ERROR user.sdr: Use "-F log" if you want any messages, warnings, and errors in the console.
weewxd[2386]: ERROR user.sdr: usb_open error -3
weewxd[2386]: ERROR user.sdr: Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules
weewxd[2386]: INFO weewx.engine: Main loop exiting. Shutting engine down.
weewxd[2386]: INFO user.sdr: shutdown process rtl_433 -f 433.7M -s 1024k -R 40
weewxd[2386]: Exception in thread stdout-thread:
weewxd[2386]: Traceback (most recent call last):
weewxd[2386]:   File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
weewxd[2386]: Exception in thread stderr-thread:
weewxd[2386]: Traceback (most recent call last):
weewxd[2386]:   File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
weewxd[2386]:     self.run()
weewxd[2386]:   File "/etc/weewx/bin/user/sdr.py", line 197, in run
weewxd[2386]:     for line in iter(self._fd.readline, ''):
weewxd[2386]: ValueError: PyMemoryView_FromBuffer(): info->buf must not be NULL
weewxd[2386]:     self.run()
weewxd[2386]:   File "/etc/weewx/bin/user/sdr.py", line 197, in run
weewxd[2386]:     for line in iter(self._fd.readline, ''):
weewxd[2386]: ValueError: PyMemoryView_FromBuffer(): info->buf must not be NULL
weewxd[2386]: INFO user.sdr: shutdown complete
weewxd[2386]: CRITICAL __main__: Caught WeeWxIOError: rtl_433 process is not running
weewxd[2386]: CRITICAL __main__:     ****  Waiting 60.0 seconds then retrying...

Stefanos Kalaitzis

unread,
Feb 6, 2024, 4:36:52 AMFeb 6
to weewx...@googlegroups.com

I had the same error with sdr driver(weewx v5 )  running on debian 12 . The problem solved by making udev rules ... maybe you are in the same situation as i was.


--
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/4c62d6c3-d690-49e8-8151-8b9af8dd5b43n%40googlegroups.com.

Stefan Gliessmann

unread,
Feb 6, 2024, 7:02:38 AMFeb 6
to weewx-user
I run weewx 4.10.2 on Ubuntu.
I did an sudo apt update, too,  and weewx 5.x got installed.
Since then, weewx is no longer running.

How did you revert back to weewx 4.10.2? 

TIA,
Stefan

michael.k...@gmx.at

unread,
Feb 6, 2024, 7:07:52 AMFeb 6
to weewx-user

sudo apt install weewx=4.10.2

Dominic Reich

unread,
Feb 6, 2024, 7:43:43 AMFeb 6
to weewx...@googlegroups.com
'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

>
>sudo apt install weewx=4.10.2

and to not upgrade again set it on hold:

sudo apt-mark hold weewx
>weewx-user/3eff3ae3-8343-437e-a259-ae24753baa61n%40googlegroups.com.


--
If you tell the truth, you don't have to remember anything.
- Mark Twain

Stefan Gliessmann

unread,
Feb 6, 2024, 7:57:25 AMFeb 6
to weewx...@googlegroups.com
Thanks a lot!
I will try this later ;)


You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/5BuR3BSQfeY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/%24kwshnkklb-%24RmhmQzk-%24qdrNT-2024%40odin.oe7drt.com.

Tom Keffer

unread,
Feb 6, 2024, 8:35:19 AMFeb 6
to weewx...@googlegroups.com
If you look in your log, you'll see that the rtl_433 process failed to run because of permissions problems. The log also suggests fixing the problem by installing the udev rules file "rtl-sir:rules". You can find this rules file in the rtl-sdr repository: https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules

V4.10 ran as user "root". Fresh V5 installs run as user "weewx", which may not have the permissions necessary to access your device. The rules file gives it these permissions.

Alternatively, you could change your install to run under "root".

--

Pierre-Yves

unread,
Feb 6, 2024, 10:05:42 AMFeb 6
to weewx-user
Hello all,

I just upgraded from 4.10 .2 to 5.0.1 and I seem to experiment a similar behavior. I run weewx on a RPi4.

As Tom explained above, I put rtl-sdr.rules in udev directory and restarted but no change
 
I tried to downgrade using "sudo apt install weewx=4.10.2" but that doesn't work :

:~ $ sudo apt install weewx=4.10.2
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances      
Lecture des informations d'état... Fait
E: La version « 4.10.2 » de « weewx » n'a pu être trouvée ??

Now I am stuck

Below the log when weewx 5.0.1 is started.

Any idea ?

Thanks, Pierre-Yves
upgrade 4-10-2 to 5-0-1-log

matthew wall

unread,
Feb 6, 2024, 10:23:15 AMFeb 6
to weewx-user
when you install rtl-sdr, it typically, but not always, installs udev rules for *many* sdr devices.  the udev rules that it installs make it possible for anyone in the 'plugdev' group to read/write to the sdr device.  (this is true when you install rtl-sdr from source - if you install rtl-sdr from a deb/rpm package, it might be different - anyone with this configuration please let us know)

weewx v4 runs as root:root, so it has access to the sdr device no matter what the udev rules might be

weewx v5 runs as weewx:weewx (for a deb/rpm install) or as a regular non-root user (for pip installs).  so udev rules are required.

btw, weewx 5.0.1 *always* converts to weewx:weewx, whereas 5.0.0 did not (it would continue to run as root - we changed in 5.0.1 because overall security and best practice)

the udev rules installed by rtl-sdr will not help for a deb/rpm install, since the user 'weewx' is not in the plugdev group.  you can either added the user weewx to the plugdev group, or modify the udev rules to use 'weewx' instead of 'plugdev' as the group.  this is how to do the former:

sudo usermod -aG plugdev weewx

for a pip install, be sure that the user running weewx is in the 'plugdev' group.

restart of the weewxd daemon is almost certainly required so that the daemon process has the right group.  reboot is not necessary.

m

Tom Hogland

unread,
Feb 6, 2024, 11:09:36 AMFeb 6
to weewx-user
In case anyone else runs into this - my Ubuntu server/Davis VP2 and serial datalogger had ownership set to root:dialout, so I had to add the weewx user to the dialout group for things to work. 

Pierre-Yves

unread,
Feb 6, 2024, 11:38:24 AMFeb 6
to weewx-user
@ Matthew,

Thanks a lot for the feedback.

It seems to be a problem of rules change. In fact, I first upgraded from 4.10.2 to 5.0.0 and weewx worked perfectly. Then I went from 5.0.0 to 5.0.1 an weewx failed to start.

For Weewx,, I did a deb/rpm install and, as far I remember, I installed rtl-sdr following your Git (https://github.com/matthewwall/weewx-sdr).

I tried the command you proposed (sudo usermod -aG plugdev weewx) but that doesn't solve the problem.

Regarding the rtl-sdr rules, I have a doubt. I installed the file in /etc/weewx/udev/rules.d. Maybe it is a wrong place... I read in another thread that it should be in /usr/lib/udev/rules.d... What about ?

Pierre-Yves

Stefanos Kalaitzis

unread,
Feb 6, 2024, 12:10:40 PMFeb 6
to weewx-user
I use a nooelec rtl-sdr.  On a fresh install  of bookworm 64bit in a Raspberry pi 4 and weewx v5  i solved the error like this:
i run  lsusb
and i saw a line similar to this 
 Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp.

**  "0bda" is the vendor id and "2838" is the product id (maybe yours are different)**

then i made a new file as root in  /etc/udev/rules.d/rtl-sdr.rules
next i modifyed this: sudo nano  /etc/udev/rules.d/rtl-sdr.rules
and i added this line :
 SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"  

hope this will help you 

matthew wall

unread,
Feb 6, 2024, 12:11:07 PMFeb 6
to weewx-user
On Tuesday, February 6, 2024 at 11:38:24 AM UTC-5 Pierre-Yves wrote:
It seems to be a problem of rules change. In fact, I first upgraded from 4.10.2 to 5.0.0 and weewx worked perfectly.

weewx was running as root:root. weewx 5.0.0 did not modify any permissions when it upgraded from 4.10.2.
 
Then I went from 5.0.0 to 5.0.1 an weewx failed to start.

weewx was running as weewx:weewx.  weewx 5.0.1 converts from root:root permissions to weewx:weewx permissions, and runs the daemon as weewx.
 
For Weewx,, I did a deb/rpm install and, as far I remember, I installed rtl-sdr following your Git (https://github.com/matthewwall/weewx-sdr).

I tried the command you proposed (sudo usermod -aG plugdev weewx) but that doesn't solve the problem.

is there a udev rules file for sdr?  (it is a separate step when you build rtl-sdr from source)
if there is a udev rules file for sdr, how are the permissions set?
did the usermod for weewx succeed?
is weewx in the plugdev group?  (grep weewx /etc/group)
did you restart weewxd after putting weewx into the plugdev group?
 
Regarding the rtl-sdr rules, I have a doubt. I installed the file in /etc/weewx/udev/rules.d. Maybe it is a wrong place... I read in another thread that it should be in /usr/lib/udev/rules.d... What about ?

packages install to /usr/lib/udev/rules.d

system administrators (or end-users acting as system administrators) put things in /etc/udev/rules.d

that way you can override whatever a package installs, and your changes will not be overwritten by the package when you upgrade/update.
 

Stefanos Kalaitzis

unread,
Feb 6, 2024, 12:17:07 PMFeb 6
to weewx-user
i forgot to write in my last message  that when you finished you must restart udev or restart the device you using( p.c , rpi ,... etc)

Pierre-Yves

unread,
Feb 6, 2024, 12:32:36 PMFeb 6
to weewx-user
@ Matthew, thanks. I need now to "digest" all this information, it's a bit high level for me ;-)

@ Stefanos, thanks too, I tested my USB SDR key and obtain the same result as yours : "Bus 003 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T"

Pierre-Yves

Mks Mk

unread,
Feb 6, 2024, 1:44:41 PMFeb 6
to weewx-user
we just tried the upgrade again to weewx  v5.0.1 (sudo apt update) and it worked this time.
(we have not done any changes to the system after the downgrade to v4.10.2) 

Pierre-Yves

unread,
Feb 6, 2024, 2:13:38 PMFeb 6
to weewx-user
@ Mks Mk,
Which command did you use to perform the downgrade from v5to v4.10.2 ?
I tried "sudo apt install weewx=4.10.2" and "sudo apt install weewx 4.10.2" but none of these work...

Thanks, Pierre-Yves

Philip Wolff

unread,
Feb 6, 2024, 2:23:35 PMFeb 6
to weewx-user
Thanks for that tip - it got me off the ground. All is now well except that /var/www/html/weewx hasn't been updated since just before I did the upgrade to 5.0.1. Anyone else seeing this?
Message has been deleted

Mks Mk

unread,
Feb 6, 2024, 2:31:56 PMFeb 6
to weewx-user
Pierre-Yves
we used these commands
sudo apt remove weewx
then
sudo apt install weewx=4.10.2-1

Jeff A. D.

unread,
Feb 6, 2024, 3:26:37 PMFeb 6
to weewx-user
Is your database being updated?

Philip Wolff

unread,
Feb 6, 2024, 3:56:40 PMFeb 6
to weewx...@googlegroups.com
Yes, and data is being sent to CWOP and Wunderground. 

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/5BuR3BSQfeY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/872b0b73-d942-487d-bbe3-61883e3d00aen%40googlegroups.com.

gjr80

unread,
Feb 6, 2024, 4:00:36 PMFeb 6
to weewx-user
Impossible to say what the issue is with such a short log extract. Please edit weewx.conf, set debug =1, save weewx.conf and restart WeeWX. Let WeeWX run for at least two archive intervals and then take a log extract showing the full WeeWX startup through until the two archive intervals have elapsed. Post the log extract here.

Gary 

František Slimařík

unread,
Feb 7, 2024, 12:57:45 AMFeb 7
to weewx-user
@Matthew:
Any clue what should be modified (udev rules/group membership) for interceptor driver? When I modify systemctl service to not run under weewx:weewx everything is OK :)

Feb  6 19:37:43 rocky-weather-machine weewxd[1612889]: INFO weewx.engine: Loading station type Interceptor (user.interceptor)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: INFO user.interceptor: driver version is 0.53
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: INFO user.interceptor: device type: observer
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: INFO user.interceptor: mode is listen
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: INFO user.interceptor: listen on :80
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: ERROR weewx.engine: Import of driver failed: [Errno 13] Operace zamítnuta (<class 'PermissionError'>)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****  Traceback (most recent call last):
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/usr/share/weewx/weewx/engine.py", line 115, in setupStation
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      self.console = loader_function(config_dict, self)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/etc/weewx/bin/user/interceptor.py", line 315, in loader
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      return InterceptorDriver(**config_dict[DRIVER_NAME])
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/etc/weewx/bin/user/interceptor.py", line 2522, in __init__
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      self._device = self.DEVICE_TYPES.get(self._device_type)(**stn_dict)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/etc/weewx/bin/user/interceptor.py", line 1285, in __init__
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      Observer.Parser(), handler=Observer.Handler, **stn_dict)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/etc/weewx/bin/user/interceptor.py", line 429, in __init__
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      self._server = Consumer.TCPServer(address, port, handler)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/etc/weewx/bin/user/interceptor.py", line 584, in __init__
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      TCPServer.__init__(self, (address, int(port)), handler)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/usr/lib64/python3.6/socketserver.py", line 456, in __init__
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      self.server_bind()
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****    File "/usr/lib64/python3.6/socketserver.py", line 470, in server_bind
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****      self.socket.bind(self.server_address)
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL weewx.engine:     ****  PermissionError: [Errno 13] Operace zamítnuta
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL __main__: Unable to load driver: [Errno 13] Operace zamítnuta
Feb  6 19:37:44 rocky-weather-machine systemd[1]: weewx.service: Main process exited, code=exited, status=4/NOPERMISSION
Feb  6 19:37:44 rocky-weather-machine weewxd[1612889]: CRITICAL __main__:     ****  Exiting...
Feb  6 19:37:44 rocky-weather-machine systemd[1]: weewx.service: Failed with result 'exit-code

Dne úterý 6. února 2024 v 22:00:36 UTC+1 uživatel gjr80 napsal:

matthew wall

unread,
Feb 7, 2024, 2:03:53 AMFeb 7
to weewx-user
Frantisek,

udev rules are for devices - USB or serial, not for network ports.

the permissions error you are experiencing is probably due the fact that you are trying to listen on (bind to) port 80.  only root is allowed to bind to ports lower than 1024.

assuming that you are on a linux system, your options include:
- run as root:root
- listen on a higher port (only works if you can change the port on whatever is sending data)
- use authbind to let weewx:weewx bind to port 80
- use iptables to REDIRECT traffic from port 80 to a high port
- use CAP_NET_BIND_SERVICE

here is the man page for authbind:


stack overflow and superuser have details about CAP_NET_BIND_SERVICE:



serverfault shows how to do the iptables redirect:


m

On Wednesday, February 7, 2024 at 12:57:45 AM UTC-5 xsli...@gmail.com wrote:
@Matthew:
Any clue what should be modified (udev rules/group membership) for interceptor driver? When I modify systemctl service to not run under weewx:weewx everything is OK :)

matthew wall

unread,
Feb 7, 2024, 2:08:46 AMFeb 7
to weewx-user
another option is to put a proxy in front of interceptor.  configure interceptor to listen on a high port, say 8080, then run nginx binding to port 80 as a reverse proxy to interceptor, proxying all traffic or just specific requests.

m

František Slimařík

unread,
Feb 7, 2024, 2:14:41 AMFeb 7
to weewx...@googlegroups.com
@Matthew:

That makes sense yep. Thanks a lot for detailed explanation. I cannot change port 80 on my hardware so I will review other options :)

st 7. 2. 2024 v 8:08 odesílatel matthew wall <mwall...@gmail.com> napsal:
another option is to put a proxy in front of interceptor.  configure interceptor to listen on a high port, say 8080, then run nginx binding to port 80 as a reverse proxy to interceptor, proxying all traffic or just specific requests.

m

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/5BuR3BSQfeY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e8a748e8-5008-4ecc-b5f2-59fad26e8b67n%40googlegroups.com.

Steve Gee

unread,
Feb 7, 2024, 11:16:48 AMFeb 7
to weewx-user
I ended up adding the weewx user to the plughw group which fixed the problem with rtl_433 not starting:

sudo adduser weewx plughw
sudo systemctl restart weewx.service

Tom Keffer

unread,
Feb 7, 2024, 11:58:36 AMFeb 7
to weewx...@googlegroups.com
I'll add "plughw" to the troubleshooting section.

-tk

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/3239d8e8-5e87-420a-a660-74666b1847ben%40googlegroups.com.

Tom Keffer

unread,
Feb 7, 2024, 11:59:59 AMFeb 7
to weewx...@googlegroups.com

matthew wall

unread,
Feb 7, 2024, 2:49:54 PMFeb 7
to weewx-user
On Wednesday, February 7, 2024 at 11:58:36 AM UTC-5 tke...@gmail.com wrote:
I'll add "plughw" to the troubleshooting section.

tom, i have added sections to the 'permissions' wiki page with details like this one.  i suspect we will see more, since this is not specific to rtl-sdr, nor  is it specific to DEB/RPM install vs pip install.  m


Tom Keffer

unread,
Feb 7, 2024, 3:34:01 PMFeb 7
to weewx...@googlegroups.com
I would add "dialout" as well.

--
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.

vince

unread,
Feb 7, 2024, 4:01:37 PMFeb 7
to weewx-user
Matthew - agree with adding group dialout.  Fortunately the raspi has the default user in that group already which is why serial-connected VP2 worked with no additions required for me (via serial2USB dongle).  I think I sent you guys some email mentioning that back in the pre-release testing back and forth a few weeks ago.

Mks Mk

unread,
Feb 8, 2024, 4:40:18 AMFeb 8
to weewx-user
today tried to update my other raspberry pi to weewx v5.01 and this pi is different than the main weather pi that we use:
1-bme280 sensor.
2-sdr
3-weewx-wxobs skin.


after the weewx update we did the following:
sudo usermod -aG dialout weewx

sudo usermod -aG plugdev weewx
sudo systemctl restart udev weewx

but weewx v5.01 failed with following errors:
-PermissionError: [Errno 13] Permission denied: '/dev/i2c-1', this error related to bme280 sensor
running this command "sudo usermod -aG i2c weewx" fixed the issue.

-PermissionError: [Errno 13] Permission denied: '/usr/share/php/wxobs_weewx.inc', this error related to weewx-wxobs skin
we are using apache2, doing these changes fixed the issue (thanks to glennmckechnie)
mkdir /etc/weewx/wxobs-tmp
chown weewx.weewx /etc/weewx/wxobs-tmp

edited skin.conf located in /etc/weewx/skins/wxobs/ and uncommenting line #30 and changing include_path = '/tmp' to become include_path = '/etc/weewx/wxobs-tmp'

weewx v5.01 is running ok now on this raspberry pi, hoping the above step may help someone during the upgrade to weewx v5.01

Pierre-Yves

unread,
Feb 8, 2024, 5:00:36 AMFeb 8
to weewx-user
Thanks a lot, very interesting !

Yesterday, as I failed to have weewx 5.1 working properly, I reverted to 4.10.2.

My configuration is very similar :
- BME280 sensor
- AS3953 lightning sensor
- SDR driver
- Seasons skin
- Belchertown skin

I am tempted to give a new try...

Pierre-Yves

Vetti52

unread,
Feb 8, 2024, 4:57:38 PMFeb 8
to weewx-user
After updating to from v5.0.0 to v5-0.1I got this log entry:
Feb 05 14:59:07 raspbee systemd[1]: weewx.service: Deactivated successfully.
Feb 05 14:59:07 raspbee systemd[1]: Stopped weewx.service - WeeWX.
Feb 05 14:59:07 raspbee systemd[1]: weewx.service: Consumed 27min 28.104s CPU time.
Feb 05 14:59:39 raspbee systemd[1]: Started weewx.service - WeeWX.
Feb 05 14:59:45 raspbee weewxd.py[7015]: windy: version is 0.6
Feb 05 14:59:45 raspbee weewxd.py[7015]: windy: Data will be uploaded to https://stations.windy.com/pws/update
Feb 05 15:00:25 raspbee weewxd[7015]: 2024-02-05 15:00:25 xCreatePipe: Can't set permissions (436) for //.lgd-nfy0, Die Operation ist nicht erlaubt
Feb 05 15:00:25 raspbee weewxd[7015]: /usr/lib/python3/dist-packages/gpiozero/devices.py:295: PinFactoryFallback: Falling back from lgpio: [Errno 2] Datei oder Verzeichnis nicht gefunden: '.>
Feb 05 15:00:25 raspbee weewxd[7015]:   warnings.warn(
Feb 05 15:00:26 raspbee weewxd.py[7015]: historygenerator.py: Generated 5 tables in 0.15 seconds


Although since then Weewx runs fine,  I doubt, that everything works ok. After reading this thread, I decided to chown root.weewx for .lgd.nfy0. Hope, that is, what it should be.
I did my upgrade from v4.10.2 according to the user guide for version 4, thus install weewx, stop it, copy all files and directories back, as listed in the user guide, just edited weewx.conf to match my old configuration and started weewx. However, after detecting the "new" user guide for version 5, I was no longer sure, that this was the proper way. With the latest update to v5.0.1 there is some hope, that at least the permissions are clean now. Except of this one.

Tom Keffer

unread,
Feb 8, 2024, 5:09:13 PMFeb 8
to weewx...@googlegroups.com
I have no idea what ".lgd-fy0" is, but it should probably be owned by weewx:weewx. 

I'm not sure what "v4 upgrade process" you're referring to. You certainly did not have to offload any files. Same with the v5 upgrade. 

The owner of the weewxd process had changed from "root" to "weewx", but the configuration file has not changed at all. A V4.10.2 config file can be used without change in V5.

vince

unread,
Feb 8, 2024, 5:32:03 PMFeb 8
to weewx-user
See if https://forums.raspberrypi.com/viewtopic.php?t=345917 helps any for your gpio issue.

Again here, what user and group is weewx running as? That user needs correct permissions to be able to access your attached hardware. My guess is that you need to add the weewx user to the same groups the default pi user is in.

Vetti52

unread,
Feb 9, 2024, 6:47:59 AMFeb 9
to weewx-user
Concerning my v4 update process I should add some clarification:
My Raspi crashed due to a SD card failure, which suddenly change it to read only mode completely. Thus I had an "unerasable backup copy". I took a brand new SD card,  installed a brand new Raspian image with Bookworm lite and installed a brand new Weewx (among others, such as lighttpd, docker-home assiastant, and mosquitto). I removed the zigbee gpio extension board, as the raspi had to move into another room, where the Zigbee signal is not available and therefore an original Ikea gateway had to be installed.) Thus I do not need the GPIO any longer, I thought. So I don't know, what the gpio thing is actually good for, concerning Weewx.
 
After installation of Weewx I stopped it and restored weewx data as excellently described in the user's guide weewx.com/docs/4.10/usersguide.htm#Restoring_from_backup.
After this, I realized, that I had installed version 5.0.0 now. So I read the version 5 guide, and was afraid, that I messed up with my setup. I then manually copied the user data to /etc/weewx/bin/user, and btw downloaded gw1000.py to the latest version, and checked all /etc/weewx files for weewx.weewx permission. I diffed weewx.conf with weewx.conf-5.0.0 and adopted all changes. I removed the mqtt plugin, because of the paho error (I know, there is a solution for it) and as I do not use it any longer, because there is an addon in home assistant to read Ecowitt data directly. So, everything worked without any problems. Now, when v5.0.1 came out, I upgraded and, again, it worked without any problems. I checked the permissions, which are set to weewx.weewx for all files in /etc/weewx and subfolders and also for the the folder /var/lib/weewx and its files forecast.sdb and weewx.sdb. I have seen, that the "old" user folder was renamed to user-<DateTime> and the new folder is used now. 
Once again, I edited weewx.conf, version = 5.0.1 as it still said 5.0.0. Previously this was updated automagically.

Guessing to add weewx to all groups, pi has joined: It is a whole bunch!!! Would it be ok, to add it to the users and gpio group?

Thanks
Peter

vince

unread,
Feb 9, 2024, 12:22:37 PMFeb 9
to weewx-user
If you do not need gpio for weewx, do not install anything related to gpio in your weewx.conf file.  Seems pretty simple to me.

Vetti52

unread,
Feb 9, 2024, 5:16:09 PMFeb 9
to weewx-user
As I don't know anything related to gpio, I was wondering, what may be related to weewx. Aside of gw1000, forecast and zambretti, I do not have installed anything else in weewx.conf.

As I plan to move to a raspi5 in a couple of months, I am considering to come back to a Zigbee (or Matter) gateway. Then I might install a RaspBee II GPIO board, which has the additional advantage of a battery buffered RTC. This might make some GW1000 issues easier, and the GPIO thing may then come up again. So, for now, I let it as is and don't worry.

tarob...@gmail.com

unread,
Mar 2, 2024, 10:25:01 AMMar 2
to weewx-user
This solved my problem, adding user ‘weewx’ to the ‘plugdev’ group using the usermod command.

'sudo usermod -aG plugdev weewx'

On Tuesday, February 6, 2024 at 10:23:15 AM UTC-5 matthew wall wrote:
when you install rtl-sdr, it typically, but not always, installs udev rules for *many* sdr devices.  the udev rules that it installs make it possible for anyone in the 'plugdev' group to read/write to the sdr device.  (this is true when you install rtl-sdr from source - if you install rtl-sdr from a deb/rpm package, it might be different - anyone with this configuration please let us know)

weewx v4 runs as root:root, so it has access to the sdr device no matter what the udev rules might be

weewx v5 runs as weewx:weewx (for a deb/rpm install) or as a regular non-root user (for pip installs).  so udev rules are required.

btw, weewx 5.0.1 *always* converts to weewx:weewx, whereas 5.0.0 did not (it would continue to run as root - we changed in 5.0.1 because overall security and best practice)

the udev rules installed by rtl-sdr will not help for a deb/rpm install, since the user 'weewx' is not in the plugdev group.  you can either added the user weewx to the plugdev group, or modify the udev rules to use 'weewx' instead of 'plugdev' as the group.  this is how to do the former:

sudo usermod -aG plugdev weewx

Invisible Man

unread,
Mar 3, 2024, 10:18:52 AMMar 3
to weewx-user
Thanks, I was missing the "-1" at the end, that solved my problem I managed to downgrade.

sudo apt install weewx=4.10.2-1

Axelle.
Reply all
Reply to author
Forward
0 new messages