Create new ReadOnly Selector for presenting config entry data which should not change

[gjohansson-ST]

Background

In many integration config flows (and even more in helpers) users are having issues not knowing (remembering?) configuration data they have set during the initial creation of the config entry.
So in many cases they would expect to see this once they click "options" but as these are data that should not be changed they are not presented.
Example issue here were a user don't know what state characteristics he set initially on the sensor.

This only address the need of seeing certain configuration entry data during a configuration entry options flow.
As with below comments to see it elsewhere is not part of this proposal as that would not make it easier for the user.

Proposal

Create a ReadOnly selector that can be used for the purpose of displaying data which the user should not be able to change but would be good to see during configuration of options.

Pros

• Easy for users to see data which has been configured previously (in the same form as the options)
• With it's own selector we can make it more clear it's readonly and provide tooltip etc. Especially users has hard to understand why they can't change certain things which can be more clear using a selector (were we can even tell them they need to create a new helper (in such case) for changing some things.

Cons

• Some might clutter the form with not needed data or even not data but some other information?
• Might be hard to present in a good style (as the data can be string, number, dict etc.)?

Alternatives to consider

Could be presented in other manner in the form, use of description field or simply just skip at all.

[dgomes]

Some integrations are using attributes to do just that.

I've since moved to the diagnostics integration, and simply dump the full config flow

[AJediIAm]

I hope I understand the problem correctly and that the following alternatives fit to some extend.

Alternative 1:
Add a "Read Only" option as part of the entity configuration. Below the "Enable" and "Visible" options. The integration will still be able to change the entity as normal, but user changes on the UI will be ignored.

Pros:

• Prevent accidental changes instead of fixing them.
• Usable for all entity types.
• Saves the effort of manually creating read only equivalents.

Cons:

• Might result in misuse of read-only switch instead of binary sensor.

Alternative 2:
Add a standard "tooltip" to the entity. Integrations can add useful information such as a description and default/initial value. Users may be given the option to edit the tooltips.

Pros:

• Improve the self-documentation of home assistant.
• provide additional information to A.I. Assistants.

Cons:

• Significant translation burden.

Use cases:
My heat pump has many settings (selector, numbers, etc.) which I want to monitor but which I do not want to change by accident. The integration provides it as configurable (as it should), but I do not want to mess things up by accident.

[gjohansson-ST]

Neither alternative would allow you to see configuration data while changing configuration options so therefore I don't see these as alternatives.

[AJediIAm]

Apparently I failed to properly understand the problem. Can you elaborate a bit further?

[gjohansson-ST]

I only address that some data needs to be visible in the config flow when configuration configuration options.
Alternatives to see configuration data elsewhere doesn't help when you're in a config flow and it would be good to see data already configured but that is not allowed to be changed.

[dougiteixeira]

• Might be hard to present in a good style (as the data can be string, number, dict etc.)?

What if we just add a "readonly" property to the current selectors? That way the frontend would leave the field locked and wouldn't have a problem with the different data types.

[gjohansson-ST]

That is one of the alternatives but the downside would be that it might be "confusing" for the user why they can't change.
With a separate layout it could be more obvious that this is only for display and not changeable.

[balloob]

Don’t we already have this: https://www.home-assistant.io/docs/blueprint/selectors/#constant-selector

[gjohansson-ST]

Constants looks like a fixed value which you can turn on/off (never used it)? In this case it should be truly read only so the user could not change it and also make it more obvious it's for display.

[gjohansson-ST]

Closing as there is a better proposal here home-assistant/core#129456