Device Creation / Area Assignment for Groups/Scenes in External Protocols

[shbatm]

Context

Several external protocols used in various integrations allow the creation of Scenes or Groups and these have a varying degree of representation in Home Assistant from use as a service (hue.hue_activate_scene) to inclusion as a switch (ISY994). However, since these are not Physical Devices they cannot currently be added as a Device in Home Assistant for direct use in Automations or be assigned to Areas.

The Device Registry currently describes a device as a "physical device that has its own control unit."

This applies to Z-Wave Scenes (Z-Wave, OpenZWave, Zwave2mqtt), Zigbee Groups (ZHA, zigbee2mqtt), Insteon Scenes (Insteon PLM, ISY994), Hue Scenes, and RF protocols as well like RFLink (Shade/Blind Groups, RF Relay Groups, etc.).

This originated with a question from @rmkraus here: https://github.com/automicus/PyISY/issues/131

Proposal

Amend the Docs for Device Registry to allow "Virtual Devices" be created in Home Assistant as well as just physical to allow devices to be created for external protocols' scenes/groups/virtual devices. This would allow them to be added to areas, as well as device triggers, conditions, and actions to be created for use in Automations (e.g. "When Insteon Scene Y turns on, do X").

Consequences

Allow better support for external groups/scenes within Home Assistant by using them as devices. This will allow for adding them to Areas and adding device

Just a note: I'm limiting this to a small change of just allowing integrations to create virtual devices for these right now, but I could see this being expanded down the road for better integrated support for these external protocol scenes and groups, such as better / more consistent editing from within Home Assistant, and adding/viewing the children/responders of the Virtual Devices by adding additional connection parameters.

CC: @bdraco, @OverloadUT, @teharris1

[OverloadUT]

To add some context for ISY994 specifically, Insteon scenes are used in two main ways:

1. As a mood scene, true to the "scene" name. Maybe you've got a movie viewing scene, or a arrive home at night scene, etc. Most people probably understand this concept very easily. You trigger them when you want a particular mood.
2. As a critical core method of control of certain devices. For example, in a 3-way circuit, both switches are set up to control a scene, which consists of both switches in the circuit as well as the load (the actual lamp). This is a case where the scene truly represents a physical situation. When you've got this set up in Insteon, you never want to control the low-level devices (each individual switch) because it would cause them to go out of sync. Thus, this is a very common Insteon use-case where the scene, for all intents and purposes, is the device (the lamp). An important note here is that scenes in Insteon can be turned on and off, which is what makes them truly behave like devices. Really they could be called groups rather than scenes to better understand them.

Another example of #2 here could be having one light switch in a room control 3 separate lamps simultaneously. This is another case where all three lamps will ALWAYS be controlled together, and the switch controls the scene/group directly. The individual lamps CAN be controlled, but the group is treated as a first-class device in the Insteon ecosystem.

I think the two examples of #2 above show the clear need for these types of scenes/groups to be able to be treated as devices in Home Assistant, or at least treated in some other way that allows the device-like functionality.

[shbatm]

Thanks for adding the context @OverloadUT -- said better than I would be able to articulate.

I'll also add that Zigbee and RFLink groups can also fall into the same category as (2) above, just like Insteon groups/scenes -- multiple physical devices can be controlled directly through a "group", and they may be devices that you always want to control together (e.g. multiple lamps in a room), but do not fit the definition of "a physical device".

[balloob]

Can you explain what this solves that is not already solved by entities in areas (https://github.com/home-assistant/core/pull/42221)

[shbatm]

I think home-assistant/core#42221 would certainly take care of half of the issue -- adding these entities to Areas, but it would still leave you without the ability to add device triggers, conditions, and actions to be created for use in Automations.

A workaround is to use the service calls against the entity_id (e.g. switch.turn_on) but it would preclude the use of the newer device triggers and conditions for these entities.

[teharris1]

I have been asked a similar request on the Insteon side. Unfortunately, I don't agree with creating scenes as devices for a few reasons. Most importantly, an Insteon scene is a trigger, not a device, therefore it does not have state, The devices that the scene triggers have state. I get the idea of having one "entity" that can turn a scene on/off and could give you the state of the scene but that has a lot of challenges to it. For example, the definition of a scene would need to be exposed to HA in some way that it could know the state of the scene and it needs to know the state of each device in the scene. This could be done manually today with a combination of a helper switch and a few automations. It does require redefining the scene in the automations and it requires the user to have a technical ability to think through the scenes, but I believe it can be done.

Perhaps the best answer is to extend the current HA Scene capability to include platform-specific scene features. This way, inside HA you could create an HA scene that can be cross-platform actions or a platform-specific scene that would then be a first-class object in HA.

Regarding the 3-way switch issue, what I think I am in favor of is extending the current Group capability to enable the on/off state of a group to be defined by a Scene definition.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck