How to survive without the "ALL groups"

BrianHanifin · January 23, 2020, 12:57am

Update: Please also see @petro’s PSA: Turn on/off all lights in Home Assistant 0.104+ (group.all_* changes) for examples.

I have noticed there is some concern about how to get along without the formerly automatically generated groups like group.all_lights. I promise you there is a way to make your code work without them. Ask here and we can help you.

First off, the following is the correct way to turn off every light now.

service: light.turn_off
entity_id: all  # replace group.all_lights with `all`

Here are some example templates to get lists of entity_ids to get you thinking.

List of all lights

{{ states.light | map(attribute='entity_id') | join(',') }}

List of lights that are turned on

{{ states.light | selectattr('state','eq','on') | map(attribute='entity_id') | join(',') }}

With some slights changes you can make these work for covers.

List of all covers

{{ states.cover | map(attribute='entity_id') | join(',') }}

List of covers that are open

{{ states.light | selectattr('state','eq','open') | map(attribute='entity_id') | join(',') }}

If you really feel like you need the all groups back you have some options. For example you can create a script that rebuilds a group. The script below literally recreates group.all_lights. Call this script just before you need the group to update it.

script:
  # Recreate group.all_lights
  update_all_light_group:
    sequence:
      - service: group.set
        data_template:
          object_id: "all_lights"
          entities: "{{ states.light | map(attribute='entity_id') | join(',') }}"

  # Recreate group.all_switches
  update_all_switches_group:
    sequence:
      - service: group.set
        data_template:
          object_id: "all_switches"
          entities: "{{ states.switch | map(attribute='entity_id') | join(',') }}"

While these group won’t be updated every time the status of a state changes… well, your server doesn’t have to update the group every time a change happens. Every little bit helps on a Raspberry Pi… ammiright?

There also two AppDaemon apps available on HACS that intend to recreate those groups for you.

If you would like help converting a script post an example of your code in this topic.

BrianHanifin · January 23, 2020, 1:09am

Here is an example from Drop the auto generated groups. · Issue #177 · home-assistant/architecture · GitHub

I also have a simple “sleep” scene that just says all lights should be off.

group.all_lights: off

Don’t worry, the replacement script required is quite simple.

script:
  turn_all_lights_off:
    sequence:
      - service: light.turn_off
        entity_id: all

Adorem · January 24, 2020, 3:49pm

Thanks. There is also an excellent description from @petro here:

hfuller · January 25, 2020, 3:40am

I love these examples! But I’m wondering if anyone has any ideas for this case.

I have a script that runs when everyone has left home:

script:
        post_departure:
                alias: 'Post-departure state checks'
                sequence:
                        - condition: state
                          entity_id: group.off_when_unoccupied
                          state: 'on'
                        - service: notify.mobile_app_leaf
                          data:
                                  title: "Device Left On"
                                  message: "No one is home, but some devices are still on."
#snip#

And here is the group that the script checks:

group:
        off_when_unoccupied:
                name: 'Stuff that should be off when the house is empty'
                entities:
                        - group.space_heaters
                        - group.all_lights

Is there a way to replicate this functionality cleanly? Notably, I’d like to have one group that turns off all the relevant devices, because later I let another script turn off the same off_when_unoccupied group when I click the notification on my phone, thereby resolving the problem.

Is there no alternative to writing a script to just recreate the all_lights group every once in a while? I’ve heard rumblings of a “template group” which would be perfect for this, but nothing that I can use today.

BrianHanifin · January 25, 2020, 5:04am

Hunter, what you are looking for is exactly what my above example update_all_light_group script is intended to do.

If you add that script, then call it just before your condition the group will be updated. It may or may not be necessary, but I usually add a second or two delay right after calling a group update script like that just to make sure it updates before I need to access it.

Here is what I would do in this situation.

script:
  # Recreate group.all_lights
  update_all_light_group:
    sequence:
      - service: group.set
        data_template:
          object_id: "all_lights"
          entities: "{{ states.light | map(attribute='entity_id') | join(',') }}"

  post_departure:
    alias: 'Post-departure state checks'
    sequence:
      - service: script.update_all_lights_group
      - delay:
          seconds: 2
      - condition: state
        entity_id: group.off_when_unoccupied
        state: 'on'
      - service: notify.mobile_app_leaf
        data:
          title: "Device Left On"
          message: "No one is home, but some devices are still on."
#snip#

P.S. I have a ton of respect for the developers, they aren’t out to get rich. Heck only a few people collect any salary at all. What they do, they do out of love. I think this was one of many difficult decisions they have made in the past year. I have been paying attention, and the changes while tough at first, are really moving us closer to a less kludgy system that will eventually have a consistency you expect from a high quality veteran product. I’m glad you are sticking it out and asking for help. I love this community!

BrianHanifin · January 25, 2020, 8:49pm

Advanced concepts

Omitting browser_mod’s virtual lights

If you use @thomasloven’s excellent browser_mod component, it will by default add a virtual light for each unique browser you use. If you want to be able to use that feature, but don’t want those “lights” added to your all_lights list here a tip. We can use the rejectattr() template filter to omit lights created by browser_mod like so:

{{ states.light | rejectattr('attributes.type','eq','browser_mod') | map(attribute='entity_id') | join(',') }}

Creating an “Actionable Lights” group

I have a bunch of Hue bulbs which are grouped together in various lamps. For example my dining room chandelier has 9 color hue bulbs in it. They are named light.dining1, light.dining2, and so on. But those are added to a light group named light.dining_room.

So how do you create a list of all lights, but omit specific lights from that list? You create a group named group.actionable_lights, also using a rejectattr() template filter. This time we are creating a list of values to reject.

sequence:
  - service: group.set
    data_template:
      object_id: "actionable_lights"
      entities: >
        {%- set ignore_list = [
          'light.dining1','light.dining2','light.dining3','light.dining4','light.dining5','light.dining6','light.dining7','light.dining8','light.dining9',
          'light.family_room_floor_lamp1','light.family_room_floor_lamp2','light.family_room_floor_lamp3',
          'light.kitchen_cabinet'
        ] -%}
        {{ states.light | rejectattr('entity_id','in',ignore_list) | map(attribute='entity_id') | join(',') }}

Bonus: Combine multiple `rejectattr()` filters

I use this to build my actionable_lights group, without the browser_mod “lights” as well.

{{ states.light | rejectattr('attributes.type','eq','browser_mod') | rejectattr('entity_id','in',ignore_list) | map(attribute='entity_id') | join(',') }}

strawwmann · February 17, 2020, 5:41pm

Deleted (duplicated an option already listed above)