Yes it does.
Check out the note.
1 Like
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.
4 Likes
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.
2 Likes
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:
- It does not do what the name implies
- There is no way to see the age of actual data.
If so knowledgeable, Please also respond to my question in what scenarios last_changed and last_updated may be different.
4 Likes
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.
1 Like
Why not just read it from the docs.
You can also check out my most hearted comment on the forums from ~4 years ago.
2 Likes
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.
1 Like
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.
2 Likes
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.
2 Likes
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.
1 Like
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.
3 Likes
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.
6 Likes
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.
6 Likes
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.
2 Likes
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.
4 Likes
I’m not taking it personally at all. I’m trying to get you to follow the rules. As you can see, your issue was closed in less than an hour. I’ve also stated multiple times at this point that I want this feature. But you can’t get that though your head and you continue to argue by moving the goalposts when you’re proven wrong.
1 Like
Also, stop editing your issue. That issue is already closed. If you want this feature added, make a #feature-requests or continue with this WTH.
1 Like
It was edited before it was closed. But thank you, I guess.
You mentioned there were discussions about last_seen already, so there’s no point in opening a request.
I don’t believe it’s a feature request, and I believe it was being discussed in a WTH unrelated to the topic at hand.