I have multiple integrations, some are zigbee, some BLE, some HTTP/cloud, some modbus-TCP…
And I have noticed that I can’t know when the last value was received, if it’s unchanged. I have no idea if the sensor is dead…
For example in the screenshot below, it says last updated 2 hours ago, when I know the sensor should send data every 10 seconds. In this case I have no way to implement a fail-safe timeout.
For example, I had an incident where my BLE climate sensor’s battery died and home assistant was completely unaware of it for quite some time. What happened is my heater went in to thermal runaway, which could have ended badly if I did not return home that day.
I understand that HA may be avoiding to log the same data over and over again to save disk space, but it should at least update the “last update” timestamp?! It could do it only in RAM, and write to disk every 10 seconds or so to save performance and disk wear, but I should still be able to see if any data is coming. Also I would like an option to log every value, even if it’s the same, for some corner cases, like data analysis, etc. I can afford a slightly larger disk.
Also this BLE sensor. Is it just reporting the same value, or is it dead? Or maybe the signal is weak and only goes through every 5 hours? How can I know?
BLE sensors send data to home assistant, home assistant doesn’t request updates. That’s the nature of BLE sensors. All BLE sensors send information out at their own frequency, unknown to HA. When BLE sensors die, they do not emit a status saying “Hey I died”, they just stop sending information.
But I want to know when last data was actually received, not when the value has changed.
This is applicable to all types of sensors and the issue sits in the core of how HA works.
Also, just so we are clear here, BLE sensors are the only sensor that has this type of issue because it’s not an active connection. Everything else will go unavailable because the integrations know when the connection is lost. So there hasn’t been a need for this ‘basic issue’ before.
That’s not correct. I have the same issues with various other integrations, for example cloud services and local modbus-over-TCP. And also zigbee. It takes quite some time for values to time out and become “unavailable”.
I want to know the exact timestamp the last value was received, either changed or not. Only this would allow me to debug connection/signal issues and code various fail-safes with custom timeouts.
Modbus is local polling. It polls devices so things won’t go unavailable until the poll fails. That’s how polling works in general.
Zigbee has settings to increase or decrease the unavailable time through availability, like many other large integrations (MQTT, Templates, Etc.) So yes, it is correct.
and just to clarify about zigbee, because I have a feeling you’re going to argue this…
If you use Zha, you have to setup a polling automation using homeassistant.update_entity.
If you use Zigbee2MQTT, there’s a setting in the application, the default is a polling rate of 10 minutes and you have to opt in per entity (or all entities).
I don’t know about decons, but I would wager it’d be the same as zha.
First of all, not every developer has spent the time to implement availability, and those who did, did it differently.
I don’t know how many examples I will need to give you to make a point, but let’s try.
You are saying it is polling and it is easy to detect when there’s no response. In theory, yes. But no one has bothered to implement it. I am getting 35 entities from my solar inverter and since I have changed my config, some of values are no longer being sent. The connection is alive, but 10 out of 35 entities are “stuck” at old values and look like the same value has been sent for over a week now.
I want to know when exactly the last value was received.
Second example, xiaomi plant sensors. All of values are received via passive BLE, however battery entity is being polled actively, and often fails. There’s no way to know if the value is still being updated.
The device also monitors the voltage, current and power on each phase on grid connection.
The data is being polled from “cloud”. And it fails a lot.
When it fails, I see “real data”, same unchanging value for like 8 hours straight. No warnings and no way to check if it’s still alive. Basically I can only make sure by physically coming to the device and checking if green LED is illuminated…
With MQTT, you can configure an expire_after for literally every x2MQTT in existence. Just because it isn’t added in discovery, doesn’t mean you can’t do it.
Use ESPHome. I have these and they go unavailable after the expire_time when it doesn’t get an update from the sensor.
You have the tools to do all of this right now. Complaining about missing functionality isn’t helping anyone, especially when you’re complaining to a person who agrees that we need the functionality with the new BLE proxies.
the “last_updated” attribute should really be the time that the entity was actually updated and shouldn’t be filtered/manipulated by HA at all. Otherwise it becomes useless since the data can’t be trusted.
Every integration should work the same. There shouldn’t need to be any work arounds/jumping thru hoops for this basic and seemingly self-explanatory functionality.
IMHO, it isn’t “complaining” if the OP sees a valid issue, reports it in a WTH (which is the entire point of WTH) and then tries repeatedly to give examples of the issue. But that’s just me…
I don’t think that “last_changed” and “last_updated” are equivalent.
“last_changed” is the last time the data actually changed. if the sensor keeps sending the same exact data every 10 seconds for 2 hours then the last_changed should be 2 hours ago.
but the last_updated should be 10 seconds ago even if the exact same data was sent for 2 hours.
I think that probably depends on the integration. For example you have a esphome node that send a sensor value (for example 10°C) then (for whatever reason) looses connection with ha for a second or two it will send that (unchanged) 10°C sensor value again when successfully connected (again). In that case the last_changed is updated even the sensor value stayed the same
Another related issue - “last_changed” is equal to boot time, if server was restarted and if sensor is actually dead. It just takes the same dead value it had before server was rebooted, but forgets previous timestamp.
For example: sensor is dead for 10 hours and I see “last changed” 10 hours ago. Then I restart the server… And suddenly I see “last changed” a few minutes ago. Which is meaningless and misleading.
All of his examples are either custom integrations or have tools to get past the issue, except for BLE proxies. All to “win the argument” instead of discussing the actual feature he wanted (which we need). Sorry, but that comes off as complaining to me.
As for your comments, I think the best course of action is covered in another wth which mentions adding a last_seen or last_active property to all state objects.
Was just explaining how BLE sensors work, seeing that you had some miss conceptions about it.
