gw1000 driver fail on wifi loss

[vince]

Gary - I wanted to pass along some logs from a gw1000 driver abort yesterday.

I had my home network down for a bit yesterday to do some firmware updates on my Ubiquiti USG, Switch and AcLite access point and weewx aborted rather quickly.

The external, wired, and wifi networks were indeed down for some minutes so missing some readings was expected, but I was hopeful that the driver would recover gracefully after things were back up,  however weewx totally aborted and the process was gone.

Just passing along the logs in case you wanted to take a look.  Thanks.

Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts

Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain live sensor data

Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop exiting. Shutting engine down.

Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down StdReport thread

Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut down StdReport thread

Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts

Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain live sensor data

Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector thread has been terminated

Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught WeeWxIOError: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts

Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:     ****  Waiting 60 seconds then retrying...

Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...

Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration file /etc/weewx/weewx.conf

Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0

Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station type GW1000 (user.gw1000)

Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts

Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts (<class 'user.gw1000.GW1000IOError'>)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****  Traceback (most recent call last):

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/weewx/engine.py", line 109, in setupStation

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      self.console = loader_function(config_dict, self)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 1293, in loader

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      return Gw1000Driver(**config_dict[DRIVER_NAME])

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 1568, in __init__

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      super(Gw1000Driver, self).__init__(**stn_dict)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 767, in __init__

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      debug_wind=self.debug_wind)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 1870, in __init__

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      lost_contact_log_period=lost_contact_log_period)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2276, in __init__

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      self.mac = self.get_mac_address()

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2407, in get_mac_address

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      return self.send_cmd_with_retries('CMD_READ_STATION_MAC')

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2532, in send_cmd_with_retries

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****      raise GW1000IOError(_msg)

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:     ****  user.gw1000.GW1000IOError: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL __main__: Unable to load driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts

Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL __main__:     ****  Exiting...

[gjr80]

Vince,

Thank you. From memory the driver should retry continuously when the network returns if loop_on_init = True in weewx.conf (though I am not sure I tested this by turning of my network). Can you confirm the loop_on_init setting at the time?

Gary

[vince]

(unsure if this blasted google groups new interface ate my draft reply - grrrrrr...)

loop_on_init was not set at all, so it's sure acting like the default is False.

I'll define it as True for the next time, which hopefully won't need testing for a long time....

Thanks.

[gjr80]

That would explain the behaviour then, if loop_on_init is not set the loss of connectivity with the station (for whatever reason) will cause WeeWX to exit as it does with any other driver. I will make a point of pulling the network on my GW1000 and confirming the driver and loop_on_init work as expected.

Gary

[Graham Eddy]

suggestion: gw1000 install set loop_on_init to true by default. we will always have this kind of problem when the wifi (re)starts and weewx races ahead of it

[Rainer Lang]

I had the same issue like Vince the other day - and .... loop_on_init hadn't been set by the install script...
I assume it's to set in the [GW1000] stanza - that's where I added it now.

-------- Forwarded Message --------

Subject:	[weewx-user] Re: gw1000 driver fail on wifi loss
Date:	Sun, 27 Dec 2020 13:12:19 -0800 (PST)
From:	gjr80 <gjrod...@gmail.com>
Reply-To:	weewx...@googlegroups.com
To:	weewx-user <weewx...@googlegroups.com>

That would explain the behaviour then, if loop_on_init is not set the loss of connectivity with the station (for whatever reason) will cause WeeWX tobeen exit as it does with any other driver. I will make a point of pulling the network on my GW1000 and confirming the driver and loop_on_init work as expected.

--
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/230141dd-4b09-4fab-8798-776d46028592n%40googlegroups.com.

[gjr80]

> loop_on_init hadn't been set by the install script...

Did you run wee_config —reconfigure to reconfigure WeeWX to use the GW1000 driver after installing the driver? wee_config —reconfigure will ask if you want to set loop_on_init. If you did run wee_config —reconfigure did you set loop_on_init or not? Did the resulting setting in weewx.conf agree without you4 selection?

loop_on_init is a general WeeWX option set in the top level of weewx.conf. It is covered under General in The configuration file weewx.conf section in the Users Guide. Placing it in [GW1000] will have no effect.

Gary

[vince]

FWIW - I didn't do it via wee_config here, which likely explains what I got as a result.

I tend to install weewx with --no-prompt which defines using the simulator, then add the extension/driver, then hand-edit weewx.conf to point to the other driver once I get everything else edited in there.  Admittedly, that's not following the expected procedure I guess, but it does explain how I got my result here.

[gjr80]

I think the install instructions are clear and concise. At the end of the day if you choose not to follow them a degree of caveat emptor applies. I believe the current loop_on_init setting is appropriate and see no need to change it (experience shows if I did then the ‘stop polluting my logs’ brigade will start complaining).

Of course anyone is free to fork the driver...

Gary

[vince]

Agree.

Also thanks for the reminder re: wee_config --reconfigure. I had not seen magic buried in a driver that asked questions when you reconfigure.  That kinda blows up scripted installs to some extent for folks like me who use --no-prompt a lot.

These might be nits but I thought I'd mention them:

• If you use the --no-prompt switch to wee_config you get only a partial stanza installed (I didn't check the code to see if this matters or not).  You might want to consider having it write out all the items if this matters.

• init_on_loop gets added right under the version string in weewx.conf with no comment or whitespace.  That might be easy to overlook later on.

• uninstalling the driver leaves the init_on_loop item in weewx.conf.  Admittedly, it is unusual to uninstall a driver as folks would just use wee_config to point to a different one (if they follow the instructions that is :-)

But the driver has been rock solid for me here, so it's of course much appreciated.

[gjr80]

Comments below.

Gary

On Monday, 28 December 2020 at 11:22:30 UTC+10 vince wrote:

Agree.

Also thanks for the reminder re: wee_config --reconfigure. I had not seen magic buried in a driver that asked questions when you reconfigure.  That kinda blows up scripted installs to some extent for folks like me who use --no-prompt a lot.

A number of the drivers use it (eg, vantage asks for hardware interface). Worth the extra effort where you want some user input. Only problem is it’s only available via wee_config and you need to get the user to go the extra step. 

These might be nits but I thought I'd mention them:

• If you use the --no-prompt switch to wee_config you get only a partial stanza installed (I didn't check the code to see if this matters or not).  You might want to consider having it write out all the items if this matters.

Will look at that. The aim in such cases is to exit with a working install, even if some of the settings are not to the users liking. 

• init_on_loop gets added right under the version string in weewx.conf with no comment or whitespace.  That might be easy to overlook later on.

Will look at that too, Tom’s configobj lesson from a few days ago might help. I was under the impression that we were fairly limited in the comments and formatting we could programmatically add to a config file. Tom showed otherwise.

• uninstalling the driver leaves the init_on_loop item in weewx.conf.  Admittedly, it is unusual to uninstall a driver as folks would just use wee_config to point to a different one (if they follow the instructions that is :-)

Bit difficult to handle that one as wee_extension will not know anything about loop_on_init and if using wee_config to configure a new driver you get the new driver’s config prompts (which may or may not include loop_on_init). Might end up being another step in the uninstall procedure.