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 <https://github.com/gjr80/weewx-gw1000/releases/tag/v0.1.0b11>), 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 > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/7699fe53-3699-4260-9a46-6c4952c87f6bn%40googlegroups.com.
