Re: [weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[Tom Keffer]

Done.

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

On Tue, Apr 9, 2024 at 5:07 PM vince  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
>> . To appear whenever we get a
>> new version out.
>>
>> -tk
>>
>>
>> On Tue, Apr 9, 2024 at 4:22 PM vince  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)
>>> 
>>>  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 

Re: [weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[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 ?

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 
> . To appear whenever we get a 
> new version out.
>
> -tk
>
>
> On Tue, Apr 9, 2024 at 4:22 PM vince  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) 
>> 
>>  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 

Re: [weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[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


On Tue, Apr 9, 2024 at 4:22 PM vince  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)
> 
>  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 

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

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

#-


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

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[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 

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) 
>>> 
>>>  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/78dcf514-66b7-4bfe-b2e7-62208d382425n%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

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

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) 
>> 
>>  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/86de5170-efec-40a3-91ae-56b184117179n%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[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.

On Monday, March 25, 2024 at 6:26:44 PM UTC-4 vince wrote:

> Perhaps this setting (link) 
> 
>  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/ef87a5ba-2185-4d09-8f79-d2882d7e358en%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[vince]

Perhaps this setting (link) 

 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/0ad581b5-8ae0-4d26-84e3-bbf6c87cbdecn%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[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 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/2832f239-3a1b-404a-9904-bc6f7a00aa6cn%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

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

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/c220117e-b402-4e2a-a749-9e1117949eden%40googlegroups.com.