Variables in trigger-bases template sensors

maxym · March 27, 2026, 6:42pm

Hello,

I have a template sensor that calculates its result using moderately complex logic. It works well and correctly updates the sensor state.

Now I need to expose some additional data—derived from the same calculation—as attributes of the same entity. I could duplicate the code, but that’s obviously not an approach I’d like to take.

In the documentation, I found that template sensors can use variables, and that trigger-based template sensors can refresh them more frequently than regular ones. I expected this to work similarly to variables in automations. That those variables are evaluated before the state and attribute templates, making possible to reuse these results to for state and attributes assigment.

The documentation is not very clear on this behavior. In fact, it seems incomplete or possibly contains a copy-paste error (see the bolded part):

Key-value pairs of variable definitions which can be referenced and used in the templates below (for trigger-based entities only). Mostly used by blueprints. With State-based template entities, variables are only resolved when the configuration is loaded or reloaded. Trigger based template entities resolve variables between triggers and actions.

Since my experiments with this approach haven’t been successful, could you help confirm whether what I’m trying to achieve is actually possible?

If not, could you suggest an alternative approach?

The only idea I’ve come up with so far is to create another template sensor that performs the full calculation, structures the results into an array or JSON, and exposes it as an attribute. Then, the final sensor(s) would simply read from that data. However, I’m somewhat reluctant to introduce intermediate “proxy” entities just for this purpose.

Thanks in advace.

Didgeridrew · March 27, 2026, 6:49pm

Yes, that is possible.

Post one of your experiments…

123 · March 27, 2026, 7:03pm

It’s been my experience that where you define a variable determines where it becomes accessible.

For example, if you define it within in variables in the actions section, it’s accessible in actions, state and attributes.

~~If I recall correctly, if you define it within the top-level variables section, it’s not accessible in attributes.~~ EDIT This was fixed. See petro’s post below.

Sir_Goodenough · March 27, 2026, 7:13pm

Agreed, and that is what messed me up with template blueprints. Variables in the top are only referenced when the template starts at restart, and not looked at until the next restart.

slimak · March 27, 2026, 7:32pm

I’m not sure if this is stated in the documentation, so for your information:

a variable can be defined anywhere within actions section (in terms of scope/nesting), and it will be available everywhere “below” that definition
you can define the same variable multiple times (it’s like assigning different values to an existing variable)
attributes are also considered variables (!) but they are scoped to the sensor in which they are defined
- you can refer to any attribute defined “above” simply by its name, and it will contain the newly calculated value (not the old one from the state machine)
- giving an attribute the same name as a regular variable will hide/redefine that variable in the given sensor (!)

A demo (send an event 'my_custom_event' to populate the sensors)

- trigger:
    - trigger: event
      event_type: my_custom_event
  action:
    - variables:
        v1: hello
    - if: "{{ true }}"
      then:
        - variables:
            v2: world
        - variables:
            v2: there
    - variables:
        v3: "{{ v1 ~ ' ' ~ v2 }}"
  sensor:
    - name: Variables and attributes demo
      state: "{{ v1 ~ ' ' ~ v2 }}"
      attributes:
        a1: "{{ v3 }}"
        a2: 5
        a3: "{{ a2 + 5 }}"
        v1: 6
        a4: "{{ v1 }}"
    - name: Variables and attributes demo 2
      state: "{{ v1 }}"

maxym · March 27, 2026, 7:53pm

Thank you all
Great info there. Answers on my concerns. Yes, I was trying with top-level defined variables. This is how it is presented in documentation: Template - Home Assistant, including examples on this page

May I ask about “below” term? I believe it’s not about position in the code, but in the objects tree. So variable scope is valid for current level and all children. Is it correct?

slimak · March 27, 2026, 8:06pm

I meant “below” in the top-down direction. I modified my example to better illustrate this: variable v3 “sees” v2, even though v2 is nested.

Didgeridrew · March 27, 2026, 8:45pm

