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.
1 Like
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
3 Likes
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…
2 Likes
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.
3 Likes
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?
1 Like
I have an approach how we can do this,
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.
Bumping this, really annoying
Nice to quickly see when a device was last used, motion detected
5 Likes
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:
A lot of bumps. No code change 
3 Likes
I hope you found the answer since then, but just in case: last_changed records the last time the value was changed, last_updated the last time the value was given.
If the sensor receives a new value and it is the same as the old value, it will only affect last_updated, not last_changed.
Nah! I’m still running 0.94 and haven’t rebooted in years…
Yes, I have, thanks!
At the risk of being accused of throwing the baby with the dirty water, I wonder if it would be worth just removing these. Almost anything you base off of these will
- at best create many questions from household members and yourself of why the data seems wrong
- at worst, produce really wrong behavior that causes false alarms and notifications and family scares
For as long as we need to restart HA regularly – minimally once every few weeks to pick up latest updates, and for some of us, much more frequently, these fields are either useless or confusing or dangerous.
3 Likes
Big plus one. The only reason why I realized I needed this was the awesome multiple entity row card: GitHub - benct/lovelace-multiple-entity-row: Show multiple entity states and attributes on entity rows in Home Assistant's Lovelace UI
1 Like
Thereis one more downside of this, and that is current implementation of “device triggers”. If you don’t use state trigger “door sensor state goes from off to on”, but use “device trigger” su as “door opened”, it doesn’t hav the “from” condition. And that means, after restart, change from “unknown” to “on” happens, which triggers any automation that has “when door opens”. That’s clearly wrong, as the doors didn’t move an inch.
Zigbee lights supports one nice functionality: power on behaviour. And you can choosefor yourself whether you want the light to stay off or go to it’s previous state when power is lost and then restored.
Nabu Casa people think it’s absolutely necesary to change status of every single thing, and trigger all automations after restart, while users think the oposite (as seen in the votes and discussion in similar topics). Why not implement HA variant of “power on behaviour”? Just a simple boolean in settings. Do you want every single change sensor to trigger change and update last-changed after restart? Your choice. That would make Nabu Casa people have it their way, while allowing users to set it to their preference. Could that be implemented?
1 Like
Bumping this.
I have been trying to implement a watchdog for my MQTT devices to check when they were last seen, the current solution I have is disrupted on every restart. My logic is if an MQTT device last changed > 24 hours ago, then flag as potentially disconnected. If I restart HA (once a week for updates or multiple time a day if I’m working on something), I lose the last time the device checked in so my watch dog is useless for 24 hours after a restart.
Bumping this as well. I need to keep a closer look at by battery devices.
Just last week a Smoke detector (Fibaro) kept stuck on 40% battery left. DIgging in to it stopped logging changes battery/temperature etc for weeks already.