When I put something like this:
- entity: binary_sensor.door_voordeur
name: Voordeur
secondary_info: last-changed
The "last-changed " info is reset on every HA restart. This is rather annoying as Im restarting HA quite a bit, and for some sensors Im actually interested in how many days its been since they triggered. Is there a way to prevent this?
Your best option for last_changed to survive restarts is to make a sensor to store the last changed timestamp. Otherwise on restart all sensors are re-polled at startup and that’s the last time they changed. You could also look in the history tab, as that will contain the full history.
They didnt change though, certainly their state did not and I see no reason “last-changed” would show something different than history. Is there a good reason why it behaves differently?
Creating 16 extra sensors and automatons is a work-around Id rather avoid if possible.
It doesn’t matter if the state was the same as before, as soon as HA restarts it polls the state and updates the sensor, therefore the last_changed attribute is updated as well.
I’m not sure, but it could even be that all sensors are “unknown/unavailabe” at start and then the state gets pulled and then it would be a state change.
Currently, the history is not restored on startup to the state objects. When home assistant starts up and loads the objects, its going from a blank state to a filled state. This is when it updates. The logic for when items are changed is not actually stored in the history, just the actual state updates. So even if home assistant were to restore the last state, it would not be guaranteed that it was the last time it changed. This has been a requested feature for some time but I believe it is a low priority seeing that most of us keep HA running for months or years without restarts. Also, restarting won’t be an issue as much in the future when all integrations are built into the UI. So unfortunately, this is something that you need to work around.
Doesn’t an upgrade to a new version (which happens almost weekly [including the minor #.#.x updates]) require a restart? I personally think the longest I’ve ever gone is 2 weeks w/out having to restart. I’ve been running HA since ~May.
I mean, that’s if you keep up to date. My record on my ‘non-dev, running the house’ instance is 7 or 8 months. Currently, I’m at about a month. I only update when I see changes that I want. I don’t forsee updating until zwave is stripped from HA and new method is added which is going to happen sometime next year.
Also, I’d like to point out that I’m not a dev. I didn’t make any of these decisions. I’ve just read the threads related to the requests. So please don’t argue me on why it’s a low priority.
Yup, completely makes sense. I personally update whenever #.#.2 or #.#.3 comes out just to stay up to date(ish) - and it clears my last_changed as well, so been contemplating adding variables to save this date, but doesn’t affect my life negatively enough. Nice to have vs. need to have (aka. PITA level associated w/fixing).
Certainly not arguing w/ you (or the powers that be that DO make the decisions)!
I agree. I’ve been toying with the idea of having an app daemon automation that fires at startup and restores the last_changed to all states that match an ‘on disk’ database. The problem is that I’d need to create a bunch of listeners and store last_changed values on disk. And I’m not sure if it would hog resources.
Sorry, I was trying to point out that “I’m just a messenger”. It probably wasn’t the best way to say that.
Based on what I’ve read and coupling that with the lack of changes related to startup restoration, it seems like they are treating this like a low priority.
I have more than 100 listeners and no performance issues with AppDaemon, I’m sure you won’t notice anything from the listeners.
yeah, i’m sure it’s nothing. I’m in the 100’s now but this app would add 500 or so to my instance. And i’d need to build a filter. TBH now that I think about it, I’m just being lazy.
There is some irony in the fact that adding a sensor template to work around this issue requires a restart. And that not adding 500 and scripts to update them is considered lazy 
Perhaps a workaround is making this polling on startup optional for a sensor? There is no point polling a door sensor, it wont respond. Just initialize it with its initial state. Or better yet, its last state.
I’m curious, what are these ‘on_disk’ sensors? Are you watching all the files whether they have been changed or not?
Oh no, it’s just easier to save the state to the hard drive in a file than it is to look through the history with appdaemon.
EDIT: I’m not even sure you can look through the history yet. But I’m running 3.0 atm, haven’t moved to the beta.