Top level variables work fine.

You can modify slimak’s example to use top-level variables…

- sensor:
    - name: Hello Goodbye demo
      default_entity_id: sensor.hello_goodbye_demo
      state: "{{'hello' if now().minute is even else 'goodbye'}}"

- triggers:
    - trigger: event
      event_type: my_custom_event
      variables:
        my_entity: "sensor.hello_goodbye_demo"
  variables:
    v1: "{{ states(my_entity) }}" #Included to show that top-level `variables` are not only Limited Templates
  actions:
    - if: "{{ true }}"
      then:
        - variables:
            v2: world
        - variables:
            v2: there
    - variables:
        v3: "{{ v1 ~ ' ' ~ v2 }}"
  sensor:
    - name: Variables and attributes demo
      state: "{{ v1 ~ ' ' ~ v2 }}"
      attributes:
        a1: "{{ v3 }}"
        a2: 5
        a3: "{{ a2 + 5 }}"
        v1: 6
        a4: "{{ v1 }}"
    - name: Variables and attributes demo 2
      state: "{{ v1 }}"

…and it still works

I don’t think there’s any major benefit to assigning the value in “top-level” variables versus “action” variables (unless you are using a conditions block where you need the variable as well). But, if you’re having problems when using them, the actual issue may be something else entirely.

dtrott · March 27, 2026, 10:25pm

At the end of the day whatever objects or techniques you use, you are always creating a solution out of the same 4 basic building blocks:

Triggers - Something has to change (or be polled) in order for subsequent updates to happen.
Conditions
Logic/Automations/Calculations - What you are trying to do.
State

Triggers

Simple sensors (and groups) manage trigger conditions for you - if a group members or the referenced entity change, the rest of the logic runs.

For Trigger based sensors or automations you get to define the trigger condition(s).

Conditions

In a nutshell conditions provide a way to stop automations from continuing (after a trigger has occurred).

There are some more advanced use cases - such as:

Conditions prevent metadata from being updated.
Evaluation of conditions at an earlier time (in the case of queued updates) than the main automation execution.

However that’s getting deeply into the weeds.

Logic

Even a simple group has logic (And or Or) obviously automations or scripts allow you complete flexibility into the functionality.

The body of (sensor) templates are another form of logic.

State

Can be:

Explicit - when you create input helpers (you must explicitly set the state).
External - any physical device which provides updates to HA.
Temporary - A number of sensors are retained in memory in HA, however these don’t survive HA restarts.
Implicit - Trigger based sensors retain their state even over HA restarts.

Conclusion

If you want to update multiple values simultaneously the cleanest approach may be to declare a bunch of “input” controls then just use a single automation to perform all the calculations and update each of the inputs with the correct calculated values.

Most of the sensors only provide a single output, so they are fine/clean if you have a complex calculation that results in a single value, but they may not be a good fit if you have multiple outputs.

Unfortunately one nice feature of sensor is that you get to define unit of measure - that is something which you can’t do with input helpers, there are some work arounds for that (such as defining a sensor which simply reads the input helper) but its not “clean”.

petro · March 28, 2026, 3:32pm

I fixed that.

So here’s how it all works:

State Based

Variables at the root level spill into variables at the entity level.
Variables at the entity level are shared with all template options, including attributes and template actions.
Variables at the root level are resolved on configuration load.
Variables at the entity level are resolved on configuration load.
Variables do not update any state template option.

Trigger Based

Variables at the root level spill into variables at the entity level.
Variables at the entity level are shared with all template options, including attributes and template actions.
Variables at the root level are resolved between triggers at the root level and actions at the root level
Variables at the entity level are resolved after conditions at the root level and all template options on the entity level

maxym · March 28, 2026, 6:17pm

Again, thank you for all the time you spend in this thread.
It’s very helpful. Great knowledge base over here.

Why I was thinking root-level vairables don't work

