RFC: Flexible Groups

As (among other things) discussed here the group is both a backend entity, i.e. something that has a state and can receive services like turn_on, and a frontend entity, i.e. something that groups other entities together in the UI.

The frontend functionality could be much better. I’m starting this thread as a Request-For-Comments for the design of this feature which I plan to implement as CustomUI / custom component (or in the main UI / HA if @balloob approves)

I would like to be able to create groups that change members in runtime. For example:

  • Group of all switches with on state.
  • Group of all entities with battery_level attribute.
  • Group of switches that have been on for longer than an hour.
  • Group with an ID that starts with “hello”

I’m aware some of those can be achieved by group services, but the config would be extremely verbose (track state changes and update groups)

Assuming UI-only implementation that allows to change existing groups only (each group could be created for this purpose by group.set service, how about xpath-like (or css selectors-like) syntax:

  • light.my_light for specific entity
  • light.my_* for glob/regexp entity match
  • light.my_light=on for state match. Can also be light.my_*=o* for glob match on both ID and state.
  • [battery_level] for matching attribute present.
  • [battery_level=0] for matching attribute value.

Alternatively, it could be a JavaScript function, that receives the entity. If function returns true, then the entity is part of a group.

I would like to get some feedback on both the general idea and the possible syntax before I start Implementing.

As far as implementation, why not a custom component that defines and manages the groups? Maybe I’m missing something but I’m not seeing why this would run on the frontend.

Depends if those need to be real groups that can receive service calls and have status.

Implementing on the back end have downsides: it needs to track all State changes and possibly update the group often causing recorder spam.

If implemented in FE then other clients won’t enjoy it, but computation is done only if someone is looking.