I have released v0.1.0b11 on Github 
<https://github.com/gjr80/weewx-gw1000/releases>. The changes include:

- when using wee_config --reconfigure to select the GW1000 driver the user 
is now prompted to set loop_on_init 
<http://weewx.com/docs/usersguide.htm#General>
- 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

-- 
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/183d31fd-63a7-443d-bd1a-d47decf9b5edo%40googlegroups.com.

Reply via email to