weewx v5.0.1 upgrade problem

[Mks Mk]

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]

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]

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]

sudo apt install weewx=4.10.2

[Dominic Reich]

'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]

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]

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]

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

[matthew wall]

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]

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]

@ 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]

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]

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]

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]

@ 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]

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]

@ 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]

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?

[Mks Mk]

Pierre-Yves

we used these commands

sudo apt remove weewx

then
sudo apt install weewx=4.10.2-1

[Jeff A. D.]

Is your database being updated?

[Philip Wolff]

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]

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]

@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]

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:

    https://manpages.ubuntu.com/manpages/noble/en/man1/authbind.1.html

stack overflow and superuser have details about CAP_NET_BIND_SERVICE:

    https://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-on-linux

    https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443

serverfault shows how to do the iptables redirect:

    https://serverfault.com/questions/112795/how-to-run-a-server-on-port-80-as-a-normal-user-on-linux

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]

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]

@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]

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]

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]

https://www.weewx.com/docs/5.0/upgrade/#weewx-runs-as-the-weewx-user

[matthew wall]

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

https://github.com/weewx/weewx/wiki/Understanding-permissions

[Tom Keffer]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/dd907df7-2022-4381-a8f8-914d545ae175n%40googlegroups.com.

[vince]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/50c1b895-a3eb-49c0-bf03-f02966436a24n%40googlegroups.com.

[vince]

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 th