Use template for entity_id (in automation trigger)

[bttrsh]

Hi,

I might have taken a wrong turn somewhere, but I got a bit confused messing with an automation.

I have an automation with the following trigger:

platform: state
entity_id: 
  - sensor.my_sensor_1
  - sensor.my_sensor_2
  - sensor.my_sensor_3
attribute: some_sensor_attribute
from: false
to: true

The entity_id’s should be dynamic and based on some filter criteria, I put the following together:

{{ states | selectattr('entity_id', 'match', '^(sensor).my_sensor_*') | list  }}

This perfectly evaluates into a list of respective entity_id’s, just how I wanted it to.
However, it doesn’t appear as if I can just go ahead and use that to base the entity_id value in my automation trigger on.

So this is not working:

platform: state
entity_id: "{{ states | selectattr('entity_id', 'match', '^(sensor).my_sensor_*') | list  }}"
attribute: some_sensor_attribute
from: false
to: true

I believe I also attempted converting it to a comma-separated string to no avail.

Any suggestions?
As I said, I’m a bit lost, apologies in advance, if this doesn’t make any sense at all.

Cheers

[123 (Taras)]

@bttrsh

it doesn’t appear as if I can just go ahead and use that to base the entity_id value in my automation trigger on

Correct, because a State Trigger’s entity_id option doesn’t support templates.

If your next question is “What’s the workaround?” the short answer is “None”. There’s no trigger that monitors a dynamic list of entities for a specific state-change in one of their attributes.

@bttrsh

The entity_id’s should be dynamic and based on some filter criteria

Why?

Does the list of sensors grow and shrink on a daily basis?

[bttrsh]

@123

Does the list of sensors grow and shrink on a daily basis?

Yup, potentially it does. These sensors are dynamically created based on some external data sources (web API).

Would‘ve been nice to keep things dynamic, but if there‘s no way to do it, thanks for letting me know.

[123 (Taras)]

@bttrsh

dynamically created based on some external data sources (web API).

Which integration is this?

[kajarit]

Yup, for instance the 17track integration generates dynamic entites for ech package tracked, so the question is relevant.
Maybe the workaround is beyond a simple template within an automation, but there should be one… maybe some automation that generates automations…?

[DvdNwk]

@123

If your next question is “What’s the workaround?” the short answer is “None”. There’s no trigger that monitors a dynamic list of entities for a specific state-change in one of their attributes.

Yep, there is no trigger like that, but there is a workaround… Template Trigger:

Automation Trigger

You have to manually create your trigger (cannot click the rules in a nice GUI), but it works

@123

Why?

Does the list of sensors grow and shrink on a daily basis?

Other people said that for them it may.

But I will say: even if it doesn’t on a daily basis, I’d still like to automate it. That’s what HA is for: home automation. I’d like some stuff to be dynamic, so I don’t have to manually correct everything when something changes. In the long term, keeping manual lists is slow and error-prone. Not that these kind of errors are life and death (and Spook helps), but still

[123 (Taras)]

I’m familiar with a Template Trigger.

Please post an example of one that meets the stated requirements.

[DvdNwk]

@123

Please post an example of one that meets the stated requirements.

I’ve created 3 Toggles via Helpers:

• input_boolean.test_toggle_1
• input_boolean.test_toggle_2
• input_boolean.test_toggle_3

I’ve also created a Number Helper: input_number.test_toggles_being_on_count

The automation catches all the test toggles and triggers when they change state.

• If the count increases → we know one+ of the inputs changed its state to on
• If the count decreases → we know one+ of the inputs changed its state to off

There is a catch though… The template trigger is only evaluated once a minute – so the automation has “one minute lag”. If you change the state few times quickly, it will not notice it.

Templates that do not contain an entity will be rendered once per minute.
~ Automation Trigger - Home Assistant

alias: test_toggles
description: ""
trigger:
  - platform: template
    value_template: |-
      {{ 
        states 
        | selectattr(
          'entity_id', 
          'match', 
          '^(input_boolean).test_toggle_*'
        ) 
        | selectattr('state', 'eq', 'on')
        | list
        | count
        
        != 
        
        states('input_number.test_toggles_being_on_count')
        | int(0)
      }}
