Access to configuration values

[Olen]

Context

There has been several discussions lately about accessing configuration values for integrations and entities from the frontend and from other parts of HA. Several PRs have been rejected on the premise "We don't allow storing config in the state attributes."
See e.g. home-assistant/core#42420 and home-assistant/core#41872

Now, I have not been able to find the ADR formulating this policy, and it is pretty obvious that a lot of existing integrations already add pieces of their config as attributes in the state machine. The plant component (which one of the mentioned PRs is about) does it. The "person" component exposes the config values "name", "id" and "user_id" as attributes, and many other integrations also expose config values such as "name" etc. as attributes - and for good reasons.

So there is an obvious need for at least some config parameters to be accessible from other parts of HA, such as the frontend, automations, scripts etc. But there are also very good reasons for not allowing access to all config for all integrations directly. So the question is - how can we allow access to parts of the configuration for an integration or entity from the rest of the infrastructure?

One easy solution is of course to be more lax in the "no config in state attributes" policy. That would simply have allowed the two PRs mentioned above (and probably others I did not find at the first glance), and nothing would need to change in the core code.
But if we really want to separate the static values from the configuration from the dynamic values of the state machine, we do need a way for developers to expose the neccesary config parameters to HA.

One way that was suggested in one of the PRs was to add a websocket command to expose the data. This can be done, but I don't really like the solution. First, it only gives the frontend access to the data, not automations, scripts and other integrations. And secondly, it seems overkill to open a websocket connection to do a "one shot" fetch of some data that will "never" change. In my opinion this could be accessed much more quickly and easily with less resources through other means.

Proposal

My proposed solution - although a bit more involved - is to create a new property e.g. conf in the Entity class. It does not seem like any existing integrations uses this name for anything (a quick grep 'def conf(' */*.py in components turns up empty), but what the property will be called is not important to me. Integrations can then populate this with the neccesary data.
It is important that this property should only be populated with static data - and only when the component is set up or the entity is created or configuration is changed. No heavy function calls should be allowed when getting the conf of an entity. Information such as usernames, password, keys, tokens etc. should of course not be added to the conf property.

@property
def conf(self):
  return {
    'name': self._name,
    'parameter': self._config.get('parameter')
  }

Then we expose this property to the rest of HA the same way the state and attributes are exposed today.
It would allow templates in scripts and automations to access the data with something like

{{ conf('entity_id', 'parameter') }}

The frontend can access the data using hass.conf['entity_id']['parameter'] and integrations can access the using hass.conf.get('entity_id' [, 'parameter'])

Consequences

This will make a clearer separation between dynamic data (state) and static data (configuration) of an entity. It will allow more flexibility for integrations to publish parts of their configuration to the rest of the HA infrastructure in a well known manner without touching the state machine.

The idea can be implemented as a non-breaking change, as it can be added without changing any existing integrations. Integrations can then be modified at their own pace, moving configuration data such as "name" etc. from the current state attributes to the new conf property. This will of course be breaking changes for the integrations as they are updated, but can also be done quite smooth by adding the parameters to the new conf property first, and later removing the state attributes after a grace period to allow frontend developers and automations some time to move over.

[balloob]

it seems overkill to open a websocket connection to do a "one shot" fetch of some data that will "never" change.

Disagree on the overkill. You will need the state too, so that's 2 API requests. Assuming you use it in the frontend, the connection is also already open.

We have Entity.capability_attributes. It allows entities to describe their capabilities (ie min/max supported color temp). It is being stored in the entity registry. It's currently still being written to the state machine too (but we can change that in the future).

[balloob]

Just a note as it relates to the linked PR. Min/max alarms are not suitable to be implemented as capability attributes.

[jansauer]

@balloob having a consistent way for entities disclosing there configuration wouldn't necessarily dictate how this information is transported to the frontend. I imagine that even without every card implementing and depending on websocket code the lovelace frontend could also use websockets for loading them from the backend.

[jcooper-korg]

Curious if there's any progress on this proposal? My PR to modify the manual alarm to publish its current state duration was rejected for the same reason (not allowing config-derived values in the entity state).

@balloob - if there's no plan to add a generalized solution like Olen's above Entity.conf proposal, then are you recommending I modify the manual alarm component to implement its own solution for config access? (e.g. via websocket as in Olen's PR 43035).

It seems a generalized solution would be far preferable to scattered ad-hoc implementations in all the components!

Thanks
-John

[Olen]

Moved this to a discussion here: #533