"'Rainer Lang' via weewx-user" <weewx-user@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!).
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/rmio7j9ucx4.fsf%40s1.lexort.com.
