Skip to content

Upgrade Guide

Jump to bottom
Gary edited this page Oct 22, 2021 · 28 revisions

Upgrade Guide

Introduction

This is the guide to upgrading an existing GW1000 driver extension installation. It should be used when upgrading an existing GW1000 driver irrespective of whether the GW1000 driver was installed manually or by using the WeeWX utility wee_extension. This guide also applies irrespective of whether the GW1000 driver is used as a WeeWX driver or service.

The section Instructions for specific versions describes changes required from one version to the next along with specific actions that may need to be taken to upgrade to the version concerned. As a minimum you should refer to the relevant section before undertaking the upgrade.

Upgrading using wee_extension

wee_extension may be used to upgrade an existing GW1000 driver extension installation irrespective of whether the GW1000 driver extension was installed manually or using wee_extension. To use wee_extension to upgrade an existing GW1000 driver extension installation:

  1. Download the latest GW1000 driver extension package:

    $ wget -P /var/tmp https://github.com/gjr80/weewx-gw1000/releases/download/v0.4.0/gw1000-0.4.0.tar.gz

  2. Install the downloaded GW1000 driver extension:

    $ wee_extension --install=/var/tmp/gw1000-0.4.0.tar.gz

    Note: Depending on your system/installation the above command may need to be prefixed with sudo.

    Note: Depending on your WeeWX installation wee_extension may need to be prefixed with the path to wee_extension.

  3. You may test the upgraded GW1000 driver by running the driver file directly using the --test-driver command line option:

    $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --test-driver

    for setup.py installs or for package installs use:

    $ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --test-driver

    Note: Whilst the driver may be run independently of WeeWX, the driver still requires access to WeeWX and it's dependencies. Consequently, if WeeWX 4.0.0 or later is installed the driver must be run under the same Python version as WeeWX uses. This may be different to the Python version invoked by the command 'python'. This means that on some systems 'python' in the above commands may need to be changed to 'python2' or 'python3'.

    You should observe loop packets being emitted on a regular basis. Once finished press ctrl-c to exit.

    Note: You will only see loop packets and not archive records when running the driver directly. This is because you are seeing output directly from the driver and not WeeWX.

  4. Restart the WeeWX daemon:

    $ sudo /etc/init.d/weewx restart

    or

    $ sudo service weewx restart

    or

    $ sudo systemctl start reweewx

Upgrading manually

An existing GW1000 driver extension installation may be upgraded manually irrespective of whether the GW1000 driver extension was previously installed/upgraded manually or using wee_extension. However, to maintain the integrity of the installed extension data maintained by wee_extension, it is recommended that extensions previously installed/upgraded by wee_extension continue to be upgraded using wee_extension. You can check if the GW1000 driver was previously installed/upgraded using the wee_extension utility by using the following command:

$ wee_extension --list

If the GW1000 driver was installed using the wee_extension utility 'GW1000' will be listed as an installed extension.

To manually upgrade and existing GW1000 driver extension installation:

  1. Download the latest GW1000 driver extension package:

     $ wget -P /var/tmp https://github.com/gjr80/weewx-gw1000/releases/download/v0.4.0/gw1000-0.4.0.tar.gz

  2. Extract the contents of the GW1000 driver extension package:

    $ tar -xzf /var/tmp/gw1000-0.4.0.tar.gz -C /var/tmp

  3. Copy the file gw1000.py to the BIN_ROOT/user directory:

    $ cp /var/tmp/gw1000/bin/user/gw1000.py BIN_ROOT/user

    Note: Depending on your system/installation the above command may need to be prefixed with sudo.

  4. You may test the upgraded GW1000 driver by running the driver file directly using the --test-driver command line option:

     $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --test-driver

    for setup.py installs or for package installs use:

     $ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --test-driver

    Note: Whilst the driver may be run independently of WeeWX, the driver still requires access to WeeWX and it's dependencies. Consequently, if WeeWX 4.0.0 or later is installed the driver must be run under the same Python version as WeeWX uses. This may be different to the Python version invoked by the command 'python'. This means that on some systems 'python' in the above commands may need to be changed to 'python2' or 'python3'.

    You should observe loop packets being emitted on a regular basis. Once finished press ctrl-c to exit.

    Note: You will only see loop packets and not archive records when running the driver directly. This is because you are seeing output directly from the driver and not WeeWX.

  5. Restart the WeeWX daemon:

     $ sudo /etc/init.d/weewx restart

    or

     $ sudo service weewx restart

    or

     $ sudo systemctl start reweewx

Instructions for specific versions

Upgrading to v0.4.1

V0.4.1 changes have no impact on users.

Upgrading to v0.4.0

V0.4.0 changes are minor and should have minimal impact on users. Keys changes are summarised below.

GW1000/GW1100 support

