Why can't we use variables in a Template Sensor?

[123 (Taras)]

variables are useful but aren’t supported by Template entities (like Template Sensor). If variables were supported then we could avoid duplicating long templates and do things like this:

template:
  - sensor:
      - name: 'Open Doors'
        variables:
          doors: "{{ expand('group.doors_all') | selectattr('state', 'eq', 'on') | map(attribute='name') | list }}"
        state: "{{ doors | count }}"
        attributes:
          names: "{{ doors | join(', ') }}"

Instead of duplicating a long template like this (i.e. the way it’s done now):

template:
  - sensor:
      - name: 'Open Doors'
        state: "{{ expand('group.doors_all') | selectattr('state', 'eq', 'on') | map(attribute='name') | list | count }}"
        attributes:
          names: "{{ expand('group.doors_all') | selectattr('state', 'eq', 'on') | map(attribute='name') | list | join(', ') }}"

[petro]

You can already do this with trigger variables.

template:
- trigger:
  - platform: state
    entity_id: sensor.xyz
    variables:
      a: "{{ ... }}"
      b: "{{ .. }}"
  sensor:
  - name: ..
    state: "{{ a }}"
    attribute:
      b: "{{ b }}"

[123 (Taras)]

Aren’t trigger variables for use with a trigger? The Template Sensor example I posted has no trigger.

[petro]

@123

Aren’t trigger variables for use with a trigger?

trigger_variables is.

variables on any trigger is resolved after the trigger. Take a moment to read that whole section. This is a relatively new addition. However it still doesn’t work for your exact case but it does work for many cases. Just see the code I wrote above.

@petro

template:
- trigger:
  - platform: state
    entity_id: sensor.xyz
    variables:
      a: "{{ ... }}"
      b: "{{ .. }}"
  sensor:
  - name: ..
    state: "{{ a }}"
    attribute:
      b: "{{ b }}"

[123 (Taras)]

@petro

variables on any trigger is resolved after the trigger.

If there’s a trigger; this WTH isn’t about a Trigger-based Template Sensor.

The example posted above is a straightforward Template Sensor (no trigger).

[petro]

I can sense the “defend my WTH” going up. Let me preface this and say: I want this feature.

But also, let me say: You can tailor most template sensors without a trigger to have a trigger and make use of variables. Today.

[TheFes]

You can always create a trigger based template sensor which triggers on all entities used in your state based template sensor

[123 (Taras)]

@petro

can tailor most template sensors without a trigger to have a trigger

@TheFes

create a trigger based template sensor which triggers on all entities used in your state based template sensor

You’ve both effectively justified why it would be a great convenience to support variables for a Template Sensor.

The added complexity of conversion to a Trigger-based entity (for an entity that can already be easily implemented without a trigger), just to use trigger variables, negates the convenience aspect of avoiding template duplication.

Converting to a Trigger-based Template Sensor isn’t always possible. Case in point is the example I posted employing a group entity.

[petro]

I think you’re miss interpreting both of our responses. We are simply pointing out that you can get reusable code right now without needing this WTH. Your WTH is still valid and a good suggestion.

Our responses are simply to let you know that you can somewhat do this right now.

[123 (Taras)]

@petro

you can somewhat do this right now.

Special emphasis on the word “somewhat” where the additional complexity of the conversion can detract from the convenience of the goal (i.e. avoid duplication; shrink a few templates).

In addition, a trigger variable is specific to the trigger where it’s defined. So if there are multiple triggers, the variable must be defined in each trigger … which runs contrary to the original goal of minimizing template duplication.

[petro]

And I see you’re still arguing a person that’s not arguing with you…

@petro

I think you’re miss interpreting both of our responses

I voted for this and I’m moving on.

[TheFes]

Yaml anchors can avoid the duplication in the trigger variables

[CentralCommand (Mike)]

TIL trigger variables work in trigger template entities. I thought they only worked in automations for some reason. Guess I have a lot of refactoring work to do now.

[123 (Taras)]

@TheFes

Yaml anchors

Sure but it adds yet more complexity to something that ought to be simple.

It’s somewhat doable but fugly. To avoid template duplication you can convert the entire Template Sensor to a Trigger-based Template Sensor and employ YAML anchors and aliases for its multiple triggers.

Faced with that prospect, it’s currently easier, and probably less verbose, to just duplicate the template …

[petro]

Oh yeah, I did the same thing when I found out about them. Then I realized I didn’t really need it… yet. We need some other changes to triggers and template entities for template entities to reach their full potential.

[Cougar]

If it is already possible then it needs to be better documented at least.

[Joaquim_Monteiro]

Not sure if this would fix an issue I had some time ago when attempting wifi presence detection using dynamic ip addresses, or if the suggested variable trigger would do the trick… Anyways, I’m voting this.