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:
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.
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.
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?
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.
We need this,
at least I need this
a change from 10.2 to 10.2 is not a change. some monitoring fails for me if I get an unexpected state update when nothing is changed.
however, this might affect automations as well.
if state = ‘X’ for 1 hour.
when will the automtion start checking? does a timer start at the beginning of this state change or will it be calculated back? becaust if the former is the case as automations do not survive a reboot, this part needs to be rewritten as well, And I think that would be the bottleneck here.
This is the graph showing my hourly rain rate… The red circles are when I restarted HA.
HA registers these as ‘updates’ even though there was no update, the value/measurement was unavailable for a brief period during the restart.
It would be good if there would be an option to not register a value/sensor being ‘unavailable’ as a value change since there was no proven change of value/state then (there could have been, but HA did not detect it as it was offline).
In SCADA systems, a measurement being unavailable is captured as its quality rather than its value changing which makes sense and gives the users (or the system) more flexibility. It would be good if HA could implement similar functionality.
Just came here if there was a “elegant” solution here. Only a feature integrated into the core can solve this. It kind of is also a basic feature I believe. I understand HA gets updates from the components and then sets the states, but until then there it is important to have prev state restored. most esp based solutions we have do not send this state to HA. instead we have to rely on prev state.
