Passing data from template triggers to trigger variables

Hi all,

I was wondering if there was a way to pass computed values from a template trigger to the trigger variables.

As an example, consider the automation for timer announcement for alexa_media (which is what I’m trying to modify):

Timer announcement

The trigger currently is as follows:

- id: timer_announcement
  alias: Timer Announcement
  description: 'Announce the time remaining on a timer at 5 minute intervals, if the timer is for longer than 5 minutes.'
  trigger:
    - platform: template
      value_template: >
        {% if not is_state('sensor.kitchen_next_timer', "unavailable") -%}
        {%- set sorted_active = state_attr('sensor.kitchen_next_timer', 'sorted_active') | from_json -%}
        {%- set duration = (sorted_active[0][1].originalDurationInMillis / 60000)|int %}
        {% set remaining = ((as_datetime(states('sensor.kitchen_next_timer')) - states.sensor.time.last_changed|as_local).seconds // 60) -%}
        {{ duration > 5 and remaining != duration and remaining != 0 and remaining % 5 == 0 }}
        {% endif -%}
  action:
    - service: notify.alexa_media_kitchen
      data:
        message: >
          You have {{ time_remaining }} {{ "minutes" if time_remaining > 1 else "minute" }} left on your {{ timer_duration }} minute timer.
        data:
          type: announce
          method: all
  mode: single
  variables:
    timer_duration: >
      {% if not is_state('sensor.kitchen_next_timer', "unavailable") -%}
      {%- set sorted_active = state_attr('sensor.kitchen_next_timer', 'sorted_active') | from_json -%}
      {{ (sorted_active[0][1].originalDurationInMillis / 60000)|int }}
      {% endif %}
    time_remaining: >
      {% if not is_state('sensor.kitchen_next_timer', "unavailable")-%}
      {{ ((as_datetime(states('sensor.kitchen_next_timer')) - states.sensor.time.last_changed|as_local).seconds // 60) }}
      {% endif %}

I’d like to reference the computed values (i.e. sorted_active, duration, etc) elsewhere in the trigger so I don’t need to perform the whole template to get those values again.

Something along the lines of:

<% set duration= ….%>
 
…
variables:
   current_duration: “{{ duration }}”

As an aside, is it possible to do something like this:

variables:
   current_duration: (some complex template here)
   next_duration: “{{ current_duration + 1 }}”

Thanks…

I have a very similar issue, I have been testing quite a few different approaches, but so far I have failed…

The variables you have defined within value_template are Jinja2 variables and their scope is limited to the value_template option. Jinja2 variables are undefined outside of the option where they were defined.

Script variables can have a broader scope, it depends where they’re defined. If defined at the ‘top’ level, like alias and description, its scope is global throughout the script or automation (not all scripts/automations, just in the one where it’s defined).

In addition, a trigger can define variables (see Trigger Variables). These also have script-wide scope. In other words, what you asked for at the end of your post is possible. However, trigger variables containing templates are computed moments after the trigger fires (not before). There’s a second variation of trigger variable that’s computed earlier but it only supports limited templates (all of this is explained in the link I posted).

Would macros or namespaces work?

Not sure how you would import, though.

You can use !import to insert an entire chunk of YAML that’s defined in a separate file (not particularly useful for your posted example) but there’s no “import” for selecting a specific macro from a library of macros defined elsewhere. Jinja2 supports the concept but not in Home Assistant’s implementation of Jinja2.

I guess you could use an input helper to pass variables back and forth, but that gets kind of messy in terms of synchronization and number of helpers you’d need.

You can’t write to a helper from within a Template Trigger (where your example’s variables are defined), so can you elaborate on your proposal?

True, that won’t work.

I was thinking a template sensor with attributes. But I’m not sure how I would do it.