gw1000/gw2000 Battery Status

178 views
Skip to first unread message

Daidl Himself

unread,
Aug 14, 2023, 6:14:46 AM8/14/23
to weewx-user
Hi,

I have the GW2000 with lots of sensors sattached,  and grab the data with the gw1000 driver. The Season skin is used to display the data.
adapting the database and  the extension.py was successfull to write the data in the database with a logical group assigned.

What I struggle with, is the logic for the Battery status for some sensors. As mentioned in the wiki, the sensors give different values for the status and might need to be individual configurated.

I have a wh45, that gives me values 0-5 for Battery use and a 6 for external power. Where can I find the code to validate the staus as "OK", "BAD"or "USB" and change it accordingly?

Rainer Lang

unread,
Aug 14, 2023, 9:04:39 AM8/14/23
to weewx...@googlegroups.com

the driver only collects the data provided by the gateway API - and if you have created corresponding fields and assignments, weewx stores this data in the data base. That's it.
There is no further code as far as I am aware of.

Can you tell what exactly you want to do ?
Display the codes as human readable text e.g. in the current value table (left side table) of the Seasons skin ?

If so, you could implement the logic (code) in e.g. current.inc which is included into index.html.tmpl at report generation time.
Something like
#if $current.wh45_bat = 0
      <tr>
        <td class="label">$obs.label.wh45_bat</td>
        <td class="data">OFF</td>
      </tr>
#else if 
$current.wh45_bat = 1
     <tr>
        <td class="label">$obs.label.wh45_bat</td>
        <td class="data">LOW</td>
      </tr>

#else if 
$current.wh45_bat = 2   
   .............
#else

#endif

etc.

(there are more elegant versions by creating one or two internal tables/arrays with the SET statement where you have defined all your possible values against which you can then check in a loop, but the above solution will also work)

--
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/00ee8aba-985b-4a0a-b5bf-2d2b35e226ffn%40googlegroups.com.

Greg Troxel

unread,
Aug 14, 2023, 10:38:21 AM8/14/23
to 'Rainer Lang' via weewx-user
"'Rainer Lang' via weewx-user" <weewx...@googlegroups.com> writes:

> the driver only collects the data provided by the gateway API - and if
> you have created corresponding fields and assignments, weewx stores
> this data in the data base. That's it.
> There is no further code as far as I am aware of.
>
> Can you tell what exactly you want to do ?
> Display the codes as human readable text e.g. in the current value
> table (left side table) of the Seasons skin ?

This is really weewx-devel type content...

I'm not the OP, but for context rtl_433 has struggled with this as well.

The basic issue is that devices report battery in all sorts of ways, and
data consumers like Home Assistant and skins want a uniform
representation. When I look at a display with battery status for a
dozen things, I don't want to think about whether they are 1 for bad and
0 for good, the other way around, 0-1 for dead to full, 0-100, 0-5 with
6 external, or something else.

The Home Assistant way is to use 0-100% with 100% full. rtl_433's way
is to use "battery_ok" as 0-1, with 1 full/new. These are almost the
same, with HA normier and rtl_433 nerdier (shocking!).

Home Assistant also has the concept of additional state entities which
can be labeled diagnostic to make them secondary in the UI. Battery
level is already that (for say a water leak sensor that has a battery,
as opposed to a device whose main purpose is to measure a battery).
Things like "is this device powered by USB" isn't really battery status,
but Ecowitt has encoded it in a battery field (which is more or less ok
but it is how it is).

> On 14.08.2023 08:14, Daidl Himself wrote:
> I have a wh45, that gives me values 0-5 for Battery use and a 6 for
> external power. Where can I find the code to validate the staus as
> "OK", "BAD"or "USB" and change it accordingly?

I too have a WH45, and in Home Assistant it is showing up as 100%,
because rtl_433 reports it as 1.0. In json it says ext_power is 1, but
I am not representing that in Home Assistant.

The rtl_433 code says:

int battery_bars = (b[7] & 0x40) >> 4 | (b[9] & 0xC0) >> 6;
// A battery bars value of 6 means the sensor is powered via USB (the Ecowitt WS View app shows 'DC')
int ext_power = battery_bars == 6 ? 1 : 0;
// Battery level is indicated with 5 bars. Convert to 0 (0 bars) to 1 (5 or 6 bars)
float battery_ok = MIN(battery_bars * 0.2f, 1.0f);

which is consistent with what you say. 6 is a codepoint for external
power and contains no information about the battery. 0 is very low and
5 is great.

Note that with this encoding, if on external power you cannot tell what
the battery level is. rtl_433 calls it 100%. (You could argue that it
should not be reported.)

Now, what is "low?" Hard to say, but in my world 3 will read as 60%.
If I ran this on battery, rather than just having batteries to avoid
sensor reboot and bad values when there is a power blip, then I'd know
the trajectory of a dying battery.

On a WH41, 3/60% is ok and 2/40% is a sign that trouble is coming.
1/20% is really thin ice and 0/0% indicates imminent failure. That's
from experience with it outside with NiMH and the solar panel, which
seems to help a fresh NiMH charge last 6 months but not indefinitely any
more.

I don't meant to criticize a particular driver, but weewx might consider
adopting a regularized battery status and have each driver map into it.
I would suggest battery_ok from 0 to 1 and ext_power 0 or 1 to align
with rtl_433 since it is pretty common to get data that way, and the
world doesn't need another representation. That could be added while
leaving the others to not mess up other processing.

Then skin code could basically say

<40% CRITICAL
<60% LOW
<80% OK
>=80% FULL

or similar and use ext_power==1 to say "EXTERNAL". The point is that it
would not have to be adapted per device, as the adaptation is from the
device into weewx.

Of course, one could argue that you want to store raw data. So it
could certainly be both.

In Davis, at least before they went to the dark side with the 6313,
there is measured voltage for console batteries, and ISS status.
Meaured voltage (mine says 4.55V right now) is really nice to have since
it is so granular, but it could be turned into 95% by dividing by
1.6V*3. Yes I know nominal is 1.5V, but fresh alkalines are usually
1.6V roughly. Or you could divide by 4.5V instead, and thus be over
100%, and be more clearly connected to the raw data. Either is fine and
on reflection I'd go with 4.5V.

I have mapped ISS battery status in Home Assistant so that

1 (low) leads to 0%
0 (ok) leads to 100%

via

- name: "Davis ISS battery raw"
state_topic: "weather/loop"
state_class: measurement
expire_after: 330
value_template: "{{ value_json.txBatteryStatus }}"
- name: "Davis ISS battery"
state_topic: "weather/loop"
state_class: measurement
unit_of_measurement: "%"
device_class: battery
expire_after: 330
# Yield 100 for undefined, for now.
value_template: "{% if value_json.txBatteryStatus|float == 1.0 %} {{ 0 }} {% else %} {{ 100 }} {% endif %}"

(and for HA people, I should make it so that if the raw 0/1 is
unavailable/undefined, the processed value is unavailable/undefined, and
really templates should do this automatically!).

Rainer Lang

unread,
Aug 14, 2023, 10:54:52 AM8/14/23
to weewx...@googlegroups.com

@Greg
I cannot fully confirm your statements regarding HA
HA shows three different types of information regarding the Ecowitt battery status depending on sensor:
normal, actual voltage or percentage of charge, where in case of a WH45 the DC connection is shown as 120%
As these different scales have historically grown, we have to live with the diversity.

And - my suggestion can use text for status (as the OP seems to want to do)
OFF, LOW, MED, HIGH, FULL, DC covers all situations of Ecowitt sensors for battery status (except for voltage)
Sensors with two status can use only OFF and FULL
the others have a 5 or 6 tier status information
those with voltage can be simply display "as is":  x.x V

Greg Troxel

unread,
Aug 14, 2023, 11:29:17 AM8/14/23
to 'Rainer Lang' via weewx-user
"'Rainer Lang' via weewx-user" <weewx...@googlegroups.com> writes:

> @Greg
> I cannot fully confirm your statements regarding HA
> HA shows three different types of information regarding the Ecowitt
> battery status depending on sensor:
> normal, actual voltage or percentage of charge, where in case of a
> WH45 the DC connection is shown as 120%
> As these different scales have historically grown, we have to live
> with the diversity.

We have to live with it in driver code, but nobody else does.

I agree that it's a mess, but my point is that by defining a battery
status protocol where 0% is just about empty and 100% is full, and an
"are we on external power" protocol as 0/1, we can map all sorts of
things -- not just EcoWitt -- into this, and then people that want to
display battery status can rely on the 0-100% and not/external without
having to understand the device, either at the skin code level or the
brain level.

120% is not a proper representation for the WH45. Yes, it's 6 in the
on-air bits, but EcoWitt consoles/displays do not show 6 bars. They
show some sort of "external power" indication, per the rtl_433 comment
(which must have come from someone with such a display helping testing
or writing the code).

> And - my suggestion can use text for status (as the OP seems to want to do)
> OFF, LOW, MED, HIGH, FULL, DC covers all situations of Ecowitt sensors
> for battery status (except for voltage)
> Sensors with two status can use only OFF and FULL
> the others have a 5 or 6 tier status information
> those with voltage can be simply display "as is":  x.x V

That is a step in the right direction, but it still results in a
non-uniform representation which needs special case processing rather
than one which can be handled with one chunk of computer or wetware
code.
Reply all
Reply to author
Forward
0 new messages