Closed shbatm closed 1 year ago
To add some context for ISY994 specifically, Insteon scenes are used in two main ways:
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.
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".
Can you explain what this solves that is not already solved by entities in areas (https://github.com/home-assistant/core/pull/42221)
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.
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.
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
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