No but there is a route to do what @kongo09 wants, nothing is broken. But I guess moaners will moan.
Not really. The only way to do what @kongo09 is asking for is to do it using an old-style group and as it says:
We donât recommend using these old-style groups anymore. They are still supported, but we recommend using the groups as described above.
And besides, this topic is âwhy the heck arenât groups UI-configurable?â Even at the time of its posting you could make groups in YAML. Itâs 156 votes were specifically about people that wanted to be able to do it without YAML.
That being said I think this is solved. The reason is because there were two types of groups:
- Domain-specific groups (light groups, cover groups, binary sensor groups, etc.)
- Generic groups that can contain any entity, attempt to coerce the state of any entity to a true/false value, and attempt to support any service for any entity they could possibly contain
Group type #2 isnât really in a sustainable place. It was more created when groups were needed to organize your UI and thatâs not how the UI works anymore. So Frenck made every instance of #1 UI-configurable and even added a few to lessen the need for group type #2 and then marked those as not recommended.
To me thatâs a pretty solid solve. What should happen now is feature requests should be opened for the types of entities you canât make groups for (ex. person and input_boolean) so people can vote on those. In fact the two mentioned already have FRs: input boolean and person.
Thanks for pointing to the FR
Iâm not moaning but stating that from a user perspective this is not done. No user understands the difference between domain specific groups and generic groups. Letâs streamline this.