Reusable/Shared trigger template variables

Feature Requests
1

Greetings,
I’m writing a Template Sensor which has to be ON when a specific Template has triggered but I’m facing a boring things: I have to triplicate statements.

The most semplified version of my Template sensor is this:

- trigger:
    - platform: template
      value_template: >-
        {{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count > 0 }}
    - platform: template
      value_template: >-
        {{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count <= 0 }}
  action:
    - variables:
        entities_on: >-
          {{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count }}
  binary_sensor:
    - name: Cucina attiva
      state: >-
        {{ (entities_on | int(0) > 0) }}

As you can see the Jinja part from “expand()” to “…| list | count” have to be replicated three times to achieve the right result:

  • two times for Template Sensor triggers
  • one time for the State

Without the “action” part I would have have write a “variables” section in each trigger and more than three replications would have beed needed, so something is already done to avoid replications but I think it could be done something more.

I mean something like this (UPPERCASE parts relevants):

- trigger:
    - platform: template
      value_template: "{{ ENTITIES_COUNT > 0 }}"
    - platform: template
      value_template: "{{ ENTITIES_COUNT <= 0 }}"
  VARIABLES:
    - ENTITIES_COUNT: >-
        {{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count }}
  binary_sensor:
    - name: Cucina attiva
      state: >-
        {{ (ENTITIES_COUNT | int(0) > 0) }}

or just let that a “trigger_variables” section be resposable to create entities Listeners AND those variables that can be used in the whole Sensor Template.

At this moment this is how variables works but…:

  • we can add a “variables” section for each Trigger BUT these variables are not shared across Triggers
  • we can add an “action” section to declare variables BUT these are evaluated only after the trigger execution
  • each trigger “variables” section doesn’t shares its values with “action” section
  • “trigger_variables” section here is not useful for the obliviously reason
2

You don’t need a trigger in this case, you don’t even need YAML

Just use this this in a template binary sensor helper you’ll get what you want:

{{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count > 0 }}
2 Likes
3

This has been explained to him multiple times. He’s not listening to advice, he’s actively ignoring people (including developers who work on templates).

Relevant thread

3 Likes
4

To anyone who thinks this FR has merit I recommend you first review the following topic.

emandt misunderstands how templates are processed in Template entities. He insists Template Sensors and Template Binary are always more performant if they have triggers. That’s incorrect.

Despite being proven wrong (by people who know how it actually works), he chooses to cling to his mistaken beliefs. The result is bloated code that needs a new feature to make it more manageable.

As mentioned by TheFes, a simple Template Binary Sensor produces the same results as the Trigger-based version shown above but with less processing demand and a fraction of the code. It doesn’t require duplicated/triplicated templates so it doesn’t need a new feature to make it manageable.

- binary_sensor:
    - name: Cucina attiva
      state: >-
        {{ expand('group.abcd') | rejectattr('entity_id', 'in', ['switch.on_off']) | selectattr('state', 'eq', 'on') | list | count > 0 }}

tl;dr

If you find yourself creating a Trigger-based Template entity with identical or nearly identical templates in its Template Trigger and state template, you don’t need the trigger-based variety (and so you don’t need a new feature for it).

5

What I wrote in that Thread has nothing to do of what I’m asking here that regards ONLY the possibility to avoid replicate statements between Triggers and State sections of the same YAML.

If a test or an example could be solved in OTHER ways it has nothing to do with this “Feature request” that could avoids ppl from replicate statements many an many times.

For the other discussion we can continue in the other right Thread :sweat_smile:

6

solve those with either Yaml anchors, or custom_templates

(I wont go into your misuse of the trigger template above, as you’ve been repeatedly told that’s counter productive, inefficient and unnecessary…)

1 Like
7

I checked and seems that Anchors are used ony to STORE YAML statements but I don’t think they are evaluated as a Trigger needs…and I think Macros works in the same way where only calling the Macro will trigger its eveluation but not for its own in a Trigger section.
However I’ll try Macros to confirm this.

PS: however decoupling/splitting YAML in multiple files that require Import could not be easy to manage, but if it would be the only solution… :man_shrugging:

8

you dont need a trigger section… how many times of repeating that will it take for you to accept that
wait, that was in the other thread… sorry I got confused

and Yaml anchors copy anything, no matter what, its just a way of c&p

9

:popcorn: Just watching… :joy:

1 Like
10

FYI, I put in a PR recently that will solve this FR.

In your case your template sensor would be…

- trigger:
    - platform: template
      value_template: >-
        {{ expand('group.abcd') | rejectattr("entity_id", "in", ['switch.on_off']) | selectattr('state', 'eq', 'on') | list }}
  binary_sensor:
    - name: Cucina attiva
      state: >-
        {{ trigger.value | count > 0 }}
1 Like