Manually triggering the automation results in a notification containing the value of inputs. In other words, the variable is correctly defined, and contains a list, but it fails to be understood within the trigger.
In short - a variable need to be used inside a "for" section.
This will make possible to create a blueprint for automations like âToggle when some entity = OFF for XXXX minutesâ, where XXXX- an input variable.
Another use-case Iâd love to make a blueprint for is trigger a blueprint to happen x minutes before a calendarâs start_time. Iâd like to be able to do this, but currently canât because trigger_variables is a limited template.
This request has been up most of a year, and it needs a little boost. This is something you would think would be obviously needed, especially for blueprints, but is not there, so it is forgotten OR hard to do, donât knowâŚ
Voted. With the advent of blueprints this becomes essential in many scenarios What workarounds are everyone here using? Iâd hate to âpollâ with a fake triggerâŚ
This post was extremely helpful to me, thanks. You may know that you can achieve the same by keeping the trigger_variables a list of entity id strings, rather than states objects, since as you said, those arenât supported.
I just made this and it worked a treat:
trigger_variables:
CURRENT_SENSORS:
- sensor.sonoff_10014911cb_current
- sensor.sonoff_10012efb58_current
- sensor.sonoff_10012efb6e_current
trigger:
- platform: template
value_template: |
{% set data = namespace(currents=[]) %}
{% for current_sensor in CURRENT_SENSORS %}
{% set data.currents = data.currents + [states(current_sensor)|float] %}
{% endfor %}
{{ data.currents|select('greaterthan', 1)|first|default }}
id: any high
and for when all currents are low, an unfortunate copy pasting of the for loop and then:
{{ data.currents|select('lessthan', 1)|list == data.currents }}
id: all low
(list|length == data.currents|length is likely more performant but whatever, when the {{ }} becomes too long the HA yaml editor does nasty reformatting)
You may also know that one can also achieve the same without even employing trigger_variables.
All this to say that there are many paths to the same destination; the aim of this FR is to allow for more extensive templating in trigger_variables (even more than the âlimited templatesâ that were introduced after this FR was posted).
FWIW, if you want to eliminate the for-loop from your template, you can do this:
Oh good call. Iâm so used to avoiding map like the plague in Python (favoring comprehensions instead) that it didnât occur to me it would be good here in a Jinja template. Thanks.
That was version 1 before I found this topic.
trigger_variables:
CURRENT_SENSORS:
- sensor.sonoff_10014911cb_current
- sensor.sonoff_10012efb58_current
- sensor.sonoff_10012efb6e_current
trigger:
- platform: template
value_template: >-
{{ expand(CURRENT_SENSORS) | map(attribute='state') | map('float') |
select('>', 1) | first is defined }}
id: any high
- platform: template
value_template: >-
{{ expand(CURRENT_SENSORS) | map(attribute='state') | map('float') |
select('<', 1) | list | length == CURRENT_SENSORS | length }}
id: all low
Itâs so glorious. Thank you!
Now if only the yaml editor wouldnât move trigger_variables to the bottom each time itâs opened, which if re-saved causes a log warning about the variable being undefined, despite everything working perfectlyâŚ