In binary_sensor, even if is_state is always true or false, the template is not

The current code leaves this decision up to integrations. HA core handles state restore but does not decide which entities to capture and restore state for. The python classes for entities which restore state inherit from RestoreEntity to make this happen.

Trigger template entities do restore state. This is because their state can’t be easily reconstituted otherwise. Their state isn’t updated until the trigger fires and that could be a long time after startup.

Non-trigger template entities do not restore state. Their state can be easily reconstituted by simply evaluating the template. Which is what HA does on startup already for all non-trigger template entities.

Because HA is already doing enough writes to the disk, it does not want to add more unless absolutely necessary. The way restore state works is every time the state of an entity which needs to be restored is updated HA writes its state to .storage/core.restore_state. So basically every state change of that entity is written to disk twice - once to history in the DB and once to this JSON file.

There’s no reason to do this if the state of the entity can be easily reconstituted as part of integration load. By re-running a template, contacting a service/device to ask for its current state, etc.

Even if the state can’t be easily reconstituted sometimes the integration author decides that it shouldn’t restore state. This can happen if the entity has very frequent updates. That would be a lot of disk noise or very little value since the integration will receive a state update shortly after startup.

Or perhaps the restore state feature really can’t work for a particular integration. Like the filter integration for example, which calculates the state based on a collection of recent state updates. Even if it kept the last known state through a restart that wouldn’t be helpful because it would’ve lost the collection of state updates it used to figure out that state. Now it becomes just one data point when before it was based on a whole bunch.

There are other examples. The point is its a bit complicated and as a result the integration has to decide what to do. Feel free to submit a Feature Requests for a particular integration if you think it should be restoring state and isn’t though.

2 Likes