"New style groups": allow for empty list of entities

Feature Request

Allow to assign an empty list of entities ([]) in “new style groups”.

Use case

Right now, the entities key is required and cannot be an empty list, which forces me to do workarounds:

# https://www.home-assistant.io/integrations/binary_sensor/
binary_sensor:
  # https://www.home-assistant.io/integrations/group/#yaml-configuration
  - platform: group
    name: Kitchen motion sensors
    unique_id: kitchen_motion_sensors
    device_class: motion
    entities:
      - binary_sensor.virtual_motion_sensor

This is not a requirement for “old style groups”: I can have an empty list of entities:

# https://www.home-assistant.io/integrations/group/#old-style-groups
group:
  kitchen_motion_sensors_old:
    name: Kitchen Motion Sensors Old
    icon: mdi:motion-sensor
    entities: []

The problem with “old style groups” is that they are missing the possibility to define unique_id → therefore cannot be managed from GUI → therefore cannot be assigned Areas and Labels…

So… we’re in a mess, where “new style groups” can be managed from GUI, but can’t have an empty list of entities, while “old style groups” can have an empty list of entities, but can’t be managed from GUI. None of the group styles is powerful enough to have it all.

Therefore → the feature request → make the “new style groups” more powerful → allow for an empty list of entities.

What would you get with an empty entity group? It would be useless as you can’t dynamically add or remove entities from new groups. It’s been stated by the core team that editing and adjusting configurations will never be added to new school groups. So all you’d get out of this FR is an empty group you can do nothing with.

I could see Frenck potentially adding the ability to adjust groups in spook, that’s about it.

As a sidebar, I use labels for this. No need for group management or to worry about empty groups. Just use a label to identify groups of entities. Spook can even add/remove labels (which will also likely not make it’s way to core).

Well, I can add and remove the entities via YAML at any point. Again, the use case I linked above.

You mean: to old style groups?

As soon as I’m able to add labels in YAML, I’d consider it.

No, you can already adjust configurations for old style groups with group.set. That service will not be added to new style groups, but it’s a moot point because of your previous points.

Not sure why that is a requirement, but maybe you’re missing my point. I’m saying to completely remove old-school groups and go with labels. I did that when labels were introduced and it’s a much easier process now.

Well, in this particular case, I don’t need to manage group members via services, nvm then.

Well, any useful change I do, I’d like to be able to track with git. Creating a group in YAML allows me that. I cannot add labels to entities in YAML, therefore I cannot DIFF/BLAME/COMMIT changes made with labels, therefore → labels are inferior to groups.

Cool, as soon as I can manage labels in yaml. Until that, keep old+new style groups (as they both have uses, even though none is perfect).

Yeah, it’s a mess xD

There’s a near zero chance creating labels and/or assigning labels in yaml will be added (from the conversations I’ve had).

Therefore, labels are not a replacement for groups.

Therefore, my FR stands :wink:

Please point to where I said the feature request was invalid. I really wish you’d stop assuming this all the time with every conversation. Asking questions is part of the discussion.

You kinda indicated that with:

But I think I’ve stated my reasons, you didn’t question them, so I guess we’re good :slight_smile:

I was identifying your use case which your FR did not spell out. The only use case I thought of, was for dynamic groups, which would make the FR require a second FR.