GW1000.py crashing when attempting to rediscover GW1000

135 views
Skip to first unread message

Dr__Bob

unread,
Mar 15, 2022, 2:42:02 PM3/15/22
to weewx-user
Hi.  From time to time, it seems like my GW1000 disappears.  It looks like the code is trying to rediscover it, but in the process hits a bug in the code and crashes.  This is with weewx 4.5.1 with python 3.7.3 and GW1000 0.41.  The syslog looks like:

Mar 15 04:14:45 raspberrypi weewx[1374] ERROR user.gw1000: Failed to obtain response to command 'CMD_READ_SENSOR_ID_NEW' after 3 attempts

Mar 15 04:14:45 raspberrypi weewx[1374] INFO user.gw1000: Attempting to re-discover GW1000...

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  Traceback (most recent call last):

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3587, in get_sensor_id

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      return self.send_cmd_with_retries('CMD_READ_SENSOR_ID_NEW')

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3740, in send_cmd_with_retries

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      raise GW1000IOError(_msg)

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  user.gw1000.GW1000IOError: Failed to obtain response to command 'CMD_READ_SENSOR_ID_NEW' after 3 attempts

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  During handling of the above exception, another exception occurred:

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  Traceback (most recent call last):

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3024, in run

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      self.client.collect_sensor_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 2476, in collect_sensor_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      queue_data = self.get_live_sensor_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 2525, in get_live_sensor_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      self.update_sensor_id_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 2538, in update_sensor_id_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      sensor_id_data = self.station.get_sensor_id()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3591, in get_sensor_id

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      if not self.rediscover():

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3928, in rediscover

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****    File "/usr/share/weewx/user/gw1000.py", line 3928, in <listcomp>

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****      gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:     ****  TypeError: not enough arguments for format string


I *think* the bug is on line 3928 in rediscover(self):

gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

This looks like a copy of the similar line further up in the code where the GW1000 is first discovered.  I'm a complete python newbie, but it looks like the second join in the above line wants two fields but is only getting one.  Shouldn't it be ".join(['%s' % (b['ip_address'],b['port'])])"?  That's the way the first version of gw1000_str is formed.

Cheers,

Bob Clare 

gjr80

unread,
Mar 16, 2022, 2:27:27 AM3/16/22
to weewx-user
Thanks for spotting that, device_list is a list of dicts so line 3928 was never going to work. I am surprised it has not shown up previously, though it is buried in some code that is seldom used. You almost have the fix correct, but '%s' should be '%s:%d' to give the IP address:port number format. There are also a couple of other changes further down from line 3298 that will also need to be made. I should have an update in the next few days; the rediscovery code is complex and I want to make sure sure it is functioning properly (now) - testing of the rediscovery code is time consuming.

In the meantime, are you operating your device with a fixed IP allocation? If possible that is the recommended way to use the GW1x00 devices with the GW1000 driver.

Gary

Dr__Bob

unread,
Mar 16, 2022, 1:56:34 PM3/16/22
to weewx-user
Hi Gary,

Thanks for looking into this!  Yeah, my "fix" was just me typing away in the message, so I indeed did miss the extra ":%d". My coding may be bad, but it ain't *that* bad! :-)  
I had, up to now, the ip address for the GW1000 set to auto.  I have an atrociously difficult to manage Spectrum router (which I should replace with a better one) that doesn't have a web interface to manage it, but rather an app.  IP allocation on that app is difficult to find, but I did find it, and now I have changed weewx.conf to have a fixed ip address for the GW1000.  Will that change anything if weewx again loses contact with the GW1000?

Thanks,

Bob

gjr80

unread,
Mar 16, 2022, 11:39:29 PM3/16/22
to weewx-user
Bob,

The GW100 driver uses discovery only if an IP address for your device is not specified in weewx.conf and then only in two general areas. First is during startup; the driver will broadcast to the network and the first device that responds will be used. The driver identifies and keeps track of the device being used by MAC address. If no device provides a valid response WeeWX will either exit or retry in 60 seconds (the default value) depending on how WeeWX is configured. The second time discovery is used is if the driver loses contact with the device (this usually occurs if the device does not respond to a command after three (the default value) attempts). In this case the driver broadcasts again looking for a device with the same MAC address as previously noted. If found the driver updates, if required, the IP address and port used to contact the device. If the same MAC cannot be found WeeWX will either exit or retry in 60 seconds depending on how WeeWX is configured. If an IP address is specified discovery is never used.

Other than discovery there is no difference between how the driver handles a device whether an IP address is specified or not. Experience has shown that sometimes discovery has been unreliable and hence the preference for specifying an IP address.

Gary

gjr80

unread,
Mar 20, 2022, 2:15:03 AM3/20/22
to weewx-user
Just to tidy this up I have released the GW1000 driver v0.4.2 that fixes this issue.

Gary

Dr__Bob

unread,
Aug 18, 2022, 11:28:28 AM8/18/22
to weewx-user
Just to complete this:  I have now verified that whenever my gw1000 disappears for while (technically the error is ""ERROR user.gw1000: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts"), the driver now correctly recovers. This has happened a couple of times, most recently yesterday, and my weewx instance has been up for 114 days.

So Gary, thanks!!!!

Bob 

Reply all
Reply to author
Forward
0 new messages