Heads up! Upcoming breaking change in the Template integration

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

now that’s a fine catch. I wasn’t thinking of the icon_template at all, because that has always worked, dont ask me how… thank you Taras.

the underlying issue was a bit more complex, but has to do with this template sensor, which I had erroneously changed using |count, instead of |list|length to make it more efficient. In this case that was a stupid mistake, but, related to the new template integration:

      media_players_active:
        friendly_name_template: >
          {% set count = expand('group.media_players_active')
            |selectattr('state','eq','on')|list|length %}
          {% set player = 'player' if count in [0,1] else 'players' %}
          {% set number = 'No' if count == 0 else count %}
          {{number}} Media {{player}} active
#          {% set count = expand('group.media_players_active')
#            |selectattr('state','eq','on')|count %}
#          {% set player = 'player' if count in [0,1] else 'players' %}
#          {% set number = 'No' if count == 0 else count %}
#          {{number}} Media {{player}} active
#        entity_id:
#          - input_boolean.googlehome_hub
#          - input_boolean.googlehome_woonkamer
#          - input_boolean.googlehome_hall
#          - input_boolean.googlehome_master_bedroom
#          - input_boolean.googlehome_library
#          - input_boolean.googlehome_office_wijke
#          - input_boolean.googlehome_dorm_marte
#          - input_boolean.googlehome_dorm_louise
#          - input_boolean.theboss
        value_template: >
          {% set rooms = expand('group.media_players_active')
            |selectattr('state','eq','on')|map(attribute='object_id')|list %}
          {% set ns = namespace(speakers = '') %}
          {% for i in range(rooms|length) %}
            {% if states('input_boolean.' ~ rooms[i]) == 'on' %}
            {% set d = ', ' if ns.speakers|length > 0 else '' %}
            {% set ns.speakers = ns.speakers ~ d ~ 'media_player.' ~ rooms[i] %}
            {% endif %}
          {% endfor %}
          {% if ns.speakers|length|int == 0 %} None
          {% else %}
          {{ns.speakers}}
          {% endif %}

what’s even more, judging by the list of states this template listens to, it is even smarter than me listing several more entities I hadn’t listed that should really be there, be it dynamically. Which this now is.
So cool!

might be futile, but is there any efficiency difference between a |list|length and |list|count.
given the fact both are floating in various templates and the 115 has us rewrite our templates, I’d love to make clear on this too…even if only theoretical.

I don’t think there is any difference, the Jinja documentation says that length and count are aliases.

The important thing is to avoid list when it is unnecessary.