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.
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).
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’ }}
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…
Any update on this? I don’t think the “last_updated” field should be updated when HA restarts. We only want the field to be updated when the device or entity sends a physical update, correct?
Making a area just like they did with Nabu Casa Alexa and Google.
Where all supported devices populate, and u can SELECT whats supported to retain the data.
Because i know there is a reason why they did not implement this by default, but making us selecting the entities from a list to include the last-changed or last-updated attribute would solve it.
So no reason to not do it, i did upvote it !
with devices i mean entities, sorry was for to long at homeseer.
Unfortunately, despite the great response in votes, the request has not yet been implemented. If it is helpful, I have shared some examples of sensors to keep the last_state on reboot.
Yep. Not so nice to have 100 sensors that tells you when you restarted Home Assistant as per current behaviour. More useful to preserve the actual last change/update rather than last restart of HA core
But for some reason, people developing the HA core does not like this so it probably will not happen. You will have to write custom automations/triggers and update the state of your additional helpers to fix this. Bloating everything.
It has been discussed before, and for a long time, e.g. here:
