Suggestion to weewx after booting with gw1000 driver

[Vetti52]

My Weewx installation was updated to version 4.4.0 using

sudo apt-get update
sudo apt-get install weewx

under debian buster on a Raspberry Pi 4. The driver is gw1000 version 0.2.0.

After rebooting my Raspberry Pi (this happens only about once or twice a year), I realized, that weewx was not running. After systemctl status weewx.service (which actually evokes /etc/init.d/weewx status) I was confronted with the message

Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      debug_wind=self.debug_wind)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2166, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      lost_contact_log_period=lost_contact_log_period)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2915, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      ip_port_list = self.discover()
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 3005, in discover
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      socket_obj.sendto(packet, (self.broadcast_address, self.broadcast_port))
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****  OSError: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: Unable to load driver: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__:     ****  Exiting...

After some investigation, I realized, that weewx was not exiting but still running. So I had first to stop it and could then start it without any issues. I suppose, that while invoking weewx during boot time from the /etc/init.d/weewx script, the network is not yet up. However, the gw1000 driver relies on an existing network and therefore blocks any further actions of weewx, which remains running.

I would therefore propose, to replace the init.d script by a weewx.service directive instead.

I realized meanwhile, that there is a /etc/weewx/weewx.service file version from 02.02.2020, which is currently not enabled. There are three stanza entries

[Unit]

Requires=time-sync.target
After=time-sync.target
RequiresMountsFor=/home

which I don't know, what they are supposed for, but I think, that for stability reason, it should have at least this additional the stanza in

[Unit]

After=network-online.target

and maybe taylor the rest of this file, and after enabling it, take systemctl start weeww.service as the regular starting process, instead of the /etc/init.d/weewx script.

What speaks against this proposal, or, why is the init.d version still preferably established?

-Peter

[gjr80]

I make no comment on systemd or service files but if loop_on_init is set True in weewx.conf and the GW1000 driver is being used as a driver WeeWX should recover from the lack of a network on startup. 

On WeeWX startup when loading the GW1000 driver the GW1000 driver does need to contact the GW1000 concerned before allowing WeeWX to continue startup. If there is no network connection the GW driver will raise a critical error (as shown in the log extract above) and WeeWX will exit. If loop_on_init is set True WeeWX should restart in 60 seconds (default) and the GW1000 driver will attempt contact again. If loop_on_init is not set True WeeWX will exit. This is standard behaviour in many drivers. If the GW1000 driver is not exhibiting this behaviour it is a bug and I would appreciate full details so it can be fixed.

Gary

[vince]

Peter - the gw1000 has at least two watchdog timers in it, and will reboot without being able to contact both the NTP and Web servers at Ecowitt for too long a period.  There is some discussion on wxforum.net regarding how to set up your own LAN services to fake it out.   Multiple people including me have asked Ecowitt to give us a way to disable their watchdogs, but they have declined to agree to do that.  They just respond with the same information saying how the user can impersonate their servers with some DNS and webserver sleight of hand.

[gjr80]

Different but I guess related issue. WeeWX/GW1000 driver will happily connect to the GW1000 wether the GW1000 has internet connectivity or not. Any data will be at best sporadic or, in some cases, next to useless but the lack of internet does not prevent WeeWX/GW1000 driver operation per se.

Gary

[Vetti52]

Thanks for the comments.  I checked weewx.conf for all "loop" entries, no loop_on_init exists. So, by default, is it set to false? Shouldn't it be generally enabled for gw1000 driver?

I wonder, why weewx could not be started after exiting. To me, this indicates, that it was in fact still running in this status for more than 30 minutes. I could stop it, which took some seconds, and then start it again. At that stage the network was up and running, so everything worked well. As I reboot the Raspberry very rarely, next time I might have forgotten about this problem with the gw1000 and the Raspberry Pi after reboot. As the gw1000 itself is continuously running and sending the data without interruption to ecowitt, thus showing valid data on the WsView dashboard, I might not check, that weewx does not receive data then. I'm getting old....

If loop_on_init would also solve this issue, and additionally the problem of a temporarily missing network connection to gw1000, this would indeed overcome my solution with weewx.service, which only works at startup.

As the Raspberry Pi has to serve some other services (cups, home assistant, Unifi), I am not very happy with the idea to inspect weewx/gw1000 after repeated reboots. Especially, if I do not exactly know, which protocols have to be logged and evaluated. I could even assume, that at next time, the network might have started slightly faster, so this issue will not always be observable by chance. So, there should be a well defined environment for testing, which I currently don't have.

Meanwhile, before I forget about it, I will enable weewx.service modified with the Stanza mentioned above.