condition: []
action:
  - service: notify.persistent_notification
    metadata: {}
    data:
      message: |-
        test_toggles_being_on_count changed from {{
          states('input_number.test_toggles_being_on_count')
          | int(0) 
        }} to {{ 
          states
          | selectattr(
            'entity_id', 
            'match', 
            '^(input_boolean).test_toggle_*'
          ) 
          | selectattr('state', 'eq', 'on')
          | list
          | count
        }}
  - service: input_number.set_value
    metadata: {}
    data:
      value: |-
        {{ 
          states 
          | selectattr(
            'entity_id', 
            'match', 
            '^(input_boolean).test_toggle_*'
          ) 
          | selectattr('state', 'eq', 'on') 
          | list 
          | count 
          | float(0.0) 
        }}
    target:
      entity_id: input_number.test_toggles_being_on_count
mode: single

[DvdNwk]

Same setup as above, just a different trigger: with Time Pattern trigger, the check is done every second → so there is no one minute lag → the reaction is instant

alias: test_toggles
description: ""
trigger:
  - platform: time_pattern
    seconds: "*"
condition:
  - condition: template
    value_template: |-
      {{ 
        states 
        | selectattr(
          'entity_id', 
          'match', 
          '^(input_boolean).test_toggle_*'
        ) 
        | selectattr('state', 'eq', 'on')
        | list
        | count
        
        != 
        
        states('input_number.test_toggles_being_on_count')
        | int(0)
      }}
action:
  - service: notify.persistent_notification
    metadata: {}
    data:
      message: |-
        test_toggles_being_on_count changed from {{
          states('input_number.test_toggles_being_on_count')
          | int(0) 
        }}  to  {{ 
          states
          | selectattr(
            'entity_id', 
            'match', 
            '^(input_boolean).test_toggle_*'
          ) 
          | selectattr('state', 'eq', 'on')
          | list
          | count
        }}
  - service: input_number.set_value
    metadata: {}
    data:
      value: |-
        {{ 
          states 
          | selectattr(
            'entity_id', 
            'match', 
            '^(input_boolean).test_toggle_*'
          ) 
          | selectattr('state', 'eq', 'on') 
          | list 
          | count 
          | float(0.0) 
        }}
    target:
      entity_id: input_number.test_toggles_being_on_count
mode: single

[123 (Taras)]

I have to admit that when you suggested that a Template Trigger could be used as a “workaround”, I assumed you had a clever template in mind that could somehow detect specific state-changes. However, the first example doesn’t do that and relies on a helper to report when the current count (of a given state value) has changed from its previous value.

What it doesn’t do is detect specific state-changes, for example off → on as opposed to unavailable → on and merely filters state values for a specific state (on). Because it’s not actually detecting state-changes, it cannot provide a State object containing details about the state-change (whether that’s needed or not depends on the application).

@DvdNwk

The template trigger is only evaluated once a minute

It’s being throttled due to the template’s use of states. Refer to the following section of the Template integration’s documentation: Rate Limiting Updates

Don’t get me wrong, depending on the application, it can be a useful workaround; you have demonstrated a way to use a Template Trigger, with a helper, to trigger when the state of one of multiple entities (whose entity_id matches a specific pattern thereby making it dynamic) is a desired value.

As for the second example, it doesn’t use Home Assistant’s resources efficiently. By making Home Assistant evaluate the template every second, it saddles it with a continuous workload merely for the convenience of supporting a dynamic list of entities.

---

As a side-note, if the entity’s domain is known in advance then it can be used in the template to reduce its complexity. However, it’s still likely to be subjected to rate limiting (because it employs states).

{{ states.input_boolean 
  | selectattr('object_id', 'match', 'test_toggle_')
  | selectattr('state', 'eq', 'on') | list | count }}

[DvdNwk]

@123

when you suggested that a Template Trigger could be used as a “workaround”, I assumed you had a clever template in mind that could somehow detect specific state-changes

If we assume there are only 2 states of input_boolean (on and off) → then we can detect every specific change in this domain (on → off and off → on).

But you’re right, I forgot about unavailable → therefore this example can “only” detect off/unavailable → on and on → off/unavailable.

I have a “better” workaround coming: using groups instead of counting I already have it working for my “automated group of windows that are open for too long” (so that I can display its members in Lovelace AND use the addition/removal of members to trigger automations) → but I need to “generalize” it to make a nice example.

With groups you actually can detect any kind of change → it’s just a case of the amount of groups and automations you’re willing to create.

