Show all state attributes possible settings!

Feature Requests
1

Under Developer tools, if I show an entities’ state attributes, like my door sensor, I cannot see all the possible attributes SETTINGS. Like “logical_status: normal” what is the other possible status? If I open the door, it becomes “violated” which developer tools does not show. Please show ALL possible status variables. It would be nice if there were a “drop-down” set of choices I can set the variable to.

index: 1
physical_status: short
logical_status: normal
definition: burglar_entry_exit_1
area: 1
triggered_alarm: false
icon: mdi:alarm-bell
friendly_name: ElkM1 Front Door

2

Where do you want this “drop-down” to appear?

  • It can’t appear in an entity’s attribute value because an attribute is read-only (it’s set by its integration)

  • It can’t appear in an entity’s state value because that’s also read-only (set by its integration or by a service call).

3

The most useful place would be in the Automations UI. Which is why I tried Developer tools to find the attribute settings. Example: Alert me if my door goes from “normal” to “violated” for 5 minutes; somebody left the door open. I couldn’t find the potential settings without actually opening the door! Other sensors may be far more difficult to see the variables.
Isn’t this an obvious need???

4

I agree it would. Having said that, the frontend would need to access a resource that doesn’t exist. It would require a significant architectural change, affecting all integrations, to expose the required information to the frontend.

I’m not saying it’s impossible, just that the breadth and depth of the change is quite significant and therefore reduces the probability of implementing it.

Its absence hasn’t been a showstopper for tens of thousands of users over the past 9 years. You can determine the values empirically (as you did) or find them in the source code. Personally, I think the easiest would be to have them documented (no architectural changes or new programming required). Anyone can contribute to an integration’s documentation.

5

Taras you may be answering the question on feasibility; if major architectural changes are required then it’s a big feature.
However, Home Assistant has been evolving to make programming not require advanced programming skills. Parsing through source code is the opposite direction HA is heading. The goal is to make things easier to manipulate your smart home. My request is an obvious one, and I think HA should absolutely move to expose all variables like this to the front end. Again, isn’t this an obvious need (for the audience HA is trying to attract)?
The quick solution may be to have a template for developers to include these variables in the documentation. Documentation quality of integrations is, at best, random.
So, I recommend a more strict adherence to documentation quality standards, and to include this kind of information in all relevant documentation.

6

Isn’t this essentially what was added in 2022.9? From the release notes:

Last, but definitely not least, Frenck added some long requested features to the automation forms. State and Attribute value auto-completion! Now if you are adding a state trigger, you can choose from a list of known states for that device type. These are also all translated into your language. Now there is no need to remember or find the states possible or format the state that needs to be entered. Just choose a state from the dropdown and let your worries wisp away!

7

Yes I thought so too but I guess each dev has to update their extensions? Because I don’t see any yet that does this.

8

Yes, it’s available for certain integrations like input_boolean, binary_sensor, media_player, light, etc. Their state values are tightly controlled unlike a sensor whose state is free to have any value (essentially whatever its underlying integration requires). Every integration that creates sensors would have to provide the frontend with a list of permissible state (and attribute) values. That’s the part that doesn’t currently exist.

Currently, an integration’s author is required to document the integration. However, to my knowledge, there’s no template for it. You said a template would be a ‘quick solution’ so perhaps you can create one that meets your ‘documentation quality standards’. Offer it to the core development team to serve as the basis for existing and future documentation. That’s how open-source projects progress, through contributions.

Alternately, you or anyone else can update any existing documentation (correct typos, add examples and more explanations, etc).