-Peter

[gjr80]

Peter,

Some comments below.

Gary

On Tuesday, 9 February 2021 at 06:40:28 UTC+10 Vetti52 wrote:

Thanks for the comments.  I checked weewx.conf for all "loop" entries, no loop_on_init exists. So, by default, is it set to false?

Correct, the default setting is False and loop_on_init is not explicitly included in a new weewx.conf, the user needs to add it.

 

Shouldn't it be generally enabled for gw1000 driver?

I guess that comes down to the user. As of v0.1.0b11 the user is prompted to set loop_on_init when using wee_config --reconfigure to re-configure WeeWX to use the  GW1000 driver as a driver (refer to v0.1.0b11 release notes), though those having installed an earlier version of the GW1000 driver would not need to run wee_config again and hence would not be prompted to set loop_on_init. I could force loop_on_init to True in the GW1000 extension installer but as that would apply to those using the GW1000 driver as a driver as well as those using the GW1000 driver as an extension but have chosen not to as those using it as a service may not wish to have loop_on_init set True.

I wonder, why weewx could not be started after exiting. To me, this indicates, that it was in fact still running in this status for more than 30 minutes.

I couldn't say, the definitive check at the time would have been been to do:

$ ps -aux | grep weewx

to see what if any WeeWX processes remained running.

 

I could stop it, which took some seconds, and then start it again. At that stage the network was up and running, so everything worked well. As I reboot the Raspberry very rarely, next time I might have forgotten about this problem with the gw1000 and the Raspberry Pi after reboot. As the gw1000 itself is continuously running and sending the data without interruption to ecowitt, thus showing valid data on the WsView dashboard, I might not check, that weewx does not receive data then. I'm getting old....

If loop_on_init would also solve this issue, and additionally the problem of a temporarily missing network connection to gw1000, this would indeed overcome my solution with weewx.service, which only works at startup.

As the Raspberry Pi has to serve some other services (cups, home assistant, Unifi), I am not very happy with the idea to inspect weewx/gw1000 after repeated reboots. Especially, if I do not exactly know, which protocols have to be logged and evaluated. I could even assume, that at next time, the network might have started slightly faster, so this issue will not always be observable by chance. So, there should be a well defined environment for testing, which I currently don't have.

Meanwhile, before I forget about it, I will enable weewx.service modified with the Stanza mentioned above.

 I guess either approach will solve the problem you experienced, certainly manually checking on the state of WeeWX/GW1000 driver after boot/WeeWX startup is not a practical approach.

 

-Peter

[Vetti52]

Thanks, Gary for the confirmation.

Of course I am accustomed to check the processes running with ps, and occasionally kill one if needed. But at that time, I didn't even think about it. Maybe, because many of the services run within a docker container.

In deed, I did not run wee_config --reconfigure, because I first run gw1000 as a service, besides interceptor (which is kind of stupid, as both data came from the same source). I did then replace interceptor with gw1000 driver, after I had detected

[StdCalibrate]
    [[Corrections]]
        radiation = luminosity/126.7 if luminosity is not None else None

which finally resulted in exactly the same data as those from interceptor. I did not put an eye on loop_on_init then, although I should have....

BTW, in the user guide it is said to set the option to "1", not to "True". I guess, "True" will work as well.

We will see, if all works, when I need to reboot again. In a year, or so...

-Peter

[gjr80]

On Tuesday, 9 February 2021 at 23:56:24 UTC+10 Vetti52 wrote:

BTW, in the user guide it is said to set the option to "1", not to "True". I guess, "True" will work as well.

Correct, I am so used to just using True or False I never mention 1 or 0 but both forms are fine.

Gary

[Vetti52]

There is another nice "solution", although from a different approach:

in https://groups.google.com/g/weewx-user/c/7RO3UytAonA/m/3dJGZ9ogBQAJ

kilo...@gmail.com wrote:

----------------------------------------

Like WFS... I also created a systemd service so that I could add the  Requires=time-sync.target, which worked to delay the start but then caused problems during upgrading of weewx with apt.  So I figured out how to do this with the default init.d script.

1.  $sudo systemctl enable systemd-time-wait-sync

2.  Add time-sync.target to your default /etc/init.d/weewx script like I show below.

### BEGIN INIT INFO

# Provides:          weewx

# Required-Start:    $local_fs $remote_fs $syslog systemd-time-wait-sync

3.   $sudo systemctl daemon-reload

----------------------------------------  

As systemd-time-wait-sync needs a network connection, this will have the same effect, but using the init.d script. And, in addition, it prevents some problems with upgrading weewx (depending on systemd  using weewx.service?).

-Peter