I do agree about the “templates reset” case.
Here what happens with 2 template binary sensors - a “normal” and a trigger-based (both depends on some “input_boolean”, the 2nd is triggered when this “input_boolean” changes):
The “input_boolean” on the top, the trigger-based sensor - on the bottom.
So, both sensors become of “undefined” state (even not specified here - may be “unavailable”, unclear for me), the “normal” sensor becomes “unknown” at HA reboot, but the trigger-based sensor does not change it’s state at HA reboot.
So, I even do agree that both sensors may have reset “last-changed” after “templates reset” - but I do not agree that the trigger-based sensor have “last-changed” reset on HA reboot.
I’ve been using the solution posted @TheFes for a few days successfully (thank you!), however I’ve noticed the following error message in Studio Code Server:
I believe this has only started showing since updating to 2023.5.3 and Studio Code Server 5.6.0
That line is how you get the data out of the template sensor again.
You can use it where you want, but if course that place needs to allow template sensors
Can I give this topic another nudge? I have a suggestion that maybe makes this more likely to be implemented:
Add two fields to the states table in the database:
last_communicated_state:
This will normally just reflect the same value that is in state. However:
It can only be unknown upon sensor creation if the sensor has a state of unknown or unavailable.
Once the sensor has any state besides unknown or unavailable, this value will reflect that state.
If the sensor state ever reverts to unknown or unavailable this value will not reflect that. It will not be changed and therefore retain the previous value.
last_communicated_state_change_ts
This will be a timestamp which changes any time the last_communicated_state has its value changed.
Having the last communicated state in the database prevents having to do lookups when a sensor gets a new state and needs to determine whether this is a “real” change or not. It is also useful in scenarios where users want to ignore unknown/unavailable and just use the last known “real” value. Also it makes it clear that there is no request to change the functionality of the existing last_changed_ts and last_updated_ts fields.
The downside is that I have no idea how much extra storage this would require adding to the database.
Also, in regards to naming of these two fields, I don’t think it matters what it is called. Here’s some other ideas for people to chew on:
I can’t believe it, my prayers have been answered and I can finally get rid of my DIY solution! Great news!
Got my hopes up, I should have checked the link! I’m still hoping this is implemented at some point - I still have the same stance that it’s the expected behaviour from your standard HA users view.
an event is always fired when an integration sets the state of an entity, regardless of any change to the state or a state attribute.
Not really a solution. last_reported is always going to be the last time the state was written to. Not the last time it actually changed. You can check the PRs listed on the docs site. This does not change the behavior for last_changed.
So now you will have two state attributes that will be set to when Home Assistant started since last_reported will fire when the integration starts up (assuming it checks the current values when it starts) and it will also have last_changed set because last_changed is still set to the same value on load as before.