Heads up! Upcoming breaking change in the Template integration

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
   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:

        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: >
        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:

        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 %}
          {% 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.

ok, cool, thanks for making sure.

this seems to be broken, or at least acting up.

  - alias: Telefoon Marijn battery low level
    id: Telefoon Marijn battery low level
      platform: template
      value_template: >
        {{states('sensor.battery_telefoon')|float <
    condition: []
      service: notify.mobile_app_calltheboss
        title: Batterij Telefoon TheBoss bijna leeg
        message: >
          Nog maar {{states('sensor.battery_telefoon')}} %. Snel de oplader zoeken!



being 84%:

yet, upon reloading the template entities it keeps notifying me with

Battery Telefoon TheBoss bijna leeg
Nog maar unknown %. Snel de oplader zoeken!

happening on all mobile devices with this template and notification

I’ve got an example where the new template doesn’t appear to identify the entities to watch - in the template editor it is watching every sensor.

Am I right? Is there a way to do this?

        friendly_name: Cycle 1 Duration In Seconds
        #=== DEPRECATED
        # entity_id:
        #   - input_number.irrigation_number_of_zones
        #   - sensor.irrigation_cycle1_zone1_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone2_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone3_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone4_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone5_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone6_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone7_actual_duration_in_seconds
        #   - sensor.irrigation_cycle1_zone8_actual_duration_in_seconds
        value_template: >
          {% set ns = namespace(duration = 0) %}
          {% for zone in states.sensor if zone.object_id.startswith('irrigation_cycle1_zone') and 
                                          zone.object_id.endswith('_actual_duration_in_seconds') %}
            {% if loop.index <= states('input_number.irrigation_number_of_zones') | int %}
              {% set ns.duration = ns.duration + (zone.state | int) %}
            {% endif %}
          {% endfor %}
          {{ ns.duration }}

Yeah that’s correct.

If you put all those into a group and then use expand() on the group, it will filter to just the sensors you care about.

Reminder: this thread is about the deprecation of entity_id in Template Sensors and not every template problem. Your latest post is about a problem with an automation’s Template Trigger and is off-topic. Please start a separate thread to discuss your Template Trigger issue(s). Thank you.

Assuming you create group.irrigation_zones containing all the sensors you had listed in entity_id then I believe this (untested) template should work.

        friendly_name: Cycle 1 Duration In Seconds
        value_template: >
          {% set durations = expand('group.irrigation_zones') | map(attribute='state') | map('int') | list %}
          {% set max = states('input_number.irrigation_number_of_zones') | int %}
          {{ durations[0:max] | sum }}
1 Like

It was refreshing to see @Mariusthvdb realize that the new template engine can be smarter than humans. That actually reaffirmed me that removing entity_id: is right. Even a power user like that gets it wrong sometimes and it is just bad to have such a blunt tool around.

However, I have also realized something. There is a need for a static template renderer, like the Markdown card in Lovelace. The template sensor used to be able to do that and input_text is not a full substitute.

So I think we could add something like auto_update: false to the template sensor for the rare cases where manual control is desired. Control could be needed either because the template is computationally too heavy (though it can probably be optimized) or because one wants to snapshot a state.

This manual control would be with automations. These can do everything that entity_id: and the proposed scan_interval: can do, and so much more.

A little trick that I was thinking about is that users can add an attribute to affected sensors, something like update_frequency: minute. That would more or less replace entity_id: sensor.time and a single automation could then find and update all of these templates.

I am still thinking about how to best handle all this but how does the above sound to you guys?