PLEASE go vote for this... even if you dont know what this is, trust those of us who create add-ons and blueprints... This Is Needed and causes a huge problem with standard logic when the system restarts (even if only part of the system restarts).
Summary: At HA restart (YAML reload), HA wipes these values and replaces it with the restart time of the system... really bad design, not a single good thing about it.
There have been dozens people, over multiple years, posting on this forum and others have asked the core devs to fix this (yes fix - this is a design flaw 100%)
An nice dev built an add-on as a work-around but its shameful this is even necessary.
It is excellent design. The values really did change.
Your sever has no idea what happened while it was off so before loading an integration and restoring entity values they are marked as unknown. As they really are unknown. To do anything else could be dangerous. So they did change from unknown to some value.
For this reason the behaviour of those properties are unlikely to change. There is however nothing to stop development of a new property that reflects the last time the entity was known to change other than a restart.
Ah, NOPE... unless you can provide specific docs, the way I, and dozens of others, understand this is nothing inside the Home Assistant State object is designed to provide a reboot-persistent “true last changed timestamp.”
Having real Last Changed data (persisting across reboots) is important in home automation for many reasons.
The current design where that data is flushed, is a bad design. If it was a good design there would not be tons of people for many years, asking for it to be fixed. I'm not interested in discussion or argument. If you dont agree, dont vote for it.
@tom_l here's one way I hope you use this flawed design you like in the real world...
Next time you take a long road trip with friend/family/etc please use the same method to measure your time for when you 'left home'... when you stop for food, gas, bathroom break, etc... your measure of "We left home N hours/mins" restarts.
Then make sure to stop 15 minutes prior to your final destination. That way the prior 3,4,5, etc hour drive did not count! When your kids/wife/etc ask, how long ago did we leave home, you tell them it was only 15 mins ago since you restarted the car only 15 mins ago.
Save the timestamp when you leave home. Problem solved. I do this for an exact runtime for my dehumidifiers.
Assuming an entity has not changed while home assistant is off is, as I said terrible design. e.g: I want to be absolutely sure my door mounted automatic shotgun is still disarmed, not just assume someone has not changed it while home assistant was off.
Contrived example but there are similar real world situations like not running an expensive pump dry.
The data may be accurate, but if the system is simply collecting accurate, but not useful information that is bad design. Well designed home automation systems, collect and present useful information in a timely manner. If the data is not useful for presentation or automation why is it even being recorded? The last time i restarted HA is not relevant to the device.
I might simply be taking this wrong (easy to misinterpret tone via written word), but I feel some not insignificant snark in your post and replies - possibly one of those "catch more flies with honey" situations, but idk
And then they ask "What? We gave you that nice travel log as a gift to keep track of our family road trip and you didn't even bother to use the tool we provided?"
Sorry, had to finish that story.
I assume you are aware of template sensors and helpers that are available for tracking things like that. I have a bunch of templates where I stuff timestamps into attributes based on some trigger. I really like being in control of what is saved and when. Most of my entities I don't care about.
I think the design for sensor and such is correct. HA is in the end reporting on its knowledge of the state of a device.
But, there is a other case which I think could be debatable (and arguably cause an inconsistency). I don't get why these last_* properties get changed to the current value upon start-up for automations. Automations exist only within the realm of HA. For example, I want to know the last time the automation triggered (the attribute last_triggered, but for some reason that is updated upon restart. I can solve that with a helper, of course.
Last Changed - should be a time stamps that never gets reset to zero unless it is new to the system.
... right now, this property is ALWAYS 100% of the time wrong on restart -- and for a decent period of time after for most devices/entities... it cannot be used in automations the way it should. Thus at a period of time after a reboot thousands of data points are wrong and not usable in automations, scripts, etc. Many, like myself, have thousands of entities (I have over 7500 and growing). Manually creating a hundreds of helpers to make HA work properly is a horrible answer.
Mother: "Hi Jonny, when did you get your haircut last?"
Jonny: "10 seconds ago, I just woke up from sleeping."
Mother: "Oh silly me, I forgot all time frames for things that we Last_Changed in our lives resets after we wake from sleeping. This morning your father an I just got married, we just bought this house this morning, and you are only 10 minutes old. Please drive safe to school... you're kinda young to be driving.
I get it. It’s probably common that one tries to use last_changed in an automation and discovers it isn’t what it was assumed it was. I remember that myself.
Home Assistant doesn’t seem like a place to store last haircut dates as (for now) it doesn’t give haircuts. But if I want to know what time we closed the front door four days ago I look at the history or log book page.
You really are not going to need a persistent last_changed for all those 7500 entities either.
Do you have an actual automation where this issue was a problem that you could share? Might help others to see a real use case and offer possible solutions.
100%, for example for physical sensor entities that makes sense. Remember I'm referring to automations (the automation itself), which has no life beyond HA, so arguably their states are 100% known.
[quote="busman, post:11, topic:1010612"]
You really are not going to need a persistent last_changed for all those 7500 entities either.[/quote]
I have ~300 entities that need Last_Changed to persist. Still not the point. The current Last_Changed design is completely flawed / incorrect.
We dont need 'possible solutions' (workarounds / hacks), we need the existing feature to work properly.
Read the FR and search for the multiple posts and FRs that have gone on for multiple years.
This is not 'me' this is 'us'. Many, including myself, have multiple automations, templates, scripts, and dashboard cards that rely on an accurate Last_Changed. For those of us that do serious/complex code integrations and blueprints and dashboards for ourselves, and others the way it is today causes a lot of problems.
You do understand that it's your opinion (sure, shared by others) that it should work differently than it does. And there's others that agree that is works correctly.
But using the tools provided by HA is not a hack or workaround at all. It's using the tools provided to you for accomplishing tasks. Often people can't figure out how to do something and post their yaml here and ask for help.
Can you post a yaml example of an automation where this is causing you a problem? I assume this came up because you ran into the issue in an automation, right?
I can see the last_reported in the Template Editor, but not as an attribute in Developer Tools - States, and it's not available as a secondary attribute in an Entities Card. Will these be updated to include it?
You have been told it already exists yet go on and on. Why don't you switch to using last_reported and stop the rant? If last_changed is altered to do the same as last_reported, then it is a huge breaking change to remove something that has its uses too, leaving us with two identical timestamps. Just get used to the other name for it.
As I said earlier... ALL 'State' property have the same problem, they are all reset on restart/reboot. test it yourself; dont blindly believe me or anyone else (who may have said it is the "answer" when it does not)
If you can show 1 example where changing Last_Changed to persist across restart would be a breaking change then you'd be the first, and only, person to do so.
