PSA: Turn on/off all lights in Home Assistant 0.104+ (group.all_* changes)

No you don’t. I posted a solution here:

Change domain to ‘lock’ and state to ‘locked’.

- condition: template
  value_template: >
    {% set domain = 'lock' %}
    {% set state = 'locked' %}
    {{ states[domain] | count == states[domain] | selectattr('state','eq', state) | list | count }}
2 Likes

Again, no you don’t. Node red calls a service. Instead of using entity_id: ‘group.all_lights’, use entity_id: ‘all’.

I get that, but previously I iterated over the entities in the group. Using all only works when trying to turn off the lights, not for getting the list of entities.

Luckily I’ve put all that code in a subflow, so it’s a change on 1 place, but still. This change kinda sucks.

dude, i posted that solution as well…

Use this as a list of entity_id’s to return to entity_id’s

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

Use this to find all items in a domain

{{ states.switch | map(attribute='entity_id') | list }}

EDIT: In the words of southpark “Rabble rabble rabble rabble”

What about some tiny python_script to get your group.all_* back?

automation:
  - alias: HA Start automation
    trigger:
      platform: homeassistant
      event: start
    action:
      - service: python_script.create_all_group
        data:
          domain: light
          group: all_lights

python_scripts/create_all_group.py

domain = data.get('domain')
group = data.get('group')

service_data = {"object_id": group, "entities": hass.states.entity_ids(domain)}
hass.services.call("group", "set", service_data, False)

I have no clue if this is safe, but it works for me. :sunglasses: It is!

EDIT: optimized create_all_group.py

5 Likes

Nice list @petro, thanks for compiling.

adding my bit: just discovered we can also expand the domain, as an alternative:

count

{% set lights = expand(states.light)
|selectattr('state','eq','off')|list|count %}
{{lights}}

list:

{% set lights = expand(states.light)
|selectattr('state','eq','off')|map(attribute='name')|list %}
{{lights}}
1 Like

This works for me:

List:

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

What’s the purpose of expanding the domain?

The result of the following two templates is the same so the expansion seems like an unnecessary step.

yes…
noticed that myself… first thought the one was listing as list, and the expand as comma separated, but they are not. they are identical. How odd.

(aware of |list versus |join(',') )

sorry for the confusion.

The expand function is useful if you want to combine domains (or groups or entities). For example, this counts how many light and switch entities are off.

4 Likes

ha, that’s very nice indeed, never saw that before in 1 template. in the cookbook!
thanks Taras.

same goes for the '=='

I’ve always used ‘eq’:

{{expand(states.light, states.switch)
| selectattr('state','eq','on')|map(attribute='name')
  |join(',\n')}}

learned a lot today.

3 Likes

ah, that is nice. Thanks @123, i’ll add it to the top post.

Nice! Out of curiously. The big batteries group topic uses an automation to periodically (or at startup) populate a group. Wouldn’t that be an options for those who REALLY want those groups back?

1 Like

The removal of group.all_devices is a bit of a disaster for me.

I use this very regularly as a trigger and condition for very many automations as it very reliably lets me tell if there is anyone home or not, or if someone has literally just gotten home (using nmap tracking of devices on Wifi)

There literally couldn’t be anything simpler than a condition state check of home or not_home, and a trigger resulting in a state change from home to not_home, but it looks like I can’t do this anymore.

I’m going to see if I can build a sensor that creates a dynamic group to replicate the old behaviour. Manually creating a group with a list of devices won’t work in case people change devices (and end up with a new entity name). If I add additional devices in future I would have to remember to add them to the group. The group needs to update the second a new device appears home.

Is there any point in campaigning to keep just group.all_devices for this use case??

1 Like

Scroll up and read my last post
Or here is another solution.

3 Likes

You can create manually same group with your device_tracker too
That I did

Thank you for your reply, the 2nd link looks ideal as it is a native script to create the dynamic group, so it can be called at startup and at any time should another device be added to home assistant. I’ll do some testing with this.

This makes me wonder if my entire approach to home / not home is incorrect, perhaps I should be using zones?

Is there an easy way to make a script that just creates the group.all_* automatically again?
I don’t want to screw around with a lot of automations of mine that use device trackers, which use to use the group.all_devices status. I manually created a group called group.all_devices and added the entities manually.
Does anyone know a script or automation that may automatically write a group file?

3 posts up!

1 Like

@VDRainer. Ooops. Missed that one scrolling through. Thanks