State attributes for STATE_UNKNOWN and STATE_UNAVAILABLE

[andrewsayre]

In developing a fix for user reported issue home-assistant/home-assistant#20331 in PR home-assistant/home-assistant#20336, the solution was not accepted and it was suggested when an entity is unavailable (STATE_UNAVAILABLE) it should not set any state attributes.

In the current implementation of async_update_ha_state, it will set all state attributes regardless of the entity state/availability. Changing this behavior might be significant as core attributes like ATTR_HIDDEN would no longer get set.

Therefore, topics for discussion are:

What attributes should be set when an entity is unavailable (STATE_UNAVAILABLE):

1. None, zero, nada. We'll fix whatever breaks.
2. Continue populating attributes, but fix it so don't try to convert the temperature unit and set the scale properly (aka, accept the PR so we can close the user's issue)

What attributes should be set when an entity state is unknown (STATE_UNKNOWN):

1. None, zero, nada. We'll fix whatever breaks.
2. Continue populating attributes, but fix it so don't try to convert the temperature unit and set the scale properly (aka, accept the PR so we can close the user's issue)

Looking forward to the discussion!

[zxdavb]

In my case, I am polling a internet API for the state of a controller, and updating an internal data structure, which the (child) entities use when they update().

If the controller misses 3 updates, I mark the entities as UNAVAILABLE until the next successful update.

I have only had a brief read of this, but it seems that some state attributes, such as temperature unit, should persist even if we don't know the entity's current temperature.

[zxdavb]

@andrewsayre I'm still keen on this (but for a lightly different reason) - can we re-open it?

I'm advocating an attribute for STATE_UNAVAILABLE, and STATE_UNKNOWN that would indicate why the device is in that state, It could either be device_state_attributes or a new attribute.

With Internet-polled devices, the vendor API may report the device as failed, and provide a reason for that failure.

In these cases, it would be reasonable to mark such entities as unavailable and have any error message in the device's state_attributes (with that attribute == None otherwise).

However, available == False has the effect of removing almost all state attributes from the entity and so the reason for the failure is not exposed to the user.

We can get past the issues raised elsewhere by only having device_state_attributes, and not any class attributes.

This is what I get in the logs (edited):

new_state=<state climate.bathroom=unavailable; friendly_name=Bathroom, icon=mdi:radiator, supported_features=17 @ 2019-08-19T13:52:32.909199+01:00>

This is what I want (not necessarily activeFaults):

new_state=<state climate.bathroom=unavailable; activeFaults=[{'faultType':'TempZoneActuatorLowBattery','since': '2019-08-07T14:39:13'}], friendly_name=Bathroom, icon=mdi: radiator, supported_features=17 @ 2019-08-19T13:52:32.909199+01:00>

[balloob]

I agree that an unavailable reason would be a nice addition.

For the unavailable attributes, I think that it should be good to keep any attribute that describes the entity capabilities around. So we have supported_features, which is mostly enough, but not always. There is actually something to say of moving these also to the entity registry.

[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