Allow entities to restore state on restart if information is unavailable

[alandtse]

Context

There are times when a API will not return valid data. For example, in Tesla, if a car is asleep or unavailable, the component will not get valid information with the API without waking the car. There are times when waking the car is not preferred because it will take the car out of a deep sleep state and thus increase the consumption of the battery. For example, if a Tesla is parked at an airport for long term parking, it should not be woken up. Per https://github.com/home-assistant/home-assistant/pull/31877 and @pvizeli, this requires an architecture change despite the existence of RestoreEntity.

Proposal

Restore state should be allowed for cases like this so that if HA is restarted, it will preserve the last known state.

Consequences

HA restarts will not show empty data for components that are not contactable.

[Kane610]

This is already possible today and it is up to the integration to set up.

from homeassistant.helpers.restore_state import RestoreEntity

Example: https://github.com/home-assistant/home-assistant/blob/0d874902cc75044e1146c6e64ae52aa2fe04dc50/homeassistant/components/unifi/switch.py#L152

[pvizeli]

@Kane610 we have the rule, only restore states if you can't read it from a device. The reason is simple:

I.e. you drive home with you care and the latest states is in front of your garage door. Now you have a power down and after startup he restore the state that the care is in front of the door and trigger the automation to open the garage door. Cool but not funny if you are not at home and the care is someone else. In case of that, we show all sensors as unavailable until we was able to get this data. Otherwise we can full restore the latest state on core and did not show that as unavailble.

We have device they have an asume state or are only fake states and they are anyway bugy, so it is a small helper for stuff like this.

Like I said, I vote to hold the strict guide line that only allowed to restore of the device/api/fake have no state that you can read or other calculated stuff.

EDIT: Also the new service helper respect the current state and did not trigger the service call if the device have allready this state. That is pretty careful if we have wrong states on the machine. A unavailable represent what it is and will be updated on next successfull retry automatic if the integration implement his integration correctly.

[balloob]

I think that the system is behaving as expected. I think that if Tesla doesn't want to update, they should mark themselves as unavailable until they want to update. However, since a restart is very rare, I also don't see the issue of waking it up once from a deep sleep.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck