I would really like to see the last state change of an entity retained through a reboot.
My use case:
I have a binary sensor talking to a remote Hikvision camera’s PIR motion in my mother’s apartment. I know I can drill down into the state history, but it would really be nice to know that the at a glance “12 minutes ago” is an accurate indication of last motion detected, and not just the time since the last reboot.
Thanks.
Also would like to see a bit more precision than 1 hour. if it’s been 1 hr 58 minutes, I’d like to know that it’s considerably more than 1 hour.
I just found out this unfortunate truth as well. Would be great if this field could persist through reboot. Makes any tinkering very difficult.
A logical flow would be “update last_changed if state != previous state”. Would likely only work if history/recorder was available for the entity.
This is a frequently discussed topic on the forum:
A cursory look at the codebase indicates that the last_updated and last_changed variables are defined whenever the class is instantiated ie. on a restart?
I’m sick of this and am trying to write a custom component that would allow you to specify a list of entities and have it save/restore the last_updated and last_modified times automatically. The component I care about (alarmdecoder) doesn’t inherit from RestoreEntity so the fix in the github discussion doesn’t help.
I’m starting by just trying to load an entity (“binary_sensor.front_door”) and change the last_changed state. I can grab the state object from the StateMachine (hass.states) and modify in a similar way to what the RestoreEntity is doing. That seems fine. But - I can’t get the data to show up anywhere. I’ve tried recreating what RestoreEntity is doing (firing an EVENT_STATE_CHANGED signal), grabbing the entity from the entity_components object, etc. I haven’t been able to find any way to trigger the front end to recognize the state change. AFAIK, the modified/updated times are not stored in the components themselves so changing it in the state machine should be enough (of course I could be wrong about this).
This kind of system (if it would ever work) won’t with restoring arbitrary state like sensor states since it doesn’t know what they are or how to push them into the entities. But I though it would at least be useful to be able to save/restore the update/modification times.
Bumping this. This feature requests is on the “top 1 page” of votes (i.e. first page if you sort on votes), and has existed for two years. Problem still exists. My front door has a last changed timestamp of two hours. But it has not been open since yesterday. However; i rebooted HA two hours ago.
If, for some reason, it is technically impossible to make the last_changed attribute to be persistent after reboot, or if it will break something else; then just create a last_changed_persistent attribute in addition to the already existing one.
One should not have to resort to making custom components, or adding a 50 line of code automation per entity to create this wanted behaviour. I have 50+ sensors, and all those automations will bloat HA. Is there even a slightest good reason for resetting last changed timestamp after reboot? I’ve heard reasons like “something could have happened while HA was offline”. Yeah, so what? The current behaviour results in one thinking it always changed during restart, which is more incorrect.
Could we provide a whip round and crowdfund the development of this?
100 votes @ 10 euros each would give us 2-3 days of core dev time?
I would definitely pay €10 in order to have this fixed 
This is my number one gripe with HA. Since you constantly have to reboot HA when making any config changes the date attributes are updated also. This basically makes the last modified and last changed values for all sensors useless. I don’t understand why this can’t be easily fixed?
I think this is the number one feature request on this site. I would pay real money to have this fixed. Can’t some kinda of a bounty system be set up so that most requested features like this one would have incentive to be fixed.
I think there are actually two (sort of) separate but related problems here.
Saving and restoring the state of the sensor can be done but requires each integration to write custom code and inherit from the RestoreEntity class in HASS. The problem with trying to make a general solution is that the state machine that stores the history stores a “derived” state. Say you have a binary_sensor that represents a door. The sensor object (and all binary sensors) has a boolean for on/off. But since it’s a door, that get’s translated to open/closed (and translated to your local language) which is what the state machine actually saves. So trying to make a general solution for restoring data from the state machine is either impossible (since each sensor class can store data however they like) or extremely difficult. That’s why the recommended solution is to inherit from RestoreEntity which calls a custom “restore this state” method on the sensor. That requires changing every integration you want to support that feature.
The second problem is that the last changed and last updated fields are never restored even if you inherit from RestoreEntity - they’re always the restart time. I tried writing a custom component to fix that but could never get it to work. The best solution I’ve found for this is written up here and changes the way the state machine works to allow those attributes to be restored. But it still requires each component to inherit from RestoreEntity for it to work.
IMO the best solution at this point is to get a PR w/ that modification to the state machine into the core HASS code (and hope it’s accepted) and then slowly file bug reports or PR’s to upgrade integrations to support the RestoreEntity framework.
If anyone wishes to submit a PR to address this issue, it might save you some time and effort to first propose it in the Architecture repo and get feedback from core developers.
The reason why I suggest you do that is because it’s my impression (and just my impression) that this issue isn’t seen as an actual issue by the founder.
I wish I could corroborate my impression with a more recent post than this one from 5 years ago. Nevertheless, it seems to have stood the test of time regardless of how many votes collected for Feature Requests or WTH.
So before writing any code, you might want to see if sentiments have recently changed (because if unchanged then your PR is likely to be rejected).
That’s a good one 
The thing I worry about is that the last discussion of this in the architecture thread seemed to say “do all the work and make a PR, then we’ll talk about it”. My read was that the core devs didn’t want to discuss the design of the fix, just whether a fix was ready for review or not. Maybe I’m wrong about that but that’s the way that conversation appeared to go to me. It makes it hard to want to put a lot of work in to try and design a fix knowing that it’s probably going to be rejected.
I didn’t get that impression. Frenck explained why it was closed:
… as you have clearly shown not to be implementing this and is merely an extension of the topics already listed in the openings post.
This is not a feature request forum.
If anyone wants to implement this; We are happy to see an architectural proposal with suggestions around implementation details that can be discussed.
Anyone who intends to implement it, and is able to explain and justify the implementation details, is likely to receive a fair hearing. It’s a vetting process, so the author’s proposal is subject to being challenged by peers.
If the author can’t implement the proposal, and/or can’t describe/justify its implementation details, the proposal is rejected (because it amounts to nothing more than a feature request). On rare occasions, a properly presented proposal is rejected because it simply doesn’t conform to the founder’s vision of how Home Assistant should behave.
Some sensors need to retain last data, some do not. So we need a parameter(an attribute of sensor) to indicate whether we need to keep the last real data at all.
But, first it’s enough if we can get the last real data of a sensor from the template directly
- platform: template
sensors:
weight_your_name:
friendly_name: "Weight Your Name"
value_template: >-
{% set weight = states('sensor.ble_stabilized_weight_miscale2') | float %}
{% if 60 <= weight <= 70 %}
{{ states("sensor.ble_stabilized_weight_miscale2") }}
{% elif weight == 'unknown' or weight == 'unavailable' %}
{{ history_query_first("SELECT state FROM states WHERE entity_id = 'sensor.weight_your_name' and state <> 'unknown' and state <> 'unavailable' ORDER BY created DESC LIMIT 1"), 'state' }}
{% else %}
{{ states("sensor.weight_your_name") }}
{% endif %}
unit_of_measurement: 'kg'
icon_template: mdi:weight-kilogram
it did not work for me. Maybe this is not working because of mariadb.
is this line still valid for data from mariadb?
{{ history_query_first(“SELECT state FROM states WHERE entity_id = ‘sensor.weight_your_name’ and state <> ‘unknown’ and state <> ‘unavailable’ ORDER BY created DESC LIMIT 1”), ‘state’ }}
If all changes that I might make to HA could be updated via YAML configuration reload or integration reload then I might not have to restart HA…
Restarts shouldn’t even have an effect on HA. They’re an implementation event. HA is a non-volatile server. As much as possible, they shouldn’t even factor into the entity-level. That’s how server applications are supposed to work. The metal could be rebooted, wiped clean and restored, etc. and HA should glide through it pretending that it didn’t happen as much as possible, abstracting those implementation details away from the user. It has access to its own history, so it’s perfectly capable of doing this.
Sometimes, you do have to restart HA (maybe for a machine software update). Those shouldn’t affect “last changed” or “last updated” at all.
If the HA logbook card and royto / logbook-card can retrieve and display the correct last transition state from logbook history, why can we not have an HA secondary_info: option like logbook-last-changed?? Better yet, restore the last-changed from logbook; if unavailable because logging not enabled for the entity, THEN set to current timestamp/last-updated…
Oh, and if someone could please explain the difference between last-changed and last-updated I would be grateful! I’ve never seen them differ…
