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.
First example, this addon:
TenySmart/ModbusTCP2MQTT: Sungrow & SMA Solar Inverter addon for Home Assistant using mobusTCP (github.com)
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.
Third example. Integration of EV charging point.
CJNE/ha-myenergi: Home Assistant integration for MyEnergi devices (github.com)
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.
I agree completely with the point of this WTH.
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…
might correlate with this WTH 
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.
Yes, mayyybe, but such basic thing should not need any tools or hoops to work around, it should just work out of the box.
I really hope that basic things like this will be done before some new fancy and exciting half-working features, as usual.
Just out of curiosity, how is it saved in the database now? There should be a timestamp with every datapoint anyway, right? So it’s just a matter of using it?
By the way this below seems to be incorrect. It’s a zigbee device with frequent broadcast. No way to check when was the last data received, but definitely not one hour ago.
Right but that has literally nothing to do with the original intent of the WTH.
Last_changed can be whatever it wants (at least related to this WTH even tho I think it needs re-worked as well and agree with your link) but last_updated should be exactly that - when was the last time that the sensor received updated data from the device/integration.
Both of those should work the way they are advertised (by the name they used) and are expected to work by users instead of the way they work now.
I have posted a bug report. Hopefully it will be fixed one day.
[BUG] last_updated is incorrect · Issue #81069 · home-assistant/core (github.com)
That will go no where. Last updated already has a meaning and home assistant follows that meaning correctly.
It does not.
In what scenario in current setup last_updated is not the same as last_changed?
Because all I see is them being always the same, and incorrect.
Yes, it describes how it is working now. But it’s wrong.
change is when value changes.
update is when value is updated to up-to-date value, even if unchanged. So the timestamp should be updated each time it’s received from sensor.
Yeah no. It’s correct. That was how it was decided to work. Not some random user on the forums who thinks it’s wrong.
