Done. Some of the issues are packaging issues, so we'd best wait.
On Tue, Apr 9, 2024 at 5:07 PM vince <vinceska...@gmail.com> wrote: > Cool - thanks. Would it be possible to add the log.info() to always log > its settings ? That might make some more "did you set this true" support > threads a little quicker. > > Also given Matthew is kinda out of pocket for personal/work reasons, would > it be possible to get a 5.0.next out there for pip users ? Or does the > to-do list include code as well as packaging things ? > > On Tuesday, April 9, 2024 at 4:58:52 PM UTC-7 Tom Keffer wrote: > >> Yes, there was a bug, but it was fixed by Gary back in February. PR #935 >> <https://github.com/weewx/weewx/pull/935>. To appear whenever we get a >> new version out. >> >> -tk >> >> >> On Tue, Apr 9, 2024 at 4:22 PM vince <vince...@gmail.com> wrote: >> >>> I was thinking systemd would be a more general purpose way, but maybe >>> that's just frustration here with loop_on_init not working. >>> >>> In poking around more I think there's a bug in weewxd.py - I can't find >>> an incantation that actually sets loop_on_init to what's set in the .conf >>> file. I added some log.info around the statements in weewxd.py and it >>> always gets set False no matter what I do. >>> >>> This patch works though... >>> >>> #--------- >>> ### >>> ### # If no command line --loop-on-init was specified, look in the >>> config file. >>> ### if namespace.loop_on_init is None: >>> ### loop_on_init = to_bool(config_dict.get('loop_on_init', False)) >>> ### else: >>> ### loop_on_init = namespace.loop_on_init >>> ### >>> #--------- >>> >>> # If command line --loop-on-init was specified use that >>> if namespace.loop_on_init is True: >>> loop_on_init = namespace.loop_on_init >>> else: >>> # look in the config file, failing safe to False >>> loop_on_init = to_bool(config_dict.get('loop_on_init', False)) >>> >>> # always log its setting >>> log.info("loop_on_init: %s", loop_on_init) >>> >>> #--------- >>> >>> >>> On Tuesday, April 9, 2024 at 2:55:32 PM UTC-7 gjr80 wrote: >>> >>>> The more I think of it the more I don't see the benefit of this >>>> approach over using loop_on_init in weewx.conf in dealing with this >>>> type of problem. Setting loop_on_init = True will cause WeeWX to >>>> reload the driver after (the default) three consecutive attempts to contact >>>> the gateway device fail; WeeWX continues running the entire time. Perhaps >>>> if some sort of network or device initialisation sat in the WeeWX core >>>> there might be a benefit, but all of that sits solely in the driver (as far >>>> as I am aware this is the case with all drivers). If the network or the >>>> device is in such a state that communication with the device via the API is >>>> not possible then no amount of WeeWX restarts or driver reloads will >>>> correct the situation. >>>> >>>> It seems to me that forcing a WeeWX restart via systemd is a somewhat >>>> heavy handed approach. >>>> >>>> My opinion only and I expect others will have a different view. >>>> >>>> Gary >>>> >>>> On Wednesday 10 April 2024 at 06:00:37 UTC+10 vince wrote: >>>> >>>>> update - my ecowitt instance crashed out on me during a several minute >>>>> network outage while I was updating firmware on the router/switch/ap so >>>>> I'm >>>>> trying this solution to see how well that works. Thanks. >>>>> >>>>> (not a bug in the gw1000 driver - it did exactly what it's configured >>>>> to do. It tried 3x with 2 sec in between. An alternate workaround would >>>>> be to try 1000x with a minute in between to basically get through any >>>>> reasonable network outages for the LAN, but I want to try the systemd >>>>> method as a more generic fix) >>>>> >>>>> On Tuesday, March 26, 2024 at 7:56:12 AM UTC-7 gary....@gmail.com >>>>> wrote: >>>>> >>>>>> I have added these lines to my weewx service file for just such an >>>>>> instance. >>>>>> Add under StandardError=journal+console entry in the [Service] stanza >>>>>> >>>>>> Restart=on-failure >>>>>> RestartSec=30 >>>>>> >>>>>> Restarts weewx after waiting for 30 seconds to allow whatever >>>>>> interfered to (hopefully) clear. >>>>>> >>>>>> On Monday, March 25, 2024 at 6:26:44 PM UTC-4 vince wrote: >>>>>> >>>>>>> Perhaps this setting (link) >>>>>>> <https://unix.stackexchange.com/questions/564443/what-does-restart-on-abort-mean-in-a-systemd-service> >>>>>>> is >>>>>>> something to try if you want to experiment and let us know if it works… >>>>>>> >>>>>>> On Monday, March 25, 2024 at 3:11:41 PM UTC-7 Thomas Hackler wrote: >>>>>>> >>>>>>>> thank you for the answer, then it was maybe soemthing wrong with >>>>>>>> the wifi >>>>>>>> >>>>>>>> does it make sense to increase the attempts before exit ? >>>>>>>> >>>>>>>> I try to find something to check if the process is running >>>>>>>> I have some experience with monit, so maybe I find an example or >>>>>>>> anything else >>>>>>>> >>>>>>>> >>>>>>>> vince schrieb am Montag, 25. März 2024 um 22:09:58 UTC+1: >>>>>>>> >>>>>>>>> I have also seen my gw1000 weewx setup abort on the pi4 >>>>>>>>> occasionally when the wifi network bounces for some reason. Mine's >>>>>>>>> been up >>>>>>>>> for 6 weeks now so it is definitely a transient kind of thing. >>>>>>>>> >>>>>>>>> Writing yourself a little cron job to look for the weewxd process >>>>>>>>> and if it's not there restart it wouldn't be too tough to do. >>>>>>>>> Perhaps >>>>>>>>> there is some systemd configuration magic that is possible, but I'm >>>>>>>>> not >>>>>>>>> sure there what a safe+effective way to leverage systemd would look >>>>>>>>> like. >>>>>>>>> I know how cron works :-) >>>>>>>>> >>>>>>>>> On Monday, March 25, 2024 at 1:56:10 PM UTC-7 Thomas Hackler wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> my weewx stopped yesterday unexpected. The last logs are >>>>>>>>>> attached. It ran stable for over 1 week. I have restarts of my >>>>>>>>>> raspberry pi >>>>>>>>>> with cron every 1 or 2 days. What is the reason that the gw1000 >>>>>>>>>> driver has >>>>>>>>>> suddenly a problem? How can I avoid it in future? Should I increase >>>>>>>>>> the >>>>>>>>>> attemps if there is a short problem with the wifi connection? >>>>>>>>>> It is a problem of my gw1000 device? I see no problems with the >>>>>>>>>> ecowitt app. >>>>>>>>>> Thank you! >>>>>>>>>> Regards >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>> -- >>> 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/0372f1da-9c54-4e2c-a608-7d971737b81fn%40googlegroups.com >>> <https://groups.google.com/d/msgid/weewx-user/0372f1da-9c54-4e2c-a608-7d971737b81fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/72775f47-36c0-4dfe-8dee-a00b7551eb71n%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/72775f47-36c0-4dfe-8dee-a00b7551eb71n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPq0zEDWfGESOyNL4QPh7ThOcwGGuH9ZpUk9f8E2z78Fmu0xKw%40mail.gmail.com.