The GW1000 driver can now distinguish between GW1000 and GW1100 devices. Whilst both devices utilise the same API, some driver output will now display GW1000 or GW1100 rather than only GW1000. This relates mainly to log output and when running the driver directly, so most users should not have an issue. When run as a driver the tag $station.hardware can be used in Cheetah report templates to display the correct device model.

Battery state data for sensors with no signal

Battery state data is now set to None for sensors with a signal level of 0 (the previous behaviour was to decode and display whatever the GW1000 returned irrespective of signal state). This behaviour can be disabled by setting option show_all_batt = True under [GW1000] in weewx.conf or by use of the --show-all-batt command line option if running directly. Those users that display or otherwise use battery state level data in Cheetah templates or other services etc may be affected by this change.

Upgrading to v0.3.1

V0.3.1 changes were bug fixes only and v0.3.1 fully backwards compatible. There should be no affect on users

Upgrading to v0.3.0

The main changes in v0.3.0 was introduction of support for the WH35 (as per API documentation)/WN35 (hardware model as released) leaf wetness sensor and the inclusion of the GW1000 lightningcount in emitted loop packets. This release also included a number of bug fixes and improvements that are backwards compatible and should have no impact on users.

WH35/WN35 support

API documentation release v1.6.0 included support for up to eight WH35 leaf wetness sensors. Support for the WH35 leaf wetness sensor is believed to have been introduced in GW1000 firmware release v1.5.6. Support for up to eight leaf wetness sensors has been included in the GW1000 driver v0.3.0 with the default field map changed to map the output of the eight leaf wetness sensors to WeeWX fields leafWet1 to leafWet8 inclusive.

Historical Note: Before public release of the leaf wetness sensor the GW1000 API documentation referred to the leaf wetness sensor as WH35. Consequently, the GW1000 driver v0.3.0 refers to the leaf wetness sensor as WH35 and relevant sensor battery and signal state fields appear as wh35_chx_batt and wh35_chx_sig respectively (the leaf wetness sensor output is mapped to WeeWX fields leafWetx so users who have one or more leaf wetness sensors will see no mention of WH35 in the leaf wetness data appearing in loop packets). Later, when the leaf wetness sensor was publicly released it was designated WN35 not WH35. This anomaly has been corrected in the GW1000 driver v0.4.2.

Revised sensor ID, battery state and signal state information

The decoding of sensor ID, battery state and signal level data was revised as per changes introduced in API documentation v1.6.0 and GW1000 firmware v1.6.5. This should be an internal GW1000 change only that does not affect users; however, any users noticing any battery state or signal level data discrepancies are asked to highlight these by raising an issue in the GW1000 driver GitHub repo or by posting to weewx-user.

Inclusion of lightningcount in emitted loop packets

Previously the daily cumulative lightning count field from the GW1000, lightningcount, was used to derive the lightning_strike_count field and the lightningcount field was then discarded and not included in the emited loop packet. The lightningcount field is still used to derive the lightning_strike_count field but lightningcount is now retained and included in the emitted loop packet.

Upgrading to v0.2.0

Various new features were introduced and changes made in the GW1000 driver v0.2.0 release that may affect users. These changes and their impact on users are detailed below.

Added support for WH45 Air Quality Sensor

Support was added for the WH45 Air Quality Sensor with PM10, CO2 and additional PM2.5, temperature and humidity fields included in the GW1000 driver output. Also included are corresponding battery and sensor state fields.

Sensor signal level data included in loop packets

Sensor signal level data for registered sensors is now included in loop packets. Loop packet field names generally use the following format:

sensor designator code_channel number_sig

for example:

wh31_ch1_sig
wh57_sig

Refer to the Field map wiki entry for a complete list of available sensor signal level field names.

Changes to 24 hour average particulate concentration fields

To align with the field name formats already in use within WeeWX it was necessary to alter the WeeWX field names used in the default mapping of PM2.5 24 hour average particulate concentration data. To keep a similar naming convention within the GW1000 driver the corresponding GW1000 internal PM2.5 24 hour average particulate concentration field names were also altered. These changes may impact users who have WH41, WH43 or WH45 sensors and (1) save or display PM2.5 24 hour average data obtained from the GW1000 driver or (2) have altered the field map to map PM2.5 24 hour average particulate concentration data to another field or (3) modified their WeeWX database schema to store 24 hour average particulate concentration data. Affected users will need to make one or more changes to continue operating as before. Details of the changes required are provided in the Changes to 24 hour average particulate concentration field names wiki entry.

    -   added --get-services command line option to display GW1000 supported weather services settings
    -   added --get-pm25-offset command line option to display GW1000 PM2.5 sensor offset settings
    -   added --get-mulch-offset command line option to display GW1000 multi-channel TH sensor calibration settings
    -   added --get-soil-calibration command line option to display GW1000 soil moisture sensor calibration settings
    -   added --get-calibration command line option to display GW1000 sensor calibration settings
    -   renamed --rain-data command line option to --get-rain-data
Clone this wiki locally