Change state of multiple entities that follow a naming convention

Configuration
,
1

I have multiple (+40) automations for managing my auto-off timers. I want to be able to switch them on, but only when they are off at a specific moment.
Also I sometimes add similar automations. I don’t want to maintain this list.

examples:
automation.badkamer_douche_auto_off_timer_beeindigd
automation.badkamer_wc_auto_off_timer_beeindigd
automation.mbr_dressing_auto_off_timer_beeindigd
They all end in “auto_off_timer_beeindigd”

So I’m looking for an automation like this:
trigger: I can fill that in (probably at 3 AM or something like that)
condition: automation.*auto_off_timer_beeindigd = off
action: turn on automation.*auto_off_timer_beeindigd
repeat above 2 steps for any automation that ends in “auto_off_timer_beeindigd”

All help appreciated.

2

I know how to build an automation like that but there should be no need to programmatically enable/disable automations. An automation should be autonomous; it should be able to determine when it should/shouldn’t execute its actions.

Valid reasons for manually disabling an automation are if it’s misbehaving and you want to take it ‘offline’ temporarily until you have time to debug it. Or if you are replacing an older version of an automation with a new one but still want to keep the old one around as a ‘backup’ in case the new one has problems.

What’s the reason for disabling these 40+ automations? Is there no way to design them so they don’t need to be disabled (and operate only when necessary)?

3

Sorry, I don’t agree.
Disabling (multiple) automations is much easier than adding a boolean that I have to add to each automation, especially when I want to be able to control each automation individually (having to create a bool for each automation).

In this situation these automation are handling a timer (switch lights off automatically). Each light has it’s own timer. 99% of the time all these automations have to be active. In rare cases I don’t want to turn off the lights off in a specific room. I turn off the automation. Done !

Now, I just don’t have to forget to turn on these automations. So I want to turn on just the automations that were switched off (at 3 AM).
I can create 1 automation that turns on all of them, even if they are turned on by just listing them. But what if I create a new automation? Then I have to add the automation to the existing list (and don’t forget to do that).

Also, when I know how to do this, I can do that also for other entities that also follow a naming convention.

4

I mean I agree with 123 about disabling automations being a bad idea. That being said I am a fan of operating on naming conventions rather then listing entity IDs. I even made this whole thing just to be able to have wildcards in entity_id in triggers (sort of).

Your use case is much easier then that though. To have a service call that turns on all automations you can just do this:

service: automation.turn_on
data:
  entity_id: "{{ states.automation | map(attribute='entity_id') | list }}"

Or (since you’re hoping to carry this to other entities) here’s an example of turning on all switches in the kitchen via naming convention:

service: switch.turn_on
data:
  entity_id: >-
    {{ states.switch | map(attribute='entity_id')
      | select('search', '[.]kitchen_') | list }}

Although truth be told for this second one it would be better to not use a naming convention and simply look for switches in the Kitchen area:

service: switch.turn_on
data:
  entity_id: >-
    {{ states.switch | map(attribute='entity_id')
      | select('in', area_entities('Kitchen')) | list }}

This is pretty straightforward for conditions and service calls, you just use templates instead of listing entities. It’s only in triggers this is difficult because the entity_id field in triggers does not accept templates.

1 Like
5

Coming from another angle: It sounds like these automations might be pretty much the same given that they need to be controlled in the same way. How about blueprints? I mean, you already have several automations, so there will be less duplication that now, plus you can then easily add 123’s idea to control them all via a helper.

6

So I need something like this (?)

service: switch.turn_on
data:
  entity_id: >-
    {{ states.automation | map(attribute='entity_id')
      | select('search', 'auto_off_timer_beeindigd') | list }}

This turns on ANY automation in the list. How can I limit this to only those that are in the ‘off’ state ?

7

It’s the same principle as for selecting any other entity by its state value, use selectattr('state', 'eq', 'off')

Example

service: switch.turn_on
target:
  entity_id: >-
    {{ states.automation | selectattr('state', 'eq', 'off')
      | selectattr('object_id', 'search', 'auto_off_timer_beeindigd')
      | map(attribute='entity_id') | list }}
8

Learning a lot here.
Especially because this solution is tailor made, so this is much easier to understand what this exactly does.

About blueprints: I started creating these automations about 2.5y ago, before blueprints existed.
I haven’t taken the time to learn how this exactly works. A thing for the future…

This leaves me with one question. Why exactly is it so ‘bad’ to disable automations?

9

It’s not exactly ‘bad’. It’s just that you lose some management flexibility.

It eliminates your ability to deliberately disable/enable an automation ‘on the fly’. You’ve lost the ability to take an automation ‘out of service’ or set it aside as a ‘backup’ in favor of a replacement. In addition, the automation’s code no longer tells the entire story of how it operates because the automation is no longer self-contained. Some other automation might be disabling and re-enabling it (according to other criteria) thereby making its behavior less self-evident.

If you don’t mind losing those features, then it’s not ‘bad’ for you.

2 Likes
10

Thank you all for your input.

Much appreciated !