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.
Mayybe let’s not go this route, ok?
Everything is being done because someone decided it to be like that. Every functionality, no matter good or bad.
In current implementation there are two issues:
If so knowledgeable, Please also respond to my question in what scenarios last_changed and last_updated may be different.
Regardless, it’s not a bug or an issue. What your asking for is a feature request. Don’t come crying here when your issue is closed because you arent following the rules of GitHub.
Why not just read it from the docs.
You can also check out my most hearted comment on the forums from ~4 years ago.
I use device trackers which report home or not_home these have attributes for latitude and longitude, when leaving home the device tracker updates the last_changed (and last_updated) as the state changes from home to not_home, whilst I am out and about the last_updated changes every time a new latitude and longitude is reported, but the last_changed does not, (as I am still not_home and that has not changed).
charlyr, well in your case the last_updated changes every time data comes in, which is good.
In all other cases, when data is coming, but not changing, it does not update, chis is not what the name implies.
I check the docs and this looks BS.
As per description, both fields change only when state actually changes.
If my window sensor sends “I’m still closed”, that’s an update, and should be logged.
I think that it works well how it is at the moment, and think that the previous comment mentioning a last_seen attribute would be the way forward with this (which is a feature request) last_updated to me implies that something was updated, and if nothing has changed then there hasn’t been any update.
well if last_seen is implemented, I don’t really care as long as it works.
However last_updated is still implemented wrong as it is.
You may be using it to refresh the map, since in your case the coordinates are changing. I want to use it to update my climate control strategy. I don’t really care what the temperature was an hour ago, I want to know what it is now and trigger automation/math/PID for every update I get, I can’t really trust the data that I have now. Different thing, same outcome.
Current implementation is broken and this field can now be used in only very limited corner cases, like yours.
It’s not implemented wrong. It’s working as intended, which is what you dislike. That’s it. That doesn’t mean it’s wrong. There’s a difference. Your single opinion isn’t going to change it or break the functionality for everyone else.
Yes, someone may have adapted their config to use this as it works now, and such change would break things for them. As many fixes do.
And it’s not a “single opinion”. An update is an update. If I write here I’m still waiting for this fix, it’s an update, even if I have not stopped waiting.
Anyway I have opened another issue to implement last_seen, since your friend rejected the bug report.
update: just for the sake of argument, I have just searched these forums for last_update and oh boy. Almost every hit involves misconception what this does and frustration, why it does not update as expected. It’s even mentioned a few times in the thread that you yourself have linked, petro.
Again, it’s a real issue.
Completely support this WTH. This is not a matter of opinion or dislike. Whether through a change or an added property, HA should be able to provide the datetime of last data received from the actual device.
The WTH is clear, the use cases are there, benefits have been outlined, this is probably easy to implement.
Yep, I agree. But I can guarantee you that it will not replace last_updated. I can also guarantee the behavior of last updated is not a bug.
Secondly, OPs way of attempting to circumvent the month of WTH by creating an issue against last_changed completely defies the rules of the month of WTH as well as GitHub. Personal opinions are not bugs. There’s no room for argument there.
I believe you are taking it way too personally, since clearly you are deeply involved in this.
It’s WTH, because yes, it did not work as I expected to, and my quick survey shows that many others had a similar experience, back from 2017 even.
And others seem to agree.
You may say it’s not a bug because documentation almost clearly states how it works and you may be right, in theory.
Admitted as bug or not, still an issue without solution or at least sensible workaround at the moment.
Anyway I made my point. Thank you for attention.
