Why the heck don't we have templates/glob for groups?

Archive Month of "What the heck?!" (2020)
1

What if there were groups that you could template?

It would convert a comma spaced output (or list) to a list.

For example, a group that shows all people that are at home

group:
  name: persons_at_home
  template_group: >
    {{ states.person | selectattr('state', 'eq', 'home') | join(', ', attribute="entity_id") }}

or a group that contains all entities that have battery_level in their name

group:
  name: battery_sensors
  template_group: >
    {{ states.sensor | selectattr('entity_id', 'contains', 'battery_level') | join(', ', attribute="entity_id") }}

Or even using glob:

group:
  name: battery_sensors
  entity_ids_glob: "sensor.*battery_level*

Then one could easily loop over these groups in automations/scripts.

2

As long as the implementation limits included entities to ones that were created before the start event (of when you reload groups), this could work. Otherwise you would have to watch all states and add new entities to the group when they appear which could get a bit expensive if you have a lot of groups that need this.

I’m not sure if that limitation would still make this useful

3

I think that’s very fair, and the feature would still be very useful IMO.

4

I voted for this but you should know that there’s an existing solution presented here that uses an automation to create a group on startup.

In addition to triggering on startup, the automation could be enhanced with an Event Trigger to also detect call_service event for group.reload.

Obviously, your proposal is neater.

5
3 Likes
6

That’s great @bdraco!

I see you stopped working on the feature though, is that because you think it might not be merged? I think what @frenck talked about the group.all_* are quite different TBH (maybe similar internally but very different for the user).

7

I’m waiting for more information on the history related to the removal of all the automatic groups and the reasoning behind it. Also, if we think its going to be necessary to implement functionality to automatically update the groups when entities are added and removed, I will switch gears and working on adding a performant way to track entities being removed (we already have a performant way to track new ones being added).

In short, I’m waiting for a review.

8

I can understand why group.all_whatever was eliminated. Frankly, I never used the “all” groups so they represented some needless overhead for me; I got something I didn’t use and couldn’t get rid of it.

However, they were useful for other people so, very quickly, a workaround was devised: an automation triggered at startup that creates the desired group from scratch (be it all lights, or all temperature sensors, or whatever). A template is employed to select the desired entities and add them to a group. Easy-peasy workaround for anyone willing to take the time to create the automations.

What’s proposed here is just a simplified version of what the workaround does. The people reviewing this proposal shouldn’t be comparing it to the deprecated “all” groups (which were created even if you didn’t use them). This proposal still requires users to define the groups they want, just more easily than by creating an automation.

In a nutshell, this proposal is a simplification of an existing workaround and has nothing to do with deprecated “all” groups.

1 Like
9

I have a case where workaround cannot be used.

I want to create a group of media players for tts messages but I want that are included only those in idle (exclude the ones playing music).

The original request would achieve this. Any update?