GW1000 driver b11 release

[gjr80]

I have released v0.1.0b11 on Github. The changes include:

- when using wee_config --reconfigure to select the GW1000 driver the user is now prompted to set loop_on_init
- reworked the wee_config --reconfigure prompts to provide existing values as defaults
- reworked the handling of non contact/loss of established contact with the GW1000:
  - users who do not use a fixed IP address for their GW1000 and experience lost contact due to a new DHCP IP address allocation should now have contact automatically re-established on the new IP address
  - when run as a driver and contact cannot be established behaviour will be as per the loop_on_init as set in weewx.conf
  - when run as a driver loss of an established contact will result in the driver being reloaded after a 60 second delay and if still no contact the behaviour will be as per loop_on_init
  - when run as a service failure to establish contact will result in WeeWX exiting
  - when run as a service loss of established contact will see WeeWX continue to operate but an attempt to re-establish contact with the GW1000 will be made every poll_interval seconds, contact results will only be logged every so often (default six hours) to limit log entries
- the 24 hour average PM2.5 fields in the default field map have been renamed from 24havpm25x to pm2_5x_24hav where x is the WH41/WH43 sensor number (1-4). This should have no affect unless the default field map was used and the database schema was changed to save the 24havpm25x fields to database. If this is the case [[field_map_extensions]] can be used to revert these fields to their previous names.

- added support for a debug_rain config option to aid in tracking down rain related issues

Reworking the handling of loss of contact was a fairly big change that affected all levels of the code. The behaviour should now be in line with the behaviour of other WeeWX drivers when contact is lost with the station with the bonus that contact with the GW1000 should be able to be re-established if the GW1000 is allocated a new IP address by DHCP (the recommended configuration remains to use a fixed IP address for the GW1000). I have spent considerable time verifying the lost contact behaviour on a network of one or two GW1000, but given the extent of the changes to the codebase it is possible a one or more corner cases may have skipped detection. Please let me know if you find any unexpected/odd behaviour.

Gary

[Graham Eddy]

did the ‘wee_extension —install’ and it is working fine

i changed all my pm..24hav fields in weewx.conf and skin.conf and templates, did the ‘ALTER TABLE archive RENAME col..’ in database, updated my extensions.py to reflect changed schema/datatypes - all looks good

i have just started tracking down an anomalous very large dayRain value that pops up in my archive records (was happening before this driver version, and yes the accumulator is set to ‘sum’) - i see a new ‘debug_rain' config option has been introduced, is there a known rain issue?

this is a seriously good driver and i very much appreciate the work going into it

[Graham Eddy]

i pulled the power plug on the gw1000 to test the new recovery/rediscover and it did not go well.

it is cycling through restart of the engine, with gw1000 service falling over soon after starting (it does find a device first).

extract from log showing a couple of those cycles with weewx.debug==2 attached

[gjr80]

On Sunday, 16 August 2020 21:46:49 UTC+10, Graham Eddy wrote:

i changed all my pm..24hav fields in weewx.conf and skin.conf and templates, did the ‘ALTER TABLE archive RENAME col..’ in database, updated my extensions.py to reflect changed schema/datatypes - all looks good

I should point out to other users that changing the schema is only required if you wish to store the 24 hour average PM2.5 readings from the GW1000 in your database, if your only requirement is to include this sort of data is reports then this can be handled by using a $span($day_delta=1).pm2_5.avg or $span($day_delta=1).pm2_5_x.avg tag. Plotting should also be possible under WeeWX 4 but would require some fairly basic coding using the new xtypes. Of course if you don't have any connected WH41/WH43 you need do nothing.

 

i have just started tracking down an anomalous very large dayRain value that pops up in my archive records (was happening before this driver version, and yes the accumulator is set to ‘sum’) - i see a new ‘debug_rain' config option has been introduced, is there a known rain issue?

I am aware of one user having small (tenths of an inch) under reporting by WeeWX of field rain over periods of up to a day when using the driver. So far it appears that field dayRain emitted by the driver is correct but the calculated rain field is somehow going awry. Still troubleshooting where/how the issue is occurring.

Gary

[gjr80]

I've spent some time trying to work out what is going on here and I am still not 100% sure. The exception that is causing the restart after the 10 second wait is being raised in StdPrint. If that is the case the behaviour you are seeing when the GW1000 is pulled is different to what I have seen. Is there anything noteworthy about your GW1000/WeeWX machine network connections? Does the log cover two disconnections of the GW1000?

Can I get you to set debug = 3 in weewx.conf and then restart WeeWX. Let WeeWX run so that at least two 'Augmented packet:' lines are displayed then unplug the GW1000 from its power supply. Assuming that causes the same OSError can you reconnect the GW1000 after at least 30 seconds. Assuming again that WeeWX reconnects to the GW1000 let it run for another two 'Augmented packets:' and then post the log from WeeWX startup. Could you also post the log as a .txt file rather than a .log, .log gives me some real headaches trying to open them on some mobile devices.

Gary

[Graham Eddy]

unable to reproduce error - driver too reliable!

sending the debug==3 logs anyway (direct to gary rather than clog up the forum) in case they prove useful later.

three logs, one with GW1000 disconnected a bit more than 30 secs, another with just a few secs disconnection and another much longer (about 15 mins) - with suffix .txt (sorry about previous .log).

at that debug level there is a lot of noise from my Alarms service…

i must have hit a corner case on my first test.

i don’t know weewx guts well enough but OSError exception (rather than IOError) coming from StdPrint sounds very strange, maybe a resource exhaustion

Q: “Is there anything noteworthy about your GW1000/WeeWX machine network connections? Does the log cover two disconnections of the GW1000?"

A: single disconnect, while moving GW1000 to its permanent position ready for cutover. no unusual config - both server (RPi 4) and GW1000 on wifi only, no service interruptions during tests, no weird interface-bending apps

cheers

--
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/4573f5aa-30b4-4fce-9a06-de9933fa208ao%40googlegroups.com.

[gjr80]

On Tuesday, 18 August 2020 13:49:39 UTC+10, Graham Eddy wrote:

unable to reproduce error - driver too reliable!

sending the debug==3 logs anyway (direct to gary rather than clog up the forum) in case they prove useful later.

three logs, one with GW1000 disconnected a bit more than 30 secs, another with just a few secs disconnection and another much longer (about 15 mins) - with suffix .txt (sorry about previous .log).

at that debug level there is a lot of noise from my Alarms service…

Thanks, replied separately re the logs.

i must have hit a corner case on my first test.

i don’t know weewx guts well enough but OSError exception (rather than IOError) coming from StdPrint sounds very strange, maybe a resource exhaustion

I still can't quite get my head around exactly what happened, in some regards it looked like the driver (run as a service in this case) was sent a command to shutdown. I have found some faulty logic in the lost contact handling in the driver that I believe could cause such a shutdown if the GW1000 was lost. I need to work through that logic again and I need to look at where the OSError was coming from. But that will have to wait a few days.

 

Q: “Is there anything noteworthy about your GW1000/WeeWX machine network connections? Does the log cover two disconnections of the GW1000?"

A: single disconnect, while moving GW1000 to its permanent position ready for cutover. no unusual config - both server (RPi 4) and GW1000 on wifi only, no service interruptions during tests, no weird interface-bending apps

Just a single disconnect, interesting that that OSError was recurring, I first thought you had two disconnections. Makes me think there was something else going on but it stills seems to have been triggered by the GW1000 disconnection.

Gary

[Bill Arthur]

I've installed it on two Pi zero W installations (with designated static IP address).
Perfect installation, no problems whatsoever.