Blueprint variable undefined in template on trigger

Configuration
1

I’m confused as to why this trigger in a blueprint doesn’t work

blueprint:
#....elided description 
  input:
    timeout_minutes:
      name: Motion timeout input
      description:
        An input_number to configure the time after no motion when lights will turn off.
        Create a helper for this or add an input_number to your configuration.yaml.
      selector:
        entity:
          domain: input_number
variables:
  timeout_minutes: !input "timeout_minutes"
trigger:
  # trigger when motion stops for the number of minutes specified by input_timeout
  - platform: state
    entity_id: !input motion_entity
    id: motion_off
    from: "on"
    to: "off"
    for:
      minutes: >-
        {{ states(timeout_minutes) | int }}
action: ....

This crashes when triggered with

Template variable error: 'timeout_minutes' is undefined when rendering '{{ states(timeout_minutes) | int }}'

The variable is clearly defined however. Is it not possible to use a blueprint variable in a template on a trigger? The docs aren’t clear about this or at least I couldn’t find any information. Thanks for any insight!

2

Remove the quotes in the variables declaration

variables:
  timeout_minutes: !input timeout_minutes
3

Unfortunately that doesn’t make a difference. The !input yaml extension works the same with or without quotes.

I think what’s going on here is that for whatever reason you aren’t allowed to use any variables in a template that’s part of a trigger. See here: Support variables in a Template Trigger

4

Deleting my post because I forgot how things work :slight_smile:

5

If just use a number selector instead of forcing the use of an input_number, you should be able to use it like this:

for:
  minutes: !input "timeout_minutes"
6

The value of the variable timeout_minutes is something like input_number.motion_lights_timeout_minutes – it’s the entity_id of the input holding the value, not the value itself. That’s why states( in a template is necessary.

I think I can conclude that Support variables in a Template Trigger is the problem. You just can’t use variables in templates that are part of triggers.

I know I could use a number input directly on the blueprint but that doesn’t solve the case that I want which is to have the timeout be configurable at runtime. If it’s a number input on the blueprint then it can’t be changed at runtime.

You can however use them in wait_for_trigger actions for whatever reason, so this works:

blueprint:
#....elided description 
  input:
    timeout_minutes:
      name: Motion timeout input
      description:
        An input_number to configure the time after no motion when lights will turn off.
        Create a helper for this or add an input_number to your configuration.yaml.
      selector:
        entity:
          domain: input_number
variables:
  timeout_minutes: !input "timeout_minutes"
trigger:
  - platform: state
    entity_id: !input motion_entity
    id: motion_on
    from: "off"
    to: "on"
action: 
  - service: light.turn_on
    target:
      entity_id: !input "light_target"
 - wait_for_trigger:
    platform: state
    entity_id: !input motion_entity
    from: "on"
    to: "off"
    for:
    minutes: >-
      {{ states(timeout_minutes) | int }}

Unfortunately this isn’t a solution I can use in my actual use case since it would conflict with other triggers I need to use in the same automation.

Blueprints are just too limited to make anything more than trivial automations at the moment it seems. I’d need something like this feature request: Extend Blueprints to include Helpers, multiple Automations/Scripts and Lovelace

7

I mean, it’s not really the blueprint that’s the problem; automation triggers don’t support templates, universally. Just because your current understanding only allows trivial use-cases doesn’t signify a flaw in the tool itself :slight_smile:

I think my edit to my above post still applies though: you can just use a number selector instead of forcing the use of an input_number. This would put a number in the input variable, instead of an entity ID, and allow the use of the input variable in the trigger, I believe, while uncomplicating the process.

It has been awhile since I messed with blueprints, sorry for my forgetfulness when it comes to the interactions of everything. Here’s hoping I didn’t forget something else about input variables :sweat_smile: