Standardize the handling of entity attributes

[frenck]

Context

Entities can have attributes, while we try to reduce the general use of state attributes (as in most cases, they should have been separate entities anyways), there are still a lot of cases we have these attributes.

The majority of our integrations currently implement the existing behavior with these attributes:

• If the specific entity doesn't provide the attribute from the device, it isn't provided by the dictionary of attributes.
• If the attribute has no value, the attribute is removed from the dictionary of attributes of the entity.

The problem with this approach, is that in both cases, the attribute is not provided; thus it is impossible to differentiate between:

"Does not exist" vs "Does not have a value"

Especially the case of "Does not have a value" is problematic, as this causes unexpected behavior when one is automating with these attributes or templates; They end up throwing errors/warnings about non-existing attributes when there is no value provided at that point in time.

Proposal

We should prevent this unexpected behavior and reduce complexity in templates for these cases (as they now require additional checks). Additionally, add the possibility to distinguish between "does not exist" and "does not provide a value".

Therefore, the following proposal to document as the official way to handle attributes:

• If an attribute is expected to be there: If should be in the dictionary.
• If an attribute is expected, but is not providing a value right now: Its value should be None; and thus remain in the state attributes as a key/value pair.
• If an attribute is not (expected) to be provided, it should not be in the state attributes dictionary.

Clarification about expected attributes (Added 2024-01-11)

An attribute is expected if supported by the entity, for example as indicated by supported_features

Consequences

• We need to be keen on this during reviews.
• Adjust the developer documentation to add clarity on this.

[balloob]

Sounds good.

What about automation_id for automations?

[frenck]

That is used of the unique_id right? How is that related to the attributes?

[balloob]

It's stored in the state machine. Automatically set if using the frontend automation editor.

[balloob]

We could probably drop it though and use entity registry.

[emontnemery]

It seems there's consensus about the proposal. Suggest to approve it.