Revised groups logic: members based on Entity, Area, Label, Device

Overview

I’m proposing a new way to populate groups. Rather than needing to update a list of static entities, the interface for adding to groups should be like the service call dialog:

image

For example, this is a Light Group that only allows light members. But this could be used for all applicable domains as is supported today.

The functionality to filter to the correct devices and entities for the domain has already been implemented in the service call interface.

This particular group’s membership is based on an entity, a label, and an area. This means that if I add a new device or entity to the included areas or labels, they will automatically be added to this group too.

When I view this group’s control panel from the interface, I would get an aggregated state like is the case today. And I would also be able to control it directly as a single entity.

Union or intersection?

The user could use “members who are in ALL of the following”, versus “members who are in ANY of the following”.

This way, the user can control entities that meet specific criteria, or control a whole heap of entities that are in any of the groups/labels/areas.

I would like this feature so that I can tell the status of a subset (label) of lights and switches. For example, know the status of my Xmas lights. Is there any other way to do this other than using Groups?

1 Like

Yes and yes. This would be amazing.

1 Like

Any updates on getting this done? I have 5 Chandeliers with 9 bulbs each that I would like to control the bulbs by different groupings and don’t want to have to manually put the bulbs into each of the groups when I already have the bulbs labeled by the groupings I want them to be: All Bulbs, Chandelier 1 (through 5) , and Bulb Group 1 (through 9). This will allow me to control all the bulbs at once or by each Chandelier as a whole, or Bulb 1 in each Chandelier through Bulb 9 in each Chandelier.