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