FYI: previously I stated that root-level variables don’t work as expected. It’s because reloading of template entities was throwing dangerously looking errors into the logs. I managed to narrow it down to the fact that another YAML-created template sensor was used as a trigger.

I assume that reloading templates triggered the template sensor providing invalid/uninitialized values to the template.

2026-03-28 09:48:56.909 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: list object has no element 0 when rendering

maxym · March 28, 2026, 7:47pm

If I may continue, why using this in variable template raises Template variable error: 'this' is undefined when rendering ?

I’m using following expression within the template:

{% set old_val = this.attributes.data or dict(start=none, end=none) %}

The syntax below works without problems, while I would like to avoid hardcoding of entity id.

{% set old_val = state_attr('my_entity_id', 'data') or dict(start=none, end=none) %}

slimak · March 28, 2026, 8:29pm

Unfortunately this variable only works within sensors/entities (state, attributes, etc.). Probably one of the reasons is that multiple entities can be defined for one trigger/action block.

maxym · March 28, 2026, 11:38pm

But this should reference the template sensor, the mentioned template is part of. Not sure what you mean by multiple entities.

HappyCadaver · March 29, 2026, 12:19am

Trigger based template entities (plural) can have more than one entity (sensor or otherwise).

template:
  - unique_id: my_unique_id
    triggers:
      - trigger: state
        entity_id: domain.sensor_id
    variables:
      my_var: some value
    actions:
      - action: domain.action
        target: domain.some_entity_id
    sensor:
      - name: sensor one
        state: "{{ jinja_state }}"
      - name: sensor two
        state: "{{ other_jinja_state }}"
    switch:
      - name: switch one
        state: "{{ yet_another_jinja_state }}"
        turn_on:
          - action: domain.more_actions
        turn_off:
          - action: domain.the_opposite_action

etc. So this, which represents a ‘state object’, needs to be entity (sensor or otherwise) specific as it represents their individual state object.

(edited to fix indentation etc.)

maxym · March 29, 2026, 1:05am

Didn’t know that.
Then yes, it does make sense. But docs are confusing then:

State-based and trigger-based template entities have the special template variable this available in their templates and actions. The this variable is the current state object of the entity and aids self-referencing of an entity’s state and attributes in templates and actions.

Probably valid for templates within particular sensor tree (state, attributes as you mentioned earlier). I cannot say that the second sentence from the quote provides the same meaning

dtrott · March 29, 2026, 2:38am

Aye this is new to me too - as a result you can ignore the “Conclusion” section in my previous post it looks like trigger based templates can handle the scenario I thought required an automation.

HappyCadaver · March 29, 2026, 2:54am

I found that it seems confusing but it’s actually specifically accurate. It’s just hard to read since things like actions can be nested within entities as well as being top level and the term template(s) requires context…

State-based and trigger-based template entities have the special template variable this available in their templates and actions. The this variable is the current state object of the entity and aids self-referencing of an entity’s state and attributes in templates and actions.

Maybe it could read better as

State-based and trigger-based template entities have the special template variable this available in their templates and actions. The this variable is the current state object of the entity and aids self-referencing of an entity’s state and attributes in the templated entities and actions.

Either way it’s not an easy write in an already long doc page.

petro · March 29, 2026, 9:43am

Templates when said alone mean the jinja code. So the sentence is saying that this is available in all the yaml options that allow templates and all the yaml options that allow actions for the template entity definition. This does not include triggers, conditions, or actions at the root level as they are defined outside the template entity definition.

Unfortunately, it would be incredibly difficult to even get this into those sections. It would require a total rewrite for trigger based template entities, and it would likely adversly affect other integrations that use that object under the hood: snmp, command_line, rest, etc.

slimak · March 29, 2026, 12:46pm

The trigger object is also available in root conditions/actions, and you can retrieve data from it (e.g. trigger.from_state and trigger.to_state), just like in automation. This won’t give you the previous template sensor values, but you can calculate new ones (assuming they come from that trigger, of course).