Global template variables

Feature Requests
1

Continuing the discussion from WTH, no global entity variables in template sensors?:

imagine we could replace the days=0 here, and then simply jot the whole template in an anchor and be done with it for days 0 - 5 .

      - unique_id: dark_sky_forecast_0
        name: >
          {{as_timestamp(now() + timedelta(days=0),none)|timestamp_custom('%a %-d %b',default='Not yet set')}}: {{
            states('sensor.dark_sky_forecast_icon_0d').replace('-',' ')|capitalize}}
        state: >
          {{- states('sensor.dark_sky_forecast_daytime_high_temperature_0d')|round(0)}}°/
          {{- states('sensor.dark_sky_forecast_overnight_low_temperature_0d')|round(0)}}°/
          {{- states('sensor.dark_sky_forecast_precip_probability_0d')|round(0)}}%
        picture: >
          {{'/local/weather/icons/' ~ states('sensor.dark_sky_forecast_icon_0d') ~ '.png'}}

by using:

      - unique_id: dark_sky_forecast_0
        variables: 
          day: 0
        name: >

or:

replace:

      - unique_id: composite_me_location
        name: Me location
        state: >
          {% set id = 'me' %}
          {{states('device_tracker.'~id~'_app')}}
        picture: >
          {% set id = 'me' %}
          /local/family/{{id}}_home.png
        attributes:
          location: >
            {% set id = 'me' %}
            {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
            {{state_attr(sensor,'Name')}} {{state_attr(sensor,'Postal Code')}} {{state_attr(sensor,'Locality')}} {{state_attr(sensor,'Country')}}
          country_code: >
            {% set id = 'me' %}
            {{state_attr('sensor.'~id~'_app_geocoded_location','ISO Country Code')|lower}}
          country: >
            {% set id = 'me' %}
            {{state_attr('sensor.'~id~'_app_geocoded_location','Country')}}
          latitude: >
            {% set id = 'me' %}
            {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
            {{state_attr(sensor,'Location')[0]}}
          longitude: >
            {% set id = 'me' %}
            {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
            {{state_attr(sensor,'Location')[1]}}

with:

      - unique_id: composite_me_location
        variables:
          id: me
        <<: &location_anchor
          name: >
            {{id}} location
          state: >
            {{states('device_tracker.'~id~'_app')}}
          picture: >
            /local/family/{{id}}_home.png
          attributes:
            location: >
              {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
              {{state_attr(sensor,'Name')}} {{state_attr(sensor,'Postal Code')}} {{state_attr(sensor,'Locality')}} {{state_attr(sensor,'Country')}}
            country_code: >
              {{state_attr('sensor.'~id~'_app_geocoded_location','ISO Country Code')|lower}}
            country: >
              {{state_attr('sensor.'~id~'_app_geocoded_location','Country')}}
            latitude: >
              {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
              {{state_attr(sensor,'Location')[0]}}
            longitude: >
              {% set sensor = 'sensor.'~id~'_app_geocoded_location' %}
              {{state_attr(sensor,'Location')[1]}}

# and here comes the true advantage of it:

      - unique_id: composite_she_location
        variables:
          id: she
        <<: *location_anchor
2

The proper way would be to have variables placed outside the sensors like scripts and automations.

template:
- variables:
    x: 4
  sensor:
  - name: a
    state: "{{ x }}"
  - name: b
    state: "{{ x + 1 }}"
3

in my examples, I am trying to inject a single changed variable into completely identical sensors (to be copied by the anchors). I am not sure your suggestion would do that?

maybe both techniques could be explored?

4

you can get the same thing.

template:
- variables:
    x: 4
  sensor:
  - name: a
    <<: &my_anchor
      state: "{{ x }}"

- variables:
    x: 5
  sensor:
  - name: b
    <<: *my_anchor
5

not sure I understand the need to do that, and btw, variables in scripts and automations are local for their scope aren’t they? Script Syntax - Home Assistant

I cant see why my code example wouldn’t be fully acceptable, or proper, as you say. To me, taking them out of the sensor config feels unconformable and tbh, I dont see the real advantage, unless one could even further compress other templates with the same variable?

But, following your suggestion, I would need:

template:
  - variables:
      id: she
    sensor:
      - unique_id: composite_she_location
        <<: *location_anchor

  - variables:
      id: me
    sensor:
      - unique_id: composite_me_location
        <<: *location_anchor

  - variables:
      id: george
    sensor:
      - unique_id: composite_george_location
        <<: *location_anchor

which seems to add some extra code lines compared to:

      - unique_id: composite_she_location
        variables:
          id: she
        <<: *location_anchor

      - unique_id: composite_me_location
        variables:
          id: me
        <<: *location_anchor

      - unique_id: composite_george_location
        variables:
          id: george
        <<: *location_anchor

might even pop in the unique_id there and make it even shorter:

      - variables:
          id: she
        <<: *location_anchor

      - variables:
          id: me
        <<: *location_anchor
6

I have no idea why it makes you feel uncomfortable, it was designed this way for a reason. You can have unlimited sensor items in the template list. That’s how your splitting of the configuration works. If you’re uncomfortable with that, then you should also be uncomfortable with packages. Otherwise it just highlights what you don’t understand about the system.

Having variables outside lets you push variables to multiple sensors, binary sensors, numbers, and selects and it would reside between triggers and the entities itself. It makes it much more powerful than your limited scope.

I’m not sure what you mean by compress, but you can do anything with jinja.

7

yes I can see that. I think both ways have their pro’s and con’s. as Ive edited the example above, I believe you can see the simpler code I suggested has its merits. ( in fact, it is how eg custom:button-card uses variables. local to the config it is used in)

The more powerful possibilities you explore are indeed impressive. I am not sure however of the use cases that would benefit from it.
My examples are real life template currently used :wink:

either way, Id be happy if this could be somehow realized, so yes, thanks for adding to this!

8

Yes, but what you aren’t understanding is that it’s literally the same… It’s not exactly the format that you want it. I’ve been meaning to implement this and if/when I do, its going on the level above to keep it consistent with every other area that uses variables.

You’re complaining about 1 line of code…

1 Like
9

nope, I am not. Id be welcoming this with open arms… So please don’t hold back. It would be amazing if we could finally do things like that.
given the state of affairs, its one of the more pressing evolutions we could use, or how do I say that politely without using the word ‘need’

1 Like