yet another question to GW1000 api driver mapping

[Vetti52]

Well, I started this conversation already at another thread (https://groups.google.com/g/weewx-user/c/ua0JjTp1DW8/m/AFGZf7AyAgAJ), concerning wind.gust.dir in version 4.2.0. As TK managed to solve the main problem, there is still the other part unsolved. So, I want to move this topic into a new thread, knowing, that there were similar questions during the last months, whicht could help only partially.

I am not able to change from interceptor's ecowitt-client to GW1000 without loss of some data. Gary provided the crucial hints in the thread mentioned above, which brought me almost to the successful end of this story. But still one thing remains to be much too complicated for me:

According to Gary's explanations, I introduced an extra stanza in weewx.conf:

# Options for extension 'GW1000'
[GW1000]
    driver = user.gw1000
    [[field_map_extensions]]
        # WeeWX field name = GW1000 field name
        rainEvent = rainevent
        wh65_battery = wh65_batt

I took these two values from the original ecowitt-client mappings in interceptor.py:

DEFAULT_SENSOR_MAP = {
...

       'rainEvent': 'rain_event',
        'UV': 'uv',

where the Weewx field is on the left and the Ecowitt-client field to the right side.

And here is the other map in weewx.conf:

[Interceptor]

    driver = user.interceptor
    device_type = ecowitt-client
    mode = listen
    port = 9000
    [[sensor_map_extensions]]
        txBatteryStatus = wh65_battery

Here, the Ecowitt client field is at the left and thus the Weewx field should be to the right.

The GW1000 field map extension works! But this is true only for rainEvent, no for the battery status. I had a look into sensors.inc in the seasons skin:

#def get_battery_status($x)
#if $x == 0
<span class="status_ok">$x: GOOD</span>
#else
<span class="status_low">$x: LOW</span>
#end if
#end def

and found out, that, using the ecowitt-client, $wx == 0.0, but with GW1000 it does not even exist, no value at all. Although I trend to assume, that I understand now, how the mappings work (thanks to Gary), I am still helpless to map the battery sensor properly.

Hopefully someone can bring me on the right track.

--ph

[gjr80]

Some comments below. Hopefully it gives you a process to work through to identify your problem.

Gary

Not quite, the sensor map extensions in weewx.conf for the interceptor driver are in the format:

    WeeWX field name = interceptor field name

This convention has been used by the WeeWX development team now for some time in all contemporary drivers with some form of sensor/field mapping. Note, drivers developed by others may or may not use the same convention.

 

The GW1000 field map extension works! But this is true only for rainEvent, no for the battery status. I had a look into sensors.inc in the seasons skin:

#def get_battery_status($x)
#if $x == 0
<span class="status_ok">$x: GOOD</span>
#else
<span class="status_low">$x: LOW</span>
#end if
#end def

and found out, that, using the ecowitt-client, $wx == 0.0, but with GW1000 it does not even exist, no value at all. Although I trend to assume, that I understand now, how the mappings work (thanks to Gary), I am still helpless to map the battery sensor properly.

Hopefully someone can bring me on the right track.

I think you need to be taking a step back working through this in a methodical manner. Data that goes from sensor to web page is processed by many different parts of WeeWX each of which could be the cause of your problem. The driver reads sensor data and emits data in loop packets, the StdArchive service accumulates these loop packets and emits archive records, the StdReport service then uses Cheetah and a system of tags to present this data in a report. At the moment you are looking at the very last step in the process and the result is not what you expect. To troubleshoot you need to work through the process from driver onwards.

First up, is the GW1000 driver actually emitting reinvent and wh65_batt fields. This can be checked by running the GW1000 driver directly with the --live-data command line option, something like:

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data

Note you may need to use PYTHONPATH=/usr/share/weewx if WeeWX was installed as a package and you may need to explicitly specify the python version to run by replacing python with python2 or python3.

The command should result all sensor data available to the GW1000 being displayed on the console. The data is raw data from the console before any mapping, so you should be looking for rainevent and wh65_batt fields. Do they exist, if so good, if not then the GW1000 driver is not obtaining data from the relevant sensor.

If you have rainevent and wh65_batt fields the next thing to check is the operation of the field mapping. The field mapping occurs in the GW1000 driver so you need to look at the loop packets emitted by the GW1000 driver to see what they contain. If you have the following in [[field_map-extensions]]:

    [[field_map_extensions]]

        rainEvent = rainevent
        wh65_battery = wh65_batt

 

Then you should see fields rainEvent and wh65_battery in the loop packets emitted by the GW1000 driver. The easiest way to do this is to run WeeWX directly and observe the loop packet output (lines beginning with LOOP:) on the console. Do the loop packets include field rainEvent and wh65_battery? If so the field mapping extensions are working as they should and the issue lay further up the chain. If the fields to no exist the issue is within he driver and/or the field map extensions.

If the rainEvent and wh65_battery fields exist in the loop packets then you need to check to ensure they are appearing in the WeeWX generated archive records; let WeeWX continue to run directly and wait for an archive record to be emitted (line beginning with REC:). Do rainEvent and wh65_battery fields appear in the archive record? If yes then the issue is likely in the report generation, if no then we have a serious problem with  the StdArchive service.

When looking at the StdReport service the first thing to check is your template. Start simple and work up to the complex. Can you display the fields you are interested in with $current tags, eg $current.rainEvent and $current.wh65_batt. If you are intending to use these fields in a comparison or expression are you using them with the .raw formatting (eg $current.rainEvent.raw which gives a number) or some other formatting which gives a string (eg $current.wh65_batt gives a string)?

--ph

[Vetti52]

Thanks, Gary, for your polite explanations.

Since I have read some of your comments with equal advices in other threads, I proceeded already to sucessfully map the fields. Otherwise I did not even had an idea about field_map in GW1000. Sorry, that you need to explain again and again the comparison of --live-data and mapped loop data. But at that point, I feel better, not to miss any point. Thanks for your patience.

Well, data are mapped, weewx running directly gives this output:

$ sudo weewxd /etc/weewx/weewx.conf
LOOP:   2020-12-16 13:29:56 CET (1608121796) altimeter: 30.09246486970751, appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121796, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp: 65.12, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure: 29.97589031125, radiation: 64.59352801894238, rain: None, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0, windchill: 48.74, windDir: 187, windGust: 3.3554127779089566, windGustDir: None, windSpeed: 2.6843302223271652, yearRain: 29.17716535433071
LOOP:   2020-12-16 13:30:56 CET (1608121856) altimeter: 30.09542729292998, appTemp: 45.69491271146897, barometer: 30.095134121428384, cloudbase: 944.6426189788297, dateTime: 1608121856, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp: 65.12, luminosity: 8075.0, maxSolarRad: 85.3176898825967, monthRain: 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure: 29.978843310000002, radiation: 63.73322809786898, rain: 0.0, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.3, usUnits: 1, UV: 0, uvradiation: 6.4, weekRain: 10.9, wh65_battery: 0, windchill: 47.93087953525257, windDir: 162, windGust: 5.816048815042191, windGustDir: None, windSpeed: 3.3554127779089566, yearRain: 29.17716535433071
REC:    2020-12-16 13:30:00 CET (1608121800) altimeter: 30.09246486970751, appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 0.00012174671890853505, extraTemp1: 124.89439999999999, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill: 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187, windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain: 29.17716535433071

So I am glad to see, that the StdArchive service is ok. Right?

Your last question needs some explanation and preparation: I am no longer bothering with rainEvent, as this works now as expected. Thus, my approach focussing wh65_battery data, was, that I looked at the output the value of $x in sensors.inc. So, when interpreting your question, I should not print $x, but $current.rainEvent.raw instead at the same place? Sorry for the dumb question, but I do not clearly understand the difference between $current and $current.raw. To me the format of the recorded battery value is a decimal number. When using interceptor's Ecowitt-client, $x returns this value as a decimal number 0.0 as well. So, do you expect, that in case of GW1000 the recorded number is converted into a string and thus not evaluated in #if $x == 0 ? Said that, should I simply compare the output of $current.wh65_batt and $current.wh65_batt.raw instead of $x at the same place I depicted above?

Peter

[Vetti52]

As I could not wait for an answer, I tried to replace $x in the example mentioned above (marked in yellow) by any of the supposed expressions. But in any case I get this type of error:

 ERROR weewx.cheetahgenerator: Generate failed with exception '<class 'TypeError'>'
 ERROR weewx.cheetahgenerator: **** Ignoring template /etc/weewx/skins/alltimeSeasons/index.html.tmpl
 ERROR weewx.cheetahgenerator: **** Reason: 'UnknownType' object is not subscriptable

neither $get_battery_status($current.wh65_batt.raw) nor $current.wh65_batt or $current.wh65_battery or any other combination works. I must admit, that I do not understand, what I am doing. This python coils.

[gjr80]

Peter,

Comments below.

Gary

On Wednesday, 16 December 2020 at 23:18:26 UTC+10 Vetti52 wrote:

Thanks, Gary, for your polite explanations.

Since I have read some of your comments with equal advices in other threads, I proceeded already to sucessfully map the fields. Otherwise I did not even had an idea about field_map in GW1000. Sorry, that you need to explain again and again the comparison of --live-data and mapped loop data. But at that point, I feel better, not to miss any point. Thanks for your patience.

I noted you had worked through the mappings, I wanted to outline the entire process, mainly for the next person that comes along.

 

Well, data are mapped, weewx running directly gives this output:

$ sudo weewxd /etc/weewx/weewx.conf
LOOP:   2020-12-16 13:29:56 CET (1608121796) altimeter: 30.09246486970751, appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121796, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp: 65.12, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure: 29.97589031125, radiation: 64.59352801894238, rain: None, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0, windchill: 48.74, windDir: 187, windGust: 3.3554127779089566, windGustDir: None, windSpeed: 2.6843302223271652, yearRain: 29.17716535433071
LOOP:   2020-12-16 13:30:56 CET (1608121856) altimeter: 30.09542729292998, appTemp: 45.69491271146897, barometer: 30.095134121428384, cloudbase: 944.6426189788297, dateTime: 1608121856, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp: 65.12, luminosity: 8075.0, maxSolarRad: 85.3176898825967, monthRain: 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure: 29.978843310000002, radiation: 63.73322809786898, rain: 0.0, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.3, usUnits: 1, UV: 0, uvradiation: 6.4, weekRain: 10.9, wh65_battery: 0, windchill: 47.93087953525257, windDir: 162, windGust: 5.816048815042191, windGustDir: None, windSpeed: 3.3554127779089566, yearRain: 29.17716535433071
REC:    2020-12-16 13:30:00 CET (1608121800) altimeter: 30.09246486970751, appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 0.00012174671890853505, extraTemp1: 124.89439999999999, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill: 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187, windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain: 29.17716535433071

So I am glad to see, that the StdArchive service is ok. Right?

 

Yes. One small thing though that I did not highlight is the accumulator extractor functions. By default when WeeWX synthesises an archive record from the accumulated loop data WeeWX takes the average of the accumulated values for each field. In essence you get the average value of the filed in the archive period. For something like temperature this is appropriate, but for something like WeeWX field rain (the amount of rainfall seen in the archive period) we want the sum not the average. For something like rainEvent which is a cumulative value we likely want the last value seen rather than the average (and certainly not the sum). Similarly for wh65_battery, if we had two loop packets arrive in the archive period and the first one had wh65_battery = 0 and the last had had wh65_battery = 1 do we want the resulting archive record to have wh65_battery = 0.5? No, we ant it to have the last value seen ie 1.

The way we tell WeeWX how to extract a given archive record field from the accumulated loop data is by specifying the extractor function to use in weewx.conf. In your case you will need to add something like the following to weewx.conf:

[Accumulator]

    [[rainEvent]]

        extractor = last

    [[wh65_battery]]

        extractor = last

If you have a look in weewx.conf you will likely find an [Accumulator] stanza towards the bottom of weewx.conf already. You will likely find it already has a [[wh65_batt]] entry and not [[rainEvent]] entry. You will need to add the [[wh65_battery]] and [[rainEvent]] entries above anywhere under [Accumulator].

Your last question needs some explanation and preparation: I am no longer bothering with rainEvent, as this works now as expected. Thus, my approach focussing wh65_battery data, was, that I looked at the output the value of $x in sensors.inc. So, when interpreting your question, I should not print $x, but $current.rainEvent.raw instead at the same place? Sorry for the dumb question, but I do not clearly understand the difference between $current and $current.raw. To me the format of the recorded battery value is a decimal number. When using interceptor's Ecowitt-client, $x returns this value as a decimal number 0.0 as well. So, do you expect, that in case of GW1000 the recorded number is converted into a string and thus not evaluated in #if $x == 0 ? Said that, should I simply compare the output of $current.wh65_batt and $current.wh65_batt.raw instead of $x at the same place I depicted above?

I have not had much experience with declaring and using in-template functions in Cheetah, but given your get_battery_status() declaration you will need to call it using $get_battery_status($current.wh65_battery.raw). You indicated you were using $current.wh65_batt.raw but that will not work as changing the mapping of wh65_batt to now map it to wh65_battery means that wh65_batt no longer appears in your loop packets/archive records, instead you now have wh65_battery (refer to the above LOOP: and REC: output).

[Vetti52]

Ok, I added the entries into accumulator. So, this part is completed now. But still the battery value is missing.

The construct in sensors.inc

#def get_battery_status($x)
#if $x == 0

<span class="status_ok">$get_battery_status($current.wh65_battery.raw : GOOD</span>
#else
<span class="status_low">$get_battery_status($current.wh65_battery.raw : LOW</span>
#end if
#end def

does not work either. The error is somewhat different:

ERROR weewx.cheetahgenerator: Generate failed with exception '<class 'RecursionError'>'

ERROR weewx.cheetahgenerator: **** Ignoring template /etc/weewx/skins/alltimeSeasons/index.html.tmpl

ERROR weewx.cheetahgenerator: **** Reason: maximum recursion depth exceeded

I think, that there is an extra turn, I do not understand at all. I can see, that this expression seems to evoke a recursion. So, where comes the $x from? Why does it only work starting with #def, but not with $? This is to much inside knowledge for me. And I am not sure, that an explanation of this part would help. Anyway, it seems, that there is a black hole between StdArchive and Record, concerning the battery thing.

[Vetti52]

Typo: $get_battery_status($current.wh65_battery.raw), of course with closed brakets

[gjr80]

No, I did not say to change the get_battery_status() definition, what I sad was that elsewhere in your template, where you call get_battery_status(), you need to call it using $get_battery_status($current.wh65_battery.raw). You should put the get_battery_status() definition back how it was. sensors.inc should look something like:

## sensors module for weewx skins
## Copyright Tom Keffer, Matthew Wall
## See LICENSE.txt for your rights
#errorCatcher Echo
#encoding UTF-8

## this is a conditional display of sensor data, including connectivity,
## battery status, and various voltages.  if there are no data available,
## then this degenerates to nothing displayed.

#def get_battery_status($x)
#if $x == 0

<span class="status_ok">OK</span>
#else
<span class="status_low">LOW</span>
#end if
#end def

...

#if $day.wh65_battery.has_data
    <tr>
      <td class="label">$obs.label.wh65_battery</td>
      <td class="data">$get_battery_status($current.wh65_battery.raw)</td>
    </tr>
#end if

...

Note that in the example I gave above you would need to define a label for wh65_battery under [Labels] [[Generic]] in skin.conf, eg

[Labels]

    # Override some labels. No need to identify these as a "Battery"
    # or "Voltage", because that is included in the template.
    [[Generic]]
        wh65_battery = WH65
       ...

Gary

[Vetti52]

Aaah, now I start to understand! The first part is just a definition. Got it! Thanks!!!!

In skin.conf stanza [Labels] [Generic] I found

        txBatteryStatus      = Transmitter

I replaced the left side with wh65_batteryStatus

In Seasons.inc I found:

#set $have_battery_status = 0
#for $x in [$day.txBatteryStatus, $day.windBatteryStatus, $day.rainBatteryStatus, $day.outTempBatteryStatus, $day.inTempBatteryStatus]
  #if $x.has_data
    #set $have_battery_status = 1
  #end if
#end for

and later on:

#if $have_battery_status
    <tr><th>Batterie Status</th><th></th></tr>
#if $day.txBatteryStatus.has_data
    <tr>
      <td class="label">$obs.label.txBatteryStatus</td>
      <td class="data">$get_battery_status($current.txBatteryStatus.raw)</td>
    </tr>
#end if

I replaced all txBatteryStatus entries by wh65_battery  except $obs.label.wh65_batteryStatus according to the label in skin.conf.

First, all this looks simply logic. However, now the sensors data were no longer displayed at all. Checked for typos. Nope. So, my logic failed again.

I then tried to replace all entries step by step. So, at first, it was evident, that the expression #for $x in [$day.txBatteryStatus, ...  still results in status = 1, but not, when replaced with $day.wh_65battery,.

Ok, next step. Then I have to keep the original condition also here:

#if $have_battery_status
    <tr><th>Batterie Status</th><th></th></tr>
#if $day.txBatteryStatus.has_data
    <tr>

but still use the new values in the next two lines here:

      <td class="label">$obs.label.wh65_batteryStatus</td>

      <td class="data">$get_battery_status($current.wh65_battery.raw)</td>
    </tr>
#end if

So, finally everything looks fine, same like the results from interceptor.py. But why do I still need txBatteryStatus? Where does this value come from? Obviously $current.wh65_battery returns a valid result, thus providing data. But it is not suitable for evaluating $x. This is still not logical to me...

Actually to me it looks like txBatteryStatus is not the Ecowitt-client field name, as mentioned in my first post here, but is an internal field name in Weewx (or why is it regularily used in seasons.inc?). So, it could have been much less complicated to map wh65_batt to txBatteryStatus. But I am afraid, that there still was something wrong with it.

Peter

[gjr80]

Peter,

Your understanding is correct. The logic in the code now appears correct but I think you are using the incorrect field name. Earlier you posted an archive record:

REC:    2020-12-16 13:30:00 CET (1608121800) altimeter: 30.09246486970751, appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 0.00012174671890853505, extraTemp1: 124.89439999999999, heatindex: 47.403000000000006, humidex: 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill: 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187, windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain: 29.17716535433071

The field name is wh65_battery not wh_65battery. Anywhere you use $day or $current to access the WH65 battery state you need to be using $day.wh65_battery or $current.wh65_battery.

Gary

[Vetti52]

Thanks, Gary. The typo was here, not in seasons.inc. But I had another assumption: When displaying the values $current.txBatteryStatus.raw and $current.wh65_battery.raw , I could see, that the first one was empty, and only the second value was existent. My assumption was, that  $day.txBatteryStatus had data from time of this day before switching from interceptor to gw1000 driver, but $day.wh65_battery did not (yet).

So I tried this modification:

#set $have_battery_status = 0
#for $x in [$day.txBatteryStatus, $day.wh65_battery, $day.windBatteryStatus, $day.rainBatteryStatus, $day.outTempBatteryStatus, $day.inTempBatteryStatus]

  #if $x.has_data
    #set $have_battery_status = 1
  #end if
#end for

If this was true, I expected, that the sensor section would be present today, because

#if $have_battery_status
    <tr><th>Batterie Status</th><th></th></tr>
#if $day.txBatteryStatus.has_data
    <tr>

      <td class="label">$obs.label.wh65_batteryStatus</td>
      <td class="data">$get_battery_status($current.wh65_battery.raw)</td>
    </tr>

#end if

should result in the header line but no "Transmitter" data, because $have_battery_status being true, but no content, because $day.txBatteryStatus.has_data was supposed to be wrong since today. However, unfortunately, the complete section disappeared. So, my assumption is true only partially: Today there is no more $day.txBatteryStatus, but, surprise,  there isn't  $day.wh65_battery either.

What is wrong with it?

[gjr80]

The penny drops. Have you added wh65_battery to your database schema? $current.wh65_battery will work without wh65_battery being in your schema but $day.wh65_battery requires wh65_battery be in your schema.

Refer to Adding a new type to the database in the Customization Guide.

Gary

[Vetti52]

Ok, this is the missing point. Actually, I hesitate because of this highlight in the Customization Guide:

----------------------------------------------------------------------------------------------------

Warning!
Make a backup of the data before doing any of the next steps!

----------------------------------------------------------------------------------------------------

As I am actually not physically close to the Raspi running with Weewx (the actual connection is with ssh from outside), so I prefer the lazy way:

I replaced wh65_battery with

[[field_map_extension]]

       txBatteryStatus = wh65_batt

and the entry in the stanza [Accumulator] accordingly, wrote back an untouched copy of seasons.inc, uncommented the original label in skins.conf, and voila, after weewx restart, everything looks ok. Although, I would have preferred wh65_battery decribing the field name more precisely, when thinking about adding further sensors in the future.  But, at least, I can now understand a little part of the whole thing more than before.

Thanks!

Peter

[vince]

[[field_map_extension]]

       txBatteryStatus = wh65_batt

and the entry in the stanza [Accumulator] accordingly, wrote back an untouched copy of seasons.inc, uncommented the original label in skins.conf, and voila, after weewx restart, everything looks ok. Although, I would have preferred wh65_battery decribing the field name more precisely, when thinking about adding further sensors in the future.  But, at least, I can now understand a little part of the whole thing more than before.

That's actually a very typical way to use the many available elements creatively and not need to extend or customize the schema.  I used to do the same thing notionally when I had three battery-powered WeatherFlow sensors at the same time.   Just comment your weewx.conf appropriately so you remember which element is used for which sensor.  Works great !

[vince]

Gary - this thread got me thinking of adding battery status to my minimal EcoWitt skin (GitHub link)

I have a GW1000 and a WH32 outdoor sensor and run weewx 4.2.0 dpkg raspi using 0.1.0b12 of your driver.

   pi@pi3jr:~ $ PYTHONPATH=/usr/share/weewx python3 -m user.gw1000 --live-data

   Using configuration file /etc/weewx/weewx.conf

   Interrogating GW1000 at 192.168.2.20:45000

   GW1000 live sensor data: absbarometer: 1002.8, datetime: 1608426650, inhumid: 43, intemp: 21.8, outhumid: 97, outtemp: 7.7, relbarometer: 1014.3, wh26_batt: 0

What's interesting is that you report this as a wh26 when the EcoWitt app (and my Amazon receipt) show it as a WH32.

A little research says that the WH32 seems to be a later model of the WH26 so I'm guessing/hoping it doesn't matter much, but I thought I'd mention it to you.  You do have a comment in decode_batt() with a question mark about it, so I guess the answer there is 'yes it seems to be the same'.

Thanks again for a great driver.  Looking forward to buying more sensors.

FWIW, I also added a screenshot and the cheetah-fu and description of how I added battery status to the skin is here

[gjr80]

Yes I'm aware of the WH26/WH32 issue, I have a WH32 myself. Interestingly the GW1000 API does not mention the term 'WH32' anywhere.In fact, to date I have not seen 'WH32' mentioned anywhere on the Ecowitt.net display/dashboard nor anywhere in the WS View app. The closet I have seen WH32 being 'mentioned' is the device icons that appear when you go to 'Sensors ID' in the WS View app - the icon appears to be a WH32 (but then I have never unknowingly seen a WH26 either). Bottom line is the GW1000 API lists the bit concerned in the battery state API response as WH26 battery state so that is what the driver passes it through as. If I could find something somewhere that discriminates between the two I would use that to change the field name accordingly (there actually is a bit in one of the API responses that discriminates between a connected WH24 or WH65, but there nothing along those lines for WH26/WH32). I have toyed with adding a config option in the driver stanza that would solely be used to set the name of that battery state field, just haven't gotten around to it yet plus WeeWX gives the user the ability to map wh26_batt to a field name of the users choice anyway.

Gary

[vince]

Yes - works great as-is.    Running the --live-data check makes it very easy to figure out what to map to what. 

FWIW, my EcoWitt app shows it as a "T&H ID: 32" in their very difficult to figure out mobile app under Menu => DeviceList, then clicking on my gateway id there, then hitting More => Sensors.    Geez what user interface rocket scientist at Ecowitt cooked up that mess.  Super frustrating to navigate.

[gjr80]

You are indeed lucky (fortunate?) that your TH32 sensor ID is ‘32’, mine is ‘e4’.

Gary

[vince]

On Sunday, December 20, 2020 at 12:03:05 PM UTC-8 gjr80 wrote:

You are indeed lucky (fortunate?) that your TH32 sensor ID is ‘32’, mine is ‘e4’.

I'm on the correct side of the equator, use a non-metric unit system, and the one true RF band (915MHz) :-)

Dunno if that matters any re: the hardware and what id it shows.   Everything I've seen so far seems to indicate Ecowitt might be a bit of a moving target as their new sensors start being released.  But for under $50 US it's a nice low cost of entry for minimal in/out temp+hum that can play with weewx, plus the low prices on additional sensors.