Device options

[pvizeli]

Context

The circle with options is not closed today. We have System options, integration options but no device options. Device options are a bit different from the other options. Some device options also want to be used on UI, others only on the device page.

Today, there is a big gap between the ways how device options are exposed to an integration. Some use entity and others use service. If you are using an entity, based on the number of options, it ends up with tons of entities getting a mess on the auto UI. It isn't nice for the representation and user experience for new and exists users.

Proposal

We create a new entity device class option for:

• switch
• number

We can filter such entities on the device info page and group them differently from the real data endpoints. Future, we also need a new integration select to allow value selection, which is also common for options.

Consequences

All integration uses this device class to expose his options to his users.

[emontnemery]

@pvizeli Can you explain a bit more what you want to do, do you mean we should encourage exposing device options as entities but add the option and use that for filtering?

I started a bit on another route where device options would be exposed through a WS API, first step here to only display decice related information or status: https://github.com/home-assistant/core/pull/44055

[dmulcahey]

How would things like a code for a keypad be handled? Or lock codes? Etc. There are so many variations to this that I think a WS API makes more sense and integrations can choose to implement it. EDIT: would we have to implement some way to access these from automations, scripts, blueprints etc.?

EDIT: although, I can see entities being much easier to use for users in conditions, scripts etc. Are there any concerns in bloating the number of entities with entities that rarely change? would we now have entities that cover all of the helper types?

[tetienne]

From end users perspective, it seems indeed any easy way.

But for the dev, how easily test if an option is enabled?

[pvizeli]

Using entities was a long internal discussion, but let first look at what is around. The goal is to streamline device configuration/options. Currently, if you use 3-4 integration, you have 3-4 different ways to do that, which is quite ugly and bad for user exp:

1) Use their own panel / API 2) Services 3) Entities 4) External 5) Integration configuration 6) Mixup of 1-5 7) Nothing

The solution could be:

• Generic API / Panel (could be in device info)
• Entities which using device class option

Of curse, some integration has its own Panel for a reason; I don't attack this with my description.

I personally was a long-time fan of "Generic API, But Franck and Paulus are high fans of using that as a device class. That has the benefit, it's easy to use for devs, and users can use it with a different approach and inside scripts/automation without we need to build something completely new. I agree that HA works with the entity and device class, and with System Options and Integration Options, we have 2 completely different Option systems, which his own backend, which is IMHO fine for me and makes sense. The question is, do we really need a 3 different options system or that solved with the entities, like a lot of integration using it now... Of curse, we need some kinds of "Number" Integration like selection.

EDIT: I.e.

Someone will use the "night" option on Sonos the whole day, so he only wants once set this in the device info page. Someone other will make an automation to turn that on/off.

Of curse, with generic API, we can make also device_options service to call that. But it's still a switch. Do we need something new or do we reuse existing logic for it?

EDIT2: We already going this route with IRSS and Battery, implemented as a device class, and that works very well. Maybe also in the future with health.

[jesserockz]

I propose that select also be considered to be an option.