The failed attempts highlighted below are exactly that; a failed attempt to communicate with the GW1000 (and in each case attempt 2 was successful). When sending a command to the GW1000 the driver will attempt to send the command (and obtain a response) a set number of times (three is the default) before giving up. This is fairly standard behaviour in most WeeWX drivers. It is only once all attempts fail that the driver considers contact with the GW1000 has been lost and the 'lost contact' procedure implemented.
As for the frequency of failed attempts, I have noticed the odd failure during testing/development which I have put down to the vagaries of communicating with a device over a network/wifi or the device being busy while doing something else (posting to WU/Ecowitt, talking to sensors etc). Can't say I have seen any 104 errors, only timeouts. Such problems will not be IP address issues as the second or third attempt works and a changed IP address would result in all attempts failing (the driver will only work through lost contact if all three attempts fail). I don't run my on-line GW1000 instance with debug=1 so I would not see any single or double attempt failures there and I am yet to have an all attempts failure. I might try running with debug=1 to see if there are any single or double failures. Can't say I have seen any pm2.5 anomalies such as you describe either. Gary On Monday, 7 September 2020 at 13:30:15 UTC+10 [email protected] wrote: > interesting. i have been running gw1000.py b12 since its release, and > stopped watching closely as it was all working fine (no weewx losses - > apart from pm2.5 sensors, which is different story). now that i go back to > logs (debug==1), i see gw1000 > service reported about 24 errors over last 36 hours at apparently random > intervals (5 mins to 5 hours). service recovers cleanly, so i hadn’t > noticed. > but it shows how critical the recovery function is to the gw1000 service - > who know what evil lurks under the “WS View” phone app provided... > > mostly gw1000 service reports a single timeout. > > Sep 7 11:34:19 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > Sep 7 11:34:41 dizzy weewx[7853] DEBUG user.*gw1000*: Failed to obtain > response to attempt 1 to send command 'CMD_GW1000_LIVEDATA': timed out > Sep 7 11:34:52 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > > > occasionally it is a "connection reset" - presumably just happens to catch > the GW1000 controller while it is failing. > > Sep 7 02:27:41 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > Sep 7 02:28:02 dizzy weewx[7853] DEBUG user.*gw1000*: Failed attempt 1 > to send command 'CMD_READ_SENSOR_ID': [Errno 104] Connection reset by peer > Sep 7 02:28:13 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > Sep 7 02:28:21 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > Sep 7 02:28:21 dizzy weewx[7853] INFO user.*gw1000*: Lightning counter > wraparound detected: new=0 last=1 > Sep 7 02:28:41 dizzy weewx[7853] DEBUG user.*gw1000*: Next update in 20 > seconds > > > in my case, it is not a DHCP issue as the ipaddr doesn’t change, the > period between failures is far too short for lease expiries, and it is > assigned ipaddr by mac address anyway. prime facie the GW1000 controller > (or at least its wifi interface) is resetting itself at random intervals. > has this behaviour been seen elsewhere? > > now i bring in my pm2.5 sensors reporting to the GW1000 controller. i have > two. they both reset sporadically (losing state, so it is not just > interface reset), and often at the same time. this interval appears to be > several days, not 1½ hours like above. i wonder if it is related to the > apparent GW1000 controller resets > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/bd063697-8be8-45e9-b8f7-8a92a8c8ff54n%40googlegroups.com.
