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.
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.
Why?
Does the list of sensors grow and shrink on a daily basis?
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…?
Yep, there is no trigger like that, but there is a workaround… Template Trigger:
You have to manually create your trigger (cannot click the rules in a nice GUI), but it works
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
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.
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
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).
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).
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.
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
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.
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”…
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.
# 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.