Anyway, the point being: there are workarounds. Might not be pretty, but it is possible ;-)\

Jokingly: I couldn’t resist not responding to someone being wrong on the internetz
With a bit of truth: I’ve had it figured out the automated groups thingy, so eventually I want to share the solution somewhere.

@123

As for the second example, it doesn’t use Home Assistant’s resources efficiently. By making Home Assistant evaluate the template every second, it saddles it with a continuous workload merely for the convenience of supporting a dynamic list of entities.

Yep, I’m aware of that, but personally I almost never care.

I’m always using the rule: “make it work, make it right, make it fast (enough)”. So performance has the lowest priority for me (unless it becomes a problem).

The checklist here: “it works”, it’s not “right” (I don’t like the copy-paste, need to figure out some ways to get rid of duplication, probably macros or sth), it does not have performance impact on my setup (therefore no need to optimize, unless optimizing would be just for fun or learning).

How do I know “there is no performance impact”? First, it actually checks every second (I don’t see any delays). Second:

Notice the big spike at 4 AM → that’s when Proxmox host is making backups. I wrote the post at around 3:30, so must have been testing the solution before that. You see “a little” higher CPU usage? I can’t be sure, but I guess this is all the (probably unnecessary) restarts I’ve done while testing. That’s ~3% – around the usual of my normal CPU usage. I bet I can make a 100 of such automations and there will still be no problem.

And I’m on a cheap 20$ terminal with 2 cores, 2 gb of RAM, with Proxmox host, HA VM, OMV VM, MQTT LXC and Z2M LXC. If I’m starting having performance problems, I’ll probably invest 20 more dollars for better gear and keep being lazy with optimizations

---

Anyway, all depends on the exact requirements of course

[123 (Taras)]

I was looking through some PRs in Home Assistant’s GitHub Core repository and noticed several code improvements designed to eke out just a little bit more performance.

I thought if only they knew how some users use resources wastefully to the extent of rendering those little nips and tucks completely worthless.

As for groups, I had devised a method of using them for the purpose of a quasi-dynamic list of entities and the ability to report which group member is responsible for the state-change. However, I recognize it’s a workaround; if it’s a kludge or a resource hog, it’s not something I recommend to others.

[DvdNwk]

@123

I thought if only they knew how some users use resources wastefully to the extent of rendering those little nips and tucks completely worthless.

I’m a web developer. Performance issue? Just add another layer of caching (and buy more ram for memcached)

---

I find trying to microoptimize mostly waste of time; just solve the core issues; pareto rule, 80/20, etc. Code quality is much more important to me (hence I’m dissatisfied with my copy-pasting automation parts). We’re back to “requirements”…

[123 (Taras)]

@DvdNwk

I find trying to microoptimize mostly waste of time

Respectfully, that’s evident from the two examples posted above. Nevertheless, I encourage you to continue being creative in your approach to solving problems. It can lead to novel techniques.

[TheFes]

#template sensor
template:
  - sensor:
      - unique_id: 46ca24eb-f0b4-4a0a-8997-26f906c87573
        name: Sensor Count
        state: >
          {{
            states.sensor
              | selectattr('object_id', 'match', 'my_sensor_')
              | selectattr('attributes.some_sensor_attribute', 'defined')
              | selectattr('attributes.some_sensor_attribute')
              | list
              | count
          }}
        attributes:
          entity_id: >
            {{
              states.sensor
                | selectattr('object_id', 'match', 'my_sensor_')
                | selectattr('attributes.some_sensor_attribute', 'defined')
                | selectattr('attributes.some_sensor_attribute')
                | list
            }}

# AUTOMATION
id: 6a055fcb-eed2-40b8-8302-a7cf703acdc6
alias: Some automation
trigger:
  - platform: state
    entity_id: sensor.sensor_count
    to: null
condition:
  - condition: template
    value_template: >
      {% set from = trigger.from_state.state %}
      {% set to = trigger.to_state.state %}
      {{ from | is_number and to | is_number and to | int > from | int }}
action:
  - variables:
      entity_added: >
        {{
          trigger.to_state.attributes.entity_id
            | reject('in', trigger.from_state.attributes.entity_id)
            | list
            | first
        }}

That’s how I would do it. The template sensor is throttled to once every second because it uses states.sensor but that’s similar as using the time pattern trigger.