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

[DvdNwk]

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.

[petro]

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).

[DvdNwk]

@petro

What would you get with an empty entity group?

Implement explicitly named "none" entity for portability?

Well, I’ve just came up with a situation that made me wanna try it. Kinda disappointed. Reason I’ve just moved into a new apartment. There’s a lot to be removed/changed, but there are parts of the setup I used to have that I still wanna keep. At this particular moment, I do not have motion sensors in my kitchen (yet). I’ve got a group kitchen_motion_sensors that I still wanna keep (it’s used in automations and presented in Lovelace widgets). But… I can not remove all the entities it contains.…

@petro

It would be useless as you can’t dynamically add or remove entities from new groups.

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

@petro

It’s been stated by the core team that editing and adjusting configurations will never be added to new school groups.

You mean: to old style groups?

@petro

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.

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

[petro]

@DvdNwk

You mean: to old style groups?

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.

@DvdNwk

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

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.

[DvdNwk]

@petro

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.

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

@petro

Not sure why that is a requirement [being able to “group” entities via labels IN YAML]

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.

@petro

I’m saying to completely remove old-school groups and go with labels.

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

[petro]

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

[DvdNwk]

Therefore, labels are not a replacement for groups.

Therefore, my FR stands

[petro]

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.

[DvdNwk]

@petro

Please point to where I said the feature request was invalid

You kinda indicated that with:

@petro

What would you get with an empty entity group? It would be useless

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

[petro]

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.