[weewx-user] Re: AWEKAS Upload & Healthchecks.io both stop working this morning

[Dave Piehl]

Try the link again. I left it unlisted by mistake. Thanks!

On Monday, April 8, 2024 at 9:19:50 PM UTC-5 gjr80 wrote:

> Don't know if I'm getting special treatment or not, but your link doesn't 
> work for me. Just paste the log here, I'm sure Google has sufficient spare 
> storage.
>
> Gary
>
> On Tuesday 9 April 2024 at 11:07:57 UTC+10 david...@gmail.com wrote:
>
>> I moved to Weewx 5 on my Raspberry Pi several weeks ago and all has 
>> seemed fine. Suddenly this morning after a restart due to a problem with my 
>> Vantage Console relay, both have stopped working.
>>
>> Here's a debug log for about 10 minutes this evening: 
>> https://pastebin.com/passmailer
>>
>> On start up both a still showing as starting but nothing after that.
>>
>> I did notice "sudo weectl extension list" returns a strange response for 
>> Healthchecks even after uninstalling and reinstalling the extension:
>>
>> Using configuration file /etc/weewx/weewx.conf
>> Extension NameVersion   Description
>> Belchertown   1.3.1 A clean modern skin with real time streaming 
>> updates and interactive charts. Modeled after BelchertownWeather.com
>>
>> *Healthchecks  ???   Cannot find 'install' module in 
>> /etc/weewx/bin/user/installer/Healthchecks*mqtt  0.24 
>>  Upload weather data to MQTT server.
>> owm   0.9   Upload weather data to OpenWeatherMap.
>> windy 0.7   Upload weather data to Windy.
>>
>> I'd appreciate any help or direction to getting to the source of these 
>> issues. Thanks!
>>
>

-- 
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/6f351e5a-c57c-4bab-a251-c3995758961en%40googlegroups.com.

Re: [weewx-user] show old nooa data in pulldown

[simon]

Hello Tom,

I have test it this weekend and it have work.
Thanks for your support 😀

Tom Keffer schrieb am Sonntag, 31. März 2024 um 15:23:45 UTC+2:

> Unfortunately, there is no easy way to do this. The list of months is 
> generated dynamically when the reports are run.
>
> If you are familiar with HTML, something you could do is modify the select 
> statement in the template titlebar.inc to include the extra dates. For 
> example, say you had extra months 2010-08 and 2010-09, contained in files 
> NOAA/NOAA-2010-08.txt and  NOAA/NOAA-2010-09.txt, respectively. When done, 
> this would look like (NOT TESTED):
>
> 
>   2010-08
>   2010-09
>   #for $monthYear in $SummaryByMonth
>   $monthYear
>   #end for
>   - $gettext("select month") -
> 
>
> This would make the extra dates available in the drop down list.
>
> On Sun, Mar 31, 2024 at 4:12 AM simon  wrote:
>
>> hello all, i have old nooa txt files with datas which are not in the 
>> database.
>> is it possible to bring the old files into the pulldown menu to select 
>> them ?[image: weewx nooa.png] 
>>
>> -- 
>> 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/4d41dea9-4785-43d9-b67e-2c7c34c659b8n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/1a2a0634-f8da-4f15-8a98-bb8c588e9642n%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: AWEKAS Upload & Healthchecks.io both stop working this morning

[Dave Piehl]

Let's try again. This is the link to the log: https://pastebin.com/aZ05aSLW

On Tuesday, April 9, 2024 at 5:58:43 AM UTC-5 Dave Piehl wrote:

> Try the link again. I left it unlisted by mistake. Thanks!
>
> On Monday, April 8, 2024 at 9:19:50 PM UTC-5 gjr80 wrote:
>
>> Don't know if I'm getting special treatment or not, but your link doesn't 
>> work for me. Just paste the log here, I'm sure Google has sufficient spare 
>> storage.
>>
>> Gary
>>
>> On Tuesday 9 April 2024 at 11:07:57 UTC+10 david...@gmail.com wrote:
>>
>>> I moved to Weewx 5 on my Raspberry Pi several weeks ago and all has 
>>> seemed fine. Suddenly this morning after a restart due to a problem with my 
>>> Vantage Console relay, both have stopped working.
>>>
>>> Here's a debug log for about 10 minutes this evening: 
>>> https://pastebin.com/passmailer
>>>
>>> On start up both a still showing as starting but nothing after that.
>>>
>>> I did notice "sudo weectl extension list" returns a strange response for 
>>> Healthchecks even after uninstalling and reinstalling the extension:
>>>
>>> Using configuration file /etc/weewx/weewx.conf
>>> Extension NameVersion   Description
>>> Belchertown   1.3.1 A clean modern skin with real time streaming 
>>> updates and interactive charts. Modeled after BelchertownWeather.com
>>>
>>> *Healthchecks  ???   Cannot find 'install' module in 
>>> /etc/weewx/bin/user/installer/Healthchecks*mqtt  0.24 
>>>  Upload weather data to MQTT server.
>>> owm   0.9   Upload weather data to OpenWeatherMap.
>>> windy 0.7   Upload weather data to Windy.
>>>
>>> I'd appreciate any help or direction to getting to the source of these 
>>> issues. Thanks!
>>>
>>

-- 
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/22a06545-3682-48e8-a31a-811a9f8599een%40googlegroups.com.

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

Re: [weewx-user] Re: AWEKAS Upload & Healthchecks.io both stop working this morning

[Tom Keffer]

Classic case of corrupt memory in the Vantage logger. See *Corrupt station
memory
*
in
the wiki.

On Tue, Apr 9, 2024 at 1:31 PM Dave Piehl  wrote:

> Let's try again. This is the link to the log:
> https://pastebin.com/aZ05aSLW
>
> On Tuesday, April 9, 2024 at 5:58:43 AM UTC-5 Dave Piehl wrote:
>
>> Try the link again. I left it unlisted by mistake. Thanks!
>>
>> On Monday, April 8, 2024 at 9:19:50 PM UTC-5 gjr80 wrote:
>>
>>> Don't know if I'm getting special treatment or not, but your link
>>> doesn't work for me. Just paste the log here, I'm sure Google has
>>> sufficient spare storage.
>>>
>>> Gary
>>>
>>> On Tuesday 9 April 2024 at 11:07:57 UTC+10 david...@gmail.com wrote:
>>>
 I moved to Weewx 5 on my Raspberry Pi several weeks ago and all has
 seemed fine. Suddenly this morning after a restart due to a problem with my
 Vantage Console relay, both have stopped working.

 Here's a debug log for about 10 minutes this evening:
 https://pastebin.com/passmailer

 On start up both a still showing as starting but nothing after that.

 I did notice "sudo weectl extension list" returns a strange response
 for Healthchecks even after uninstalling and reinstalling the extension:

 Using configuration file /etc/weewx/weewx.conf
 Extension NameVersion   Description
 Belchertown   1.3.1 A clean modern skin with real time
 streaming updates and interactive charts. Modeled after
 BelchertownWeather.com

 *Healthchecks  ???   Cannot find 'install' module in
 /etc/weewx/bin/user/installer/Healthchecks*mqtt  0.24
  Upload weather data to MQTT server.
 owm   0.9   Upload weather data to OpenWeatherMap.
 windy 0.7   Upload weather data to Windy.

 I'd appreciate any help or direction to getting to the source of these
 issues. Thanks!

>>> --
> 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/22a06545-3682-48e8-a31a-811a9f8599een%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEA94k68Nyo3m-uoEc%3DP6XmtBJiJs3UAtO1X-we5kpGoqg%40mail.gmail.com.

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

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 ran

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 i

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 U

[weewx-user] Export Meteobridge db as csv, import into WeeWX as csv

[William B]

I have a couple years worth of data that is stored on my Meteobridge 
NanoSD's database. I want to export that data and import it into WeeWX's 
database.

I have created a custom export for Meteobridge (
https://pastebin.com/dg7weFe7) that exports everything I could find that 
has matching columns in the WeeWX DB. Sample of the CSV that was created (
https://pastebin.com/gkvWRBwP). I have also created a custom WeeWX CSV 
import config (https://pastebin.com/UL7iFex0) to import all of that.

Just want someone to double check that that looks good before I import 
years of data in 1 minute intervals.

-- 
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/58df2a8e-1653-43d1-ba5b-063bbdd06143n%40googlegroups.com.

[weewx-user] rtgd dont auto update after lost contact from sensor to console

[Δημήτρης Βήχος]

i notice that, every time who i have lost contact the sensor with the 
console, after the connection back again, weewx  (the seasons skin )  
updates data again , but rtgd (the gauge-data.txt )  no. 
only with weewx restarting rtgd works again. 

-- 
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/71d1cbbb-4f6e-4638-957b-16014a817e91n%40googlegroups.com.