Heads up! Upcoming breaking change in the Template integration

heck yes, many config used other entities than sensor.time. As a matter of fact, most of the entity_id’s I used were other entities for triggering the update.
Also, I used scripts to update the template sensor that without an entity_id set in the config wouldn’t update by itself.

in the case of my earlier posted unavailable template sensor:

  - platform: template
    sensors:
      entities_unavailable:
#        entity_id:
#          - script.update_entities_uun
#          - automation.check_for_unavailable_entities
        friendly_name: Entities Unavailable
        value_template: >

making sure this only ran on demand, because it was only needed to run on demand, and not constantly.

or like this, including sensor.time, making sure it ran, once a minute, but also on demand by the state change of the boolean (which was automated, so notifications ran immediately:

      github_repo_updates:
        friendly_name: Github repo updates
#        entity_id: input_boolean.github_repo_update, sensor.time
        value_template: >
          {% set updates_on = states.input_boolean
             |selectattr('entity_id','in',expand('group.github_repo_updates'))
             |selectattr('state','eq','on')|map(attribute='name')|list|count %}
          {{updates_on}}
        attribute_templates:
          updates: >
            {% set updates_on = states.input_boolean
               |selectattr('entity_id','in',expand('group.github_repo_updates'))
               |selectattr('state','eq','on')|map(attribute='name')|list %}
            {% if updates_on|length == 0 %}
              No Updates..
            {% elif updates_on|length == 1 %}
              The {{updates_on[0]}} repo has an update available
            {% elif updates_on|length == 2 %}
              The {{updates_on[0]}} and {{updates_on[1]}} repos have updates available, please check
            {% else %}
              The {{updates_on[:-1]|join(', ')}}, and {{updates_on[-1]}} have updates available, please check
            {% endif %}

the above example shows something else, might I ask that here: would be really cool if we could have global templates (call them variables if must) per template entity, so we can use that for all templates in that sensor. As you can see we need to double up on the yaml code now, while it could be so much shorter (and less error prone because of that).

like:

      github_repo_updates:
        friendly_name: Github repo updates
        variable:
          update_on: >
            {% set updates_on = states.input_boolean
             |selectattr('entity_id','in',expand('group.github_repo_updates'))
             |selectattr('state','eq','on')|map(attribute='name')|list %}
#        entity_id: input_boolean.github_repo_update, sensor.time
        value_template: >
          {{updates_on|count}}
        attribute_templates:
          updates: >
            {% if updates_on|length == 0 %}
              No Updates..
            {% elif updates_on|length == 1 %}
              The {{updates_on[0]}} repo has an update available
            {% elif updates_on|length == 2 %}
              The {{updates_on[0]}} and {{updates_on[1]}} repos have updates available, please check
            {% else %}
              The {{updates_on[:-1]|join(', ')}}, and {{updates_on[-1]}} have updates available, please check
            {% endif %}

I have several templates for which I have created an extra backend sensor to use like this, but that is way more complicated, and of course creates yet another sensor …
check this:

      weather_icon_backend:
#        entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
#        friendly_name_template: >
#          {{states('sensor.weather_icon').split('weather-')[1]|title}}
        value_template: >
          {% set mapper_icon =
            {'partly-cloudy-night':'night-partly-cloudy'} %}
          {% set mapper_br =
            {'pouring':'pouring',
             'lightning-rainy':'lightning-rainy',
             'snowy-rainy':'snowy-rainy'} %}
          {% set mapper_ds =
            {'clear-night':'night',
             'partlycloudy':'partly-cloudy'} %}
          {% set icon = states('sensor.dark_sky_icon') %}
          {% set buienradar = states('weather.buienradar') %}
          {% set dark = states('weather.dark_sky') %}

          {% set weather = mapper_icon[icon] if icon in mapper_icon else
                           mapper_br[buienradar] if buienradar in mapper_br else
                           mapper_ds[dark] if dark in mapper_ds else
                           dark if dark in
                             ['sunny','rainy','snowy','snowy-rainy','windy','fog','cloudy','hail','lightning']
                           else 'sunny-alert' %}
            mdi:weather-{{weather}}
#        icon_template: >
#          {{states('sensor.weather_icon')}}

      weather_icon:
#        entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
        friendly_name_template: >
          {{states('sensor.weather_icon_backend').split('weather-')[1]|title}}
        value_template: >
          {{states('sensor.weather_icon_backend')}}
        icon_template: >
          {{states('sensor.weather_icon_backend')}}

which, btw, is another fine example of a sensor using more than sensor.time for entity_id’s :wink:

I said to decrease the update frequency. For the GitHub and the weather ones, it seems like you do want updates immediately?

I think this can be changed to:

     {% set updates_on = expand('group.github_repo_updates')
             |selectattr('state','eq','on')|map(attribute='name')|list|count %}

and it would work perfectly with the new engine, with less cruft and using no processing power at all except when the booleans toggle. Did I miss something?

as said and explained eloquently by @123, the entity_id was also used for templates that didn’t update by them selves on 114. In this case, I was trying to illustrate that this same template sensor (that under 115 would constantly update) could be limited ( == decreasing) to updating on adding that entity_id.
but yeah your right, I could have picked better examples…

right, its me that missed that one. thanks!

can we use the expand function also in the reject line here?

          {{states|selectattr('state','in',['unavailable','unknown','none'])
                  |rejectattr('entity_id','in',ignore_list)
                  |rejectattr('entity_id','in',state_attr('group.entity_blacklist','entity_id'))
                  |rejectattr('domain','in',['group','media_player'])
                  |list|length}}

only my question on the globale template variable?

Gotcha. It’s a little bit complex so maybe I missed something but I believe this should work:

      weather_icon:
        friendly_name_template: >
          {{states('sensor.weather_icon').split('weather-')[1]|title}}
        value_template: >
          {% set mapper_icon =
            {'partly-cloudy-night':'night-partly-cloudy'} %}
          {% set mapper_br =
            {'pouring':'pouring',
             'lightning-rainy':'lightning-rainy',
             'snowy-rainy':'snowy-rainy'} %}
          {% set mapper_ds =
            {'clear-night':'night',
             'partlycloudy':'partly-cloudy'} %}
          {% set icon = states('sensor.dark_sky_icon') %}
          {% set buienradar = states('weather.buienradar') %}
          {% set dark = states('weather.dark_sky') %}

          {% set weather = mapper_icon[icon] if icon in mapper_icon else
                           mapper_br[buienradar] if buienradar in mapper_br else
                           mapper_ds[dark] if dark in mapper_ds else
                           dark if dark in
                             ['sunny','rainy','snowy','snowy-rainy','windy','fog','cloudy','hail','lightning']
                           else 'sunny-alert' %}
            mdi:weather-{{weather}}
        icon_template: >
          {{states('sensor.weather_icon')}}

It won’t work in that case where you do want to look at all entities.

I was trying to stay focused, it’s a bit hard having a discussion with a stream of consciousness. Also, I did not notice any question :slight_smile:

However, I did see a developer mention template variables not long ago so they might be coming (like they were just added to scripts).

think I am on to something , has to do with python scripts creating sensors on startup, and template sensors based on those sensors. I am experiencing great lag on that, and the fronted/startup seems to wait for them forever. creating errors as I posted here

didn’t want to tag you or Bdraco, so please let me ask like this here? Could this be something not foreseen in the quicker-than-light way of the new template engine?

Ive have experienced Python script issues from the offset of 115, but didnt yet relate it to this. All things created by them are taking time at startup. Once all has settled (which now can take up to triple the setup time from 114) they work fine and immediate.

FYI, I have my python script run at homeassistant start, havent yet tried to do so at delayed startup, because I would think that to enhance problem.
What would you say?

haha, that’s what I had before! exactly (I think)
I rewrote that because either you or Nick told us(me) not to use self-referencing templates…

have a look in my yaml to proof it:

      weather_icon_backend:
#        entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
#        friendly_name_template: >
#          {{states('sensor.weather_icon').split('weather-')[1]|title}}
        value_template: >
          {% set mapper_icon =
            {'partly-cloudy-night':'night-partly-cloudy'} %}
          {% set mapper_br =
            {'pouring':'pouring',
             'lightning-rainy':'lightning-rainy',
             'snowy-rainy':'snowy-rainy'} %}
          {% set mapper_ds =
            {'clear-night':'night',
             'partlycloudy':'partly-cloudy'} %}
          {% set icon = states('sensor.dark_sky_icon') %}
          {% set buienradar = states('weather.buienradar') %}
          {% set dark = states('weather.dark_sky') %}

          {% set weather = mapper_icon[icon] if icon in mapper_icon else
                           mapper_br[buienradar] if buienradar in mapper_br else
                           mapper_ds[dark] if dark in mapper_ds else
                           dark if dark in
                             ['sunny','rainy','snowy','snowy-rainy','windy','fog','cloudy','hail','lightning']
                           else 'sunny-alert' %}
            mdi:weather-{{weather}}
#        icon_template: >
#          {{states('sensor.weather_icon')}}

      weather_icon:
#        entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.buienradar
        friendly_name_template: >
          {{states('sensor.weather_icon_backend').split('weather-')[1]|title}}
        value_template: >
          {{states('sensor.weather_icon_backend')}}
        icon_template: >
          {{states('sensor.weather_icon_backend')}}

A real world example:

I found one that doesn’t update. Should it?

sensor:
  - platform: template
    sensors:
      pn_count:
        value_template: "{{ states.persistent_notification | length }}"

Normaly i use an automation to update it.

  - alias: persistent_notification_update
    mode: parallel
    trigger:
      - platform: event
        event_type: call_service
        event_data:
          domain: persistent_notification
          service: create
      - platform: event
        event_type: call_service
        event_data:
          domain: persistent_notification
          service: dismiss
    action:
      - service: homeassistant.update_entity
        entity_id: sensor.pn_count

If i deactivate that automation, the sensor doesn’t update.
Auswahl_394
but Templates editor shows this.

using this myself:

      count_persistent_notifications:
        entity_id: sensor.time
        friendly_name: Persistent notifications
        value_template: >
          {{states.persistent_notification|count}}
        attribute_templates:
          notifications: >
            {% set noti = states.persistent_notification
                          |selectattr('state','eq','notifying')
                          |map(attribute='attributes.title')
                          |list %}
            {% if noti|length == 0 %} No persistent notifications
            {% else %}
            {{noti|join(', \n')}}
            {% endif %}
        icon_template: >
          {% if states('sensor.count_persistent_notifications') > '0' %} mdi:message-bulleted
          {% else %} mdi:message-bulleted-off
          {% endif %}

which works fine, and it cant be because I forgot to take out entity_id: :wink: or?

Having only 1 set of templates left with {{states.xx}}, {{states.person|..) in this case, but I don’t see how I could change that?:

 - service: notify.filed_intercom_messages
   data_template:
   message: >
     {% set message = states('input_select.intercom_message') %}
     {% set device = states('input_select.intercom') %}
     {% set language = states('input_select.intercom_language') %}
     {% set id = trigger.to_state.context.user_id %}
     {% set time = as_timestamp(now())|timestamp_custom('%d %b: %X') %}
     {% set user = states.person|selectattr('attributes.user_id','eq',id)|first %} #<---- can we change this line?            
     {% set user = user.name %}
     {{time}}: {{user}} played "{{message}}" on {{device}} in {{language}}

Why do you want to change that line? You don’t need to change all your templates. They work fine as it is.

yes you’re right, this one only listens to 6 states, so that shouldn’t harm the system… was merely walking over all states. containing templates in the multi-file search result to reduce system overload as much as possible.
this one stays :wink:

generators don’t really impact memory like you seem to think they do. A listener dealing with 6 states vrs 1000 isn’t going to be that big of a difference.

17 posts were split to a new topic: Help with birthday python script & templates

Haha, sure, my pardon.
Though, it’s good to know HA 115 causes issues with not yet created template sensors, and that that has been recognized, and will probably fixed next update.

Which most certainly counts as a breaking change in the template integration…

I agree but the last 20-odd posts have been about using availability_template to optimize a Template Sensor.

Thank you Petro for splitting the topic. :+1:

ok this one is new:

      wakeup_radio_volume:
        friendly_name: Wakeup radio volume
#        entity_id:
#          - input_boolean.wakeup_radio
#          - input_boolean.snooze
#          - input_select.radio_station_wakeup
#          - input_select.wakeup_radio
#          - sensor.wakeup_radio
#          - sensor.wakeup_radio_state
#          - sensor.wakeup_radio_volume
#          - timer.increase_volume_delay
        value_template: >
          {{state_attr(states('sensor.wakeup_radio'),'volume_level')|float|round(2)}}
        icon_template: >
          {% set state = state_attr(states('sensor.wakeup_radio'),'volume_level')|float|round(2) %}
          {% if state == '0.0' %} mdi:volume-off
          {% elif state <= '0.3' %} mdi:volume-low
          {% elif state <= '0.6'%} mdi:volume-medium
          {% else %} mdi:volume-high
          {% endif %}

commented the entities that made this update. Now, it won’t even get a state in the template editor, showing Unknown error

In icon_template, you are assigning a float value to state. Then the template proceeds to compare that float value to numeric strings. Remove the single-quotes delimiting the numbers.

That seems to be a bug, it updates on new notifications but not when dismissing.

cc @bdraco