Is there a way to auto-create a switch group for areas?

[dondo]

I’m new to Home Assistant; apologies if this is well-trodden, but having spent an hour or so researching I can’t see that this has been suggested before. My primary interaction with automation is through voice assistant, specifically Alexa.

I love the ability to create nested groups to control eg. lights in a chandelier, which are in a “space” (eg. living room, kitchen), which are within a collection of spaces (“great room”), which are on a floor. But Zones/Floors/Areas provide a flat hierarchy, so I have to mix in groups to create a hierarchy that models my natural language understanding of my home.

It is well documented that none of zones, floors, or areas can be exposed to Alexa. To work around this shortcoming, I have been creating a group for each area and floor, and then more groups to collect switches and other entities, and more still to collect areas into the natural hierarchy described above. (I use templates to convert lights to switches to work around the type system for groups.)

Is there another approach that makes this simpler? If not, is there a way to extend the HA user interface easily create switch groups for areas & floors? Or, more broadly, is there a best practice for this I haven’t discovered in my research?

[Didgeridrew]

@dondo

Is there a way to auto-create a switch group for areas?

Not really.

One alternative instead of Switch groups would be to use Labels, then have Template Switches that take the place of the Switch groups. That would at least remove the need for the intermediate switch entities for your light entities. You could also, through the use of the Spook custom integration, gain the ability to programmatically add or remove labels if you want, which isn’t supported by Switch groups.

[dondo]

I may be missing something, but I don’t see how any of that helps. I want to expose my areas to voice assistants, so they can behave like, you know, rooms, containing switches that operate as a group. Unless I’m missing something, Labels cannot be so exposed, so I don’t understand how this suggestion helps.

Since (a) areas cannot be exposed to voice assistants, the problem is that (b) in order to expose areas to the voice assistant I have to create some other entity which can be exposed. I can’t be the first person to trip on this. I don’t see how labels solves the problem. What’s the best practice?

[Didgeridrew]

@dondo

Since (a) areas cannot be exposed to voice assistants, the problem is that (b) to expose areas to the voice assistant I have to create some other entity which can be exposed.

That’s what the Template Switches (or Template Lights) are for… they can be exposed to Alexa. The Template integration can use the Labels to identify which switches or lights get turned on and off when the template entity is turned on or off by Alexa.

Examples of Template Switches

Labels can be used as targets. So, if you apply them to the light and switch entities you can use the generic turn on and turn off actions:

template:
  - switch:
      - name: Great Room lights
        optimistic: true
        turn_on:
          - service: homeassistant.turn_on
            target:
              label_id: great_room_subgroup
        turn_off:
          - action: homeassistant.turn_off
            target:
              label_id: great_room_subgroup

But, they also can be used as part of a more complex selection/rejection criteria that includes the Floor > Area hierarchy.

template:
  - switch:
      - name: Great Room lights
        optimistic: true
        turn_on:
          - service: homeassistant.turn_on
            target:
              entity_id: |
                {{ floor_entities('first floor')
                | reject('in', area_entities('first bathroom'))
                | select('match', 'light.|switch.')
                | select('in', label_entities('great room subgroup'))
                | reject('in', label_entities('plant related'))
                | list }}
        turn_off:
          - action: homeassistant.turn_off
            target:
              entity_id: |
                {{ floor_entities('first floor')
                | reject('in', area_entities('first bathroom')) 
                | select('match', 'light.|switch.')
                | select('in', label_entities('great room subgroup'))
                | reject('in', label_entities('plant related'))
                | list }}

@dondo

What’s the best practice?

I don’t think there is a best practice… there’s just what works for you. Opinions about how we want to group and organize devices and entities have been the source of some of the more contentious discussions on this forum over the years.

[boheme61]

How about Legacy Groups (Yaml) ? you can mix lights and switches, and turn all(on/off)
Group - Home Assistant .

On If 1 Is ON

[Didgeridrew]

I don’t think group entities can be exposed to Alexa, so OP would still have to used Template switches or lights to proxy those groupings.

[boheme61]

Ok, i know nothing about Alexa , but first i also thought of templates, doo to the “story” , and the fact that not many read all the way to the bottom of the Doc’s

( And it is not an “autocreated” solution either way )

[Didgeridrew]

@boheme61

Ok, i know nothing about Alexa

You’re better off that way… … they are a continuous annoyance.

[dondo]

Group entities can indeed be exposed to Alexa; that’s what I’m doing currently. Probably would have been more clear to include that in my original post.

Here’s a group:

And here are the group options:

It sounds as though this is the easiest way, so I’ll keep on keeping on. Thanks for the thoughts, all.

[Didgeridrew]

@dondo

Group entities can indeed be exposed to Alexa; that’s what I’m doing currently.

No, what you are using is a Switch Group which is different than the legacy style groups Boheme61 mentioned… which cannot be exposed to Alexa, hence my comment replying to him.

[dondo]

Yeah, but I’m using the non-deprecated groups, and per above they can be exposed to Alexa. My initial suggestion was to provide a widget in the UI to easily create such groups, which gracefully works around two limitations to the “area” implementation - specifically (a) that they don’t nest, and (b) that they can’t be exposed to voice assistants. I’m not overly interested in a solution that is less capable than the one I’ve devised on my own!

[arturpragacz]

Depends on the voice assistant… Home Assistant’s own Assist fully works with areas.

[Didgeridrew]

@dondo

My initial suggestion was to provide a widget in the UI to easily create such groups

The Template Switches I showed above can be created in the UI in the Helpers menu. I share the YAML because it is efficient and portable.

When using the Label-based approach there is no need for an additional widget, because the tools to add labels to multiple entities are already built-in in the Entities menu…

… or they can be changed individually in each entities’ settings (as shown in the screenshot for your Switch Group).

And, as previously mentioned, they can be added and removed programmatically using actions provided by the Spook integration.

[dtrott (David Trott)]

Just to put a different option on the table, you could just give up on Zones/Areas/Floors (and labels). I have adopted a naming convention of putting the room name first on all my devices, i.e.:

• Bedroom Side

I don’t usually bother saying “Bedroom Side Light” since the entity id will be: light.bedroom_side

It doesn’t really help with the need to build groups manually, but it does eliminate the duplicated effort since you don’t have to go through putting everything in the right area **.

I do have some scripts and automations that just look for all lights or switches with a prefix/suffix of “Bedroom” but that only really works if you want everything in the room.

** - The root cause of this is I wanted to move away from the UI / HA database for configuration and rely on configuration files, currently there is isn’t good support in config files for areas.