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+unsubscr...@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.

Reply via email to