This is already possible. It’s usage is up to a specific integration implementation.
See https://github.com/home-assistant/core/blob/b8a8485e91bc64f6effeec83e1567497efa70bb3/homeassistant/helpers/restore_state.py#L283
This is great but still only addresses a small portion of the home automation scenarios for few reasons:
- The OEM decides the requirements for me. if I am using a baby monitor to track any noises in my garage then I really do not care about its safety features.
- It does not solve solutions where a generic hardware is used with a opensource software like D1 Mini flashed with ESPHome which can be connected with large number of generic sensors.
For a very good reason.
It has no idea what has happened while it has been off and thus requires an update from entities before changing from their actual state according to home assistant: ‘unknown’, to the new state.
2 Likes
The HA integration code is opensource and is independent of the OEM or manufacturer.
@tom_l you’ve been super helpful so really do not want to piss you off for a theoretical discussion 
But imagine if you bank’s computer wakes up from a fresh start not knowing how much was in your account before or after the transaction. You are assuming that entities knows best - I’ve two motion sensors mounted on a D1 Mini, one in my toilet to turn off the light and the second one monitoring the open/close status of my garage door. How will D1 know that the one in garage is more important? And more importantly who will implement the persistence since they are flashed with ESPHome?
All I am proposing is that HA team consider adding an option for persistence of state and leave the final decision to implement with end user. This will have an overhead (like certificates for SSL) which users can decide if it is worthwhile depending on their use case.
2 Likes
I’m calm as a Hindu cow. 
All things internal to home assistant (input selects, automation’s enabled state, input_numbers, etc…) are restored as there is no possibility of them changing while home assistant is off.
All things external to HA are not restored, they are marked unknown on start up because there is no way for home assistant to know what has happened to them while it was off. This is the logical direction the development team has taken. Just look at the recent changes to binary sensors in 2022.2.
I would be very surprised if the devs did an about face on this.
You are missing the point here, solving persistence of state (as or if needed) is HA’s problem and not OEMs.
Just like on a firewall, I’ve a choice on following:
- IPv4 or IPv6
- DHCP or static IP
- Port forwarding etc
Similarly the home automation platform needs to give me a choice where I desire persistence of state in a given situation.
1 Like
Nope. I’m not. You are choosing to give irrelevant examples.
Home Assistant will remember if you have set IPv4 or 6, DHCP or it’s set port number for example.
It wont remember things external to it that can change when it is not running.
The best you can do is ensure these updates arrive at home assistant promptly after a restart.
thats not entirely true. See my post above - every integration developer can choose to opt into this if they think it is appropriate for the integration.
@PanMat I don’t understand how the OEM would have to do anything with this. You are right, its HAs problem - and HA has a solution for this. But I don’t think it will become configurable in granually way.
One thing to consider is that the state of your bank account can’t be modified while the computer is down, motion can happen while HA is down.
1 Like
Neat. I did not know that. I bet the team are strict about the appropriateness of this for core submissions though.
Actually I don’t have the feeling they are. In KNX for example there are entities whose state can’t be read from the bus - these are restored while others that can be read are not (except for binary_sensors which are always restored because many users automations caused troubles since 2021.10(afair)…).
Calm as a “Hindu Cow” LOL 
full marks for humor 
At the risk of giving my age away, I saw the carnage of dot.com 22 years back and the sole reason was that companies could not differentiate between “expertise” and “expertness”. There were gas station chains rushing to get websites built because they heard about Dell making a killing with online sales!!
Fair point about development road map, so I leave it up to HA team. Here is the challenge with engineering mindset:
When you are writing a YAML code you tend to be an idealist!
Take location for example, between using ping and GPS location (from cellphone) most engineers would salivate at the prospect of lights turned on/off as you move through the house (after sunset) and literally no would consider ping for device_tracker
Reality is that I am less than perfect, my wife calls me when she is at grocery shopping and asks “If there is bread in the fridge?”. And I respond “no or yes” from the couch while binge watching Netflix. Can you imagine the ramification of using GPS vs Ping now? 
Bottom line: Home Automation needs to emulate personality of my house (my expectations of its behavior) and not a software engineer’s idealistic vision of it…cos its my home!!!
Why does one have to be more important? I don’t get the downside of querying them both concurrently at HA startup for their actual current state.
I don’t know ESPHome and its integration, but the persistence is implemented (or not) in its HA integration
Matthias,
Because you assume that device reboot state is the most “benign or truthful” one!
Imagine I have a D1 Mini flashed with ESPHome wired to a reed switch on the garage door. I go out the door in my car and press my mobile app to “close” garage door and drive away. The D1 reboots at the same time and garage door jams for any number of reasons, as per your logic, the D1 after reboot can ask for the state of garage door from the reed switch and it will get the status as “open” while completely ignoring that I wanted it “closed”.
In this example, HA instance is the best arbitrator of my wish that I wanted the garage door closed.
HTH
Tom,
This is the travesty of creativity - not finding a landing strip if I were flying a plane in 1505 
Thanks,
Pankaj
I have no idea what that means. Anyway I’ve said my piece. We will have to disagree on this one.
One has to keep in mind that HA is a state machine, not a database.
As a reminder, the recorder integration, that writes states/events to a database, is optional. Without it, HA runs as a pure stateless, in-memory, machine, which makes the “Bank account” example irrelevant.
As indicated above, specific integrations can choose to save/restore states where applicable. That system is different than the recorder database.
As a counter-example, if HA is down for a sizeable amount of time, e.g. 1h, the temperature of room X 1h ago is quite irrelevant, so it doesn’t really make sense to save/restore that value…
As such, having HA-wide state save/restore doesn’t seem neither appropriate nor desirable.
1 Like
There is a 3rd party integration on HACS to do what you want… its called Saver and its examples are pretty much your use case.
HA being “toast” is your best rebuttal…then I concede!!
Your wording is obscure. What do you mean by that?