Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[Thomas Hackler]

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

[vince]

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 :-)

[Thomas Hackler]

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]

Perhaps this setting (link) is something to try if you want to experiment and let us know if it works…

[gary....@gmail.com]

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.

[vince]

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)

[gjr80]

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 

[vince]

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)

#---------

[Tom Keffer]

Yes, there was a bug, but it was fixed by Gary back in February. PR #935. To appear whenever we get a new version out.

-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/0372f1da-9c54-4e2c-a608-7d971737b81fn%40googlegroups.com.

[vince]

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 ?

[Tom Keffer]

Done.

Some of the issues are packaging issues, so we'd best wait.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/72775f47-36c0-4dfe-8dee-a00b7551eb71n%40googlegroups.com.