I would like to be able to use !inputs (or variables) with templates. I have a blueprint with a boolean that I want to use in a trigger (if on) at a specific time (mobile phone alarm).
You can use !inputs in templates, assign them to a variable first and then use the variable in the template, something like this:
variables:
my_var: !input light
condition:
- {{ states(my_var) == 'on' }}
Thatâs not a solution, itâs a workaround. The template rendering engine should be robust enough to replace !input calls with their actual values.
Did I say that this is a solution? I just showed a way how it can be done currently.
Iâm trying the following, but canât get it to work.
variables:
alarm_trigger: !input alarm_trigger
trigger:
- platform: template
value_template: "{{ states('alarm_trigger') == true }}"
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.
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
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:
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
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.
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!
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'