#MQTT battery sensors expires despite updates

1 messages · Page 1 of 1 (latest)

rose drum
#

Hi everyone,
I have a bunch of TRVs that only report the battery state as GOOD or LOW.
I set the expire duration to 4200 s and the update frequency of the sensor to 3500 s. So in theory the sensor should always be available.

However, as you can see here, the sensors all become unavailable regularly and remain so for the duration of the update frequency, i.e. becomes available again after 3500 s.

Does anybody know why this is happening? Is it possible that this is a bug where the constant value is not considered when checking wxpirqtion period?
I.e. if the battery is Good and is reported as GOOD again, the system thinks that there is no sensor update and the expiration timer starts counting.

It seems like it to me but maybe someone actually knows or can see the issue in the code?

Thank you
Alex

Screenshot_20241112_101021_Home_Assistant.jpg
sturdy bloom
#

Zigbee2MQTT?

rose drum
#

Direct MQTT in this case. Bluetooth to MQTT via tasmota.
But for HA it is just the normal MQTT integration.

fathom heron
rose drum
# fathom heron What does your discovery info look like? 
{"state_topic":"tele/EQ3/001A2208B97D","name":"Battery","object_id":"eq3_living_room_battery","unique_id":"eq3_living_room_battery","value_template":"{% if value_json.result == 'ok' %} {{ value_json.battery }} {% else %} {{ states('sensor.eq3_battery_living_room') }} {% endif %}","icon":"mdi:battery-bluetooth","expire_after":4200,"force_update":true,"device":{"identifiers":["eQ-3 Living Room"],"name":"eQ-3 Living Room","model":"eQ-3","manufacturer":"eQ-3","suggested_area":"Living Room"}}
fathom heron
#

remove force update

rose drum
#

But isn't that exactly what it is for? To make sure the value is updated even if unchanged?

#

I added it for that specific reason 😄

fathom heron
#

that's for numerical history

#

you have a regular sensor

#

there's no need for it, it will just clutter your database

#

and it could cause unwanted behavior

#

(like you're seeing)

rose drum
#

So remove it only for non-numerical values? So leave it e.g. for the temperature sensor? Or remove it in general?

fathom heron
#

jsut remove it from your battery

rose drum
#

Will give it a try 🙂

fathom heron
#

If that doesn't work, then there may be a bug with expire_after

#

it's hard to say because you're pulling the state from the states table in your if statement

rose drum
#

I set force_update to false now and will see what happens in the next few hours.

#

Btw, I only set the force_update because I am filtering the data and wanted to prevent the sensor expiring due to lack of state change.
Will expire_after not expire if the sensor receives a constant value over and over again? Or will it remain "alive"?

fathom heron
#

it should remain alive

#

the force update is just to force the sensor to add a value to history

rose drum
#

So, tested with force_update: false and I am still seeing the same behavior.

fathom heron
#

are you sure the device itself isn't marking itself as unavailable?

#

look for errors in your logs

rose drum
#

I will monitor the MQTT broker and see what the published messages are. In theory there should be regular updates with valid data.

rose drum
#

Could not find anything that would explain the behavior by watching the MQTT broker.
Will check out the logs next.