Remove the quotes around alarm_trigger in your template. If you out it in quotes it reads it as a string, but it’s a variable so you need to use it without quotes.
4 Likes
It does not work with templates in triggers since variables are expanded only after the trigger has happened AFAIK.
I therefore made a fake trigger in one of my Blueprints and then put ‘wait for trigger’ as first action. Alternatively you could try putting it in a condition and triggering every minute or so. But yeah a proper fix would be good.
That’s not true. If you declare the variable before the trigger, it will be available to the trigger.
Then please tell me how it is supposed to work. Take this dummy blueprint for example which just turns a light off when it is turned on.
blueprint:
name: Test
domain: automation
input:
light_entity:
name: Light entity
selector:
entity:
domain: light
variables:
light_entity: !input "light_entity"
trigger:
platform: template
value_template: "{{ states(light_entity) == 'on' }}"
condition: []
action:
- service: light.turn_off
entity_id: !input "light_entity"
mode: single
max_exceeded: silent
Result is:
homeassistant.exceptions.TemplateError: UndefinedError: ‘light_entity’ is undefined
in the logs for the trigger template.
You are right, I remwmber now that I had the same issues before blueprints even got introduced. I’m sorry for the misinformation.
See this existing feature request that I even voted for myself xD
1 Like
Yes, it’s unfortunate that the convention is not currently supported. Not only would it allow for more flexible Template Triggers in automations, it would be useful in blueprints as well.
BTW, this Feature Request asks for two separate things and the first one can’t be fulfilled. An !input is a YAML directive to replace a placeholder for a key’s value. In other words, this:
key_name: !input placeholder_for_the_key_value
That’s not possible when the YAML directive appears somewhere within a Jinja2 template (basically it’s a syntax error; a misunderstanding of what is handled by the YAML processor and what is handled by the Jinja2 interpreter).
The second half of the Feature Request is ambiguous. Currently, variables are allowed in templates except not in Template Triggers. That’s what the linked Feature Request proposed over two months ago:
2 Likes
Hello together,
I have a similar, but more complicated problem:
blueprint:
name: Climate
description: Test
domain: automation
input:
room:
name: Roomname
description: Roomname
selector:
text:
variables:
room: !input 'room'
trigger:
- platform: state
entity_id: !input trigger
to: 'on'
action:
- service: input_boolean.turn_off
target:
entity_id: !input trigger
- service: notify.all_devices
data:
message: >-
Climate in '{{ rooom }}' off
title: >-
Climate '{{ rooom }}'
mode: restart
I thought, that the notification will be “Climate Work”, if the “Work” is set as “room” in the inputs, but it is only “Climate”. I also tested the following, but it didn’t work:
Climate room
Climate {{ rooom }}
'Climate {{ rooom }}'
What is wrong?
There’s a spelling error.
You defined a variable named room but you are referencing it using the name rooom.
variables:
room: !input 'room'
message: >-
Climate in '{{ rooom }}' off
1 Like
Thanks a lot! Things could be so easy sometimes, but I really didn’t recognized it.
I think this just saved me hours of debugging. It seems like this is still the case? I’m trying to use a sun sunrise/sunset event where the offset is a computed value based on one of the inputs. This seems to make it impossible, or at least VERY cumbersome, or plain inefficient.
As I understand this is impossible…?
trigger:
- platform: sun
event: sunrise
offset: "{{ computed_variable_here }}" # this is based on input that has been defined in "variables" section of the blueprint
@Sbyx @Burningstone - what are my options here?
There’s no option, you can’t use templates in triggers. See also the feature request I posted above.
1 Like
Try this…
input:
seq_status:
name: Control Sequence Status Placeholder
description: >-
input_number - The internal use lock sequence number (set range to 0 to 100)
You will need one of these for every copy of this automation,
IE one for every lock code.
selector:
entity:
domain: input_number
variables:
seq_status_ent: !input 'seq_status'
seq_status_last: '{{ expand(seq_status_ent)[0].last_changed | as_timestamp }}'
seq_status_val: '{{ expand(seq_status_ent)[0].state }}'
I have an automation that uses templating
trigger:
platform: template
value_template: "{{ state_attr('vacuum.my_crapper', 'status_code') not in ['RDY', 'CCC', 'CCP', 'DFS', 'DF1', 'DF2'] }}"
for:
minutes: "10"
Am I correct in my understanding there is no way to create a blueprint from this yet?
AFAIK it’s the variables that are the problem not templating in general.
I also have automations that use value_template and they work and blueprints are just automations with an extra wrapper, basically. The problem, as stated above, is that variables aren’t populated until after the trigger fires.
I’m getting the same error mentioned earlier in this thread (Template variable error: '_____' is undefined when rendering) as of today so it likely hadn’t changed.
Edit: Actually this may now be possible thanks to trigger_variables. I found a working example of this that I have in an automation as well as this post. I’ve yet to get my automation triggering properly (that might be another issue) but the errors are gone!
2 Likes
Could someone tell me if this allowed? And will it work?
input:
after_time:
name: 'After: '
description: runs only after this time.
default: '23:59:59'
selector:
time:
before_time:
name: 'Before: '
description: runs only before this time.
default: '05:00:00'
selector:
time:
...............
condition:
condition: time
after: !input 'after_time'
before: !input 'before_time'
Just wanted to say your edit in your comment helped me solve my frustration. Never knew Trigger Variables existed! Many thanks.
Hi I’m trying to create a blueprint that has a input named remote_id of type text , how can I use the input in a condition?
{{ trigger.event.data.id_string.startswith( states(remote_id) + ':') }} does not seem to match the event data correctly?
blueprint:
input:
remote_id:
name: Remote id
selector:
text:
variables:
remote_id: !input remote_id
trigger:
- platform: event
event_type: rfxtrx_event
condition:
- condition: template
value_template: "{{ trigger.event.data.id_string.startswith( states(remote_id) + ':') }}"
event:
remote_id: 1599e6a
all_off_action:
...
1_on_action:
...
1_off_action:
...
2_on_action: []
2_off_action: []
3_on_action: []
3_off_action: []
this:
entity_id: automation.sovrum_fjarrkontroll
state: 'on'
attributes:
last_triggered: null
mode: single
current: 0
id: '1679664439381'
friendly_name: Sovrum fjärrkontroll
last_changed: '2023-03-24T13:48:33.395274+00:00'
last_updated: '2023-03-24T13:48:33.395274+00:00'
context:
id: 01GW9Y1M7KQYMTGT9JY3YBFF27
parent_id: null
user_id: null
trigger:
id: '0'
idx: '0'
alias: null
platform: event
event:
event_type: rfxtrx_event
data:
packet_type: 17
sub_type: 0
type_string: AC
id_string: 1599e6a:1
data: 0b1100ca01599e6a01010f70
values:
Command: 'On'
Rssi numeric: 7
device_id: 2c28bbd198de769adf9f7bb42707d2d9
origin: LOCAL
time_fired: '2023-03-24T13:48:39.200384+00:00'
context:
id: 01GW9Y1SX0BT964F95XTANHVGJ
parent_id: null
user_id: null
description: event 'rfxtrx_event'
What am I doing wrong here?
The remote_id is specified as 1599e6a and trigger.event.data.id_string is 1599e6a:1, so why doesn’t {{ trigger.event.data.id_string.startswith( states(remote_id) + ':') }} match the event?
The full source of the blueprint can be found here
I didn’t understand what states() did, but removing it and just using remote_id solved my issue
Hello,
You are very close. The only change you need is to use a different name for the input variable in the blueprint section. One may apply an input_ prefix to the variable name as follows.
blueprint:
input:
input_alarm_trigger:
variables:
alarm_trigger: !input input_alarm_trigger
trigger:
- platform: template
value_template: "{{ states('alarm_trigger') == true }}"
Placing the variables under the variables: OR the trigger_variables: stanza worked for me.
I feel like this should be better explained in Blueprint Entity Selector Tutorial.
Thanks to @bverkron for finding and @joshcrosby for pointing it out after I skimmed passed it.
kristofferbas I am rewriting it here, so people coming off the Google train don’t have to read so much, in-case you want to mark it as answer.
P.S.
I think trankillity is correct in stating that the rendering engine should be able to handle this. If technically feasible, a input() Jinja call, in addition to states() would make this work-around not needed.
This is a very old post, but I think I need to set it straight.
The name as long as it is valid doesn’t matter. What you show @vittorio88 will not work.
If you want to put a variable into a trigger, it has to be built using the trigger_variables: key.
This is because that key is rendered when you save the automation (or blueprint) and will exist for the trigger to use.
Variables:, no matter where they are in the automation (or blueprint) are rendered after the trigger and do not exist before, so when put in the trigger are probably ‘unavailable’ or ;null’ or something.
This is also why template_triggers: are limited in what they can do as they only have access to some of the jinga and only information available when the automation (or blueprint) is saved. They know what the !inputs are, so that works fine. Not a lot beyond that.
The documentation is covered here:
Automation Trigger - Home Assistant.
(PS, pinging people years after they posted something is not a great idea. )
1 Like