on AmbientWeather-TX8300 report Battery statur from rtl_433 MQTT Auto Discovery (next)

[Mark-Muc]

The problem

Hello!! just a question.
I own 2 AmbientWeather-TX8300 devices and i like to recieve the batterystatus from rtl_433 MQTT Auto Discovery (next).
It seems that rtl_433 MQTT Auto Discovery (next) whatches out for:
battery_ok
but the AmbientWeather-TX8300 don't report:
battery_ok
the report only
battery
so so status will be skiped .. like this:

[2023-12-20T13:16:33+0100] INFO:root:Published AmbientWeather-TX8300-1-98: time, channel, temperature_C, rssi, snr, noise
[2023-12-20T13:16:33+0100] INFO:root:Skipped AmbientWeather-TX8300-1-98: battery

So my question is:
were to change that also
battery
will be reported as well .. and to to be skipped,

MQTT looks like this:

AmbientWeather-TX8300
time = 2023-12-20T13:33:47+0100
id = 54
channel = 3
battery = 2
temperature_C = 4.7
humidity = 86
mic = CHECKSUM
mod = ASK
freq = 433.88909
rssi = -5.92413
snr = 18.22666
noise = -24.1508

Thanks for any help
Regards Mark_Muc

What addon are you reporting the bug for?

rtl_433_mqtt_autodiscover

What is the addon version?

next

What type of MQTT Broker are you using?

Home Assistant Mosquitto MQTT Broker

Addon log messages

No response

Additional information

AmbientWeather-TX8300
time = 2023-12-20T13:33:47+0100
id = 54
channel = 3
battery = 2
temperature_C = 4.7
humidity = 86
mic = CHECKSUM
mod = ASK
freq = 433.88909
rssi = -5.92413
snr = 18.22666
noise = -24.1508

[deviantintegral]

Does battery = 2 mean 2%? Or is it a state like 1 = >80, 2 = >20, 3 = >1, etc?

If you can figure out the mappings, then you could either manually edit the configuration topic in homeassistant/devices/… or work on updating the auto discovery script to configure it automatically.

[Mark-Muc]

Hallo and thank u for your respond!!
the Battery is like other devices .. you mentioned: 1 = >80, 2 = >20, 3 = >1, it's like that.

work on updating the auto discovery
How to do??
THX
Mark_Muc

[deviantintegral]

The script comes from https://github.com/merbanan/rtl_433 in the "examples" directory. So if you're familiar with the basics of Python, a pull request that's accepted in that repository will eventually make it down to this addon.

[riegelbrau]

I just have an issue with the script rtl_433_mqtt_hass.py (see merbanan/rtl_433#2776). In the mapping for battery_ok, the Jinja filter which multiplies the value by 99 and adds 1, leads to an error in my environment.
If the filter is corrected, devices with a decimal representation like 0.6 will get 60% as the result. The battery_ok status from devices sending values 0 and 1 (I have some) will result in 0 or 100, which is OK for those.
This filter would not fit for the AmbientWeather-TX8300, which I own as well. I fear that rtl_433 needs to be changed to send a special field name and the script then must to be adapted to interpret and transform those values.
I woul appreciate a solution, too!

Regards
Christoph

[riegelbrau]

I now created a dirty workaround in rtl_433_mqtt_hass.py just before the mapping for "time":

# Battery missing for AmbientWeather TX8300
"battery": {
    "device_type": "sensor",
    "object_suffix": "B",
    "config": {
        "device_class": "battery",
        "name": "Battery",
        "unit_of_measurement": "%",
        "value_template": "{{ ( 100 / value|float ) | round(0) }}",
        "state_class": "measurement",
        "entity_category": "diagnostic"
    }
},

After rtl_433_mqtt_hass.py has run again using the parameter -r and an update message appeared, I've got 50 for the value '2'. A value of '1' will be transformed to 100 and a value of '3' will lead to 33. This is pretty much better than no data at all.

[catduckgnaf]

@riegelbrau can you submit a pr for this to

I can add it to the discovery script there, I have a fast moving and improving script. Mind helping out?