Template triggers should allow Jinja templates

[tetele]

This is a follow up of this comment thread.

Context

Template entities can he trigger-based, but the triggers themselves cannot contain Jinja templates. This is usually not a major limitation, but in the context of #1027, we can argue that it's fast becoming a necessity.

Automations already have this feature by using trigger_variables to provide some limited templates which should get parsed before the actual automation config.

There will be cases when people will want to publish template blueprints in which the triggers will need to be based on input entities. This is one of the main usecases for blueprints in fact. Here's an example:

Let's say we have a blueprint such as:

blueprint:
  name: "Wasp in a box"
  description: "A binary_sensor which uses the so-called \"wasp in a box\" concept to determine occupancy of a room with a door sensor and a motion sensor."
  domain: template
  input:
    wasp_sensor:
      name: Motion sensor
      description: Binary sensor which indicates that there is a person in the room (such as a motion sensor)
      selector:
        entity:
          domain: binary_sensor
    box_sensor:
      name: Door sensor
      description: Binary sensor which indicates that the door is open, allowing people to enter and exit (such as a door sensor)
      selector:
        entity:
          domain: binary_sensor
    wasp_sensor_cooldown:
      name: Motion sensor cooldown
      description: The time it takes for the motion sensor to clear after no longer detecting any motion
      default: 0
      selector:
        duration:
variables:
  wasp_sensor: !input wasp_sensor
  box_sensor: !input box_sensor
  wasp_sensor_cooldown: !input wasp_sensor_cooldown
trigger:
  - id: door_open
    platform: state
    entity_id: "{{ box_sensor }}"
    from: "off"
    to: "on"
  - id: door_closed
    platform: state
    entity_id: "{{ box_sensor }}"
    from: "on"
    to: "off"
  - id: door_closed_long_ago
    platform: state
    entity_id: "{{ box_sensor }}"
    from: "on"
    to: "off"
    for: "{{ wasp_sensor_cooldown }}"
  - id: motion_detected
    platform: state
    entity_id: "{{ wasp_sensor }}"
    to: "on"
  - id: motion_cleared
    platform: state
    entity_id: "{{ wasp_sensor }}"
    from: "on"
    to: "off"
binary_sensor:
  state: >
    {% if trigger.id == "motion_detected" %}
      {% if is_state(box_sensor, 'off') %}
        on
      {% else %}
        {{ this.state }}
      {% endif %}
    {% elif trigger.id == "motion_cleared" %}
      {% if is_state(box_sensor, 'on') %}
        off
      {% else %}
        {{ this.state }}
      {% endif %}
    {% elif trigger.id == "door_closed" %}
      off
    {% elif trigger.id == "door_closed_long_ago" %}
      {%
        if this.state == "off"
        and is_state(wasp_sensor, 'on')
        and (as_timestamp(now())|float - states[wasp_sensor].last_changed|as_timestamp|float > 70)
      %}
        on
      {% else %}
        {{ this.state }}
      {% endif %}
    {% else %}
      {{ this.state }}
    {% endif %}
  device_class: occupancy

Config validation would fail because the entity_id of state triggers is expected to be an entity ID or UUID.

2024-10-03 07:50:54.970 ERROR (MainThread) [homeassistant.config] Invalid config for 'template' at configuration.yaml, line 88: Entity {{ box_sensor }} is neither a valid entity ID nor a valid UUID for dictionary value 'entity_id', got None

Proposal

Just as for automations, allow a trigger_variables property for template blueprints. These variables would be parsed just before registering the trigger for the template, allowing blueprint publishers to attach triggers to entities provided as input upon instantiation of their blueprints.

In the config above, that would mean moving the 3 items under variables: to trigger_variables:. Just as for automations, trigger_variables should also be available when the template entity state/attributes/availability actually gets computed or in the underlying action definitions.

[frenck]

To me, this sounds good. We have been matching up all of the modern templates with the automation syntax.

So, from my point of view, adding trigger_variables and adding template support to the triggers there, is just continuing that perspective.

Need another core member to agree.

👍