Heads up! Upcoming breaking change in the Template integration

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
    trigger:
      platform: template
      value_template: >
        {{states('sensor.battery_telefoon')|float <
          states('input_number.battery_marijn_low')|float}}
    condition: []
    action:
      service: notify.mobile_app_calltheboss
      data_template:
        title: Batterij Telefoon TheBoss bijna leeg
        message: >
          Nog maar {{states('sensor.battery_telefoon')}} %. Snel de oplader zoeken!

and

{{states('sensor.battery_telefoon')}}

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?

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

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

4 Likes

don’t want to rush into this, but yes, having the auto_update: false added to the template sensor would come very close (read: simply would be) the answer to my request for being able to limit the auto updating :wink:

to yes, I would certainly applaud that. Considering we would then have best of both worlds, I feel that to be the ultimate situation we could wish for.

If that would also work in the template editor that would be perfect. Coming to think of it, maybe that could have a ‘tickable’ auto_update checkbox. Creating single snapshots of big and heavy templates, without breaking the system if one makes a mistake

update_frequency: minute would be nice to, but not as replacement for the auto_update: false. update_frequency: would be great, since we could also enter date there, or, maybe even a template …?

This was just a stray idea about how one could structure the automations, not something for HA to implement. Everybody has different ideas/needs and those can already be done with automations so it is redundant to support a subset just for the template sensor.

those are often the best :wink:

appreciating we can set freqency updates in a variety of ways in HA for the various integrations, I found your suggestion of update_frequency: for the template sensors particularly innovative.
Not only does it replace an up to now frequently used but deprecated option of entity_id:, it supersedes it in elegance and functionality.
Heck, it could even supersede the auto_update: when set to ‘off’
Or, maybe even better, like this:
Imagine you’d implement auto_update: as 'on'/'true' by default, use 'off'/'false' for a single run, and use another entity like sensor.time/sensor.date/sun.sun for more specific updating.
How cool would that be!

Sure we could write automations for updating these sensors, but this simple line would prevent a lot of extra code.

Won’t push any further, but since it was your own idea, I thought it useful to compliment that once more…

Yes I agree. I think: update_frequency: minute and auto_update: false could get the job done. And people who want it to update on any other ‘complex’ frequency would use an automation and auto_update: false. It would be the best of all worlds.

The only caveat is that the update_frequency should perform the action on the minute/hour/day, not based on startup. If they want it based on startup, they can use an automation.

It seems that I did not express that very well. I did not propose that HA should support update_frequency:, that would just be a renamed scan_interval:.

I meant to suggest a simple way that you could rebuild the periodic update feature, tailored for your own needs, with your own automation.

this could be both set in auto_update couldn’t it?
auto_update: minute

we’d only need the extra option auto_update: allowing for all possibilities to be set

I"m ok with whatever we go with. In a perfect world I would like the scan_interval updated (For all sensors) to handle time_patterns:

scan_interval: 60
scan_interval: /60
scan_interval: 
  minutes: 60
scan_interval: 
  minutes: /60

template entities would be unique where if scan_interval wasn’t defined in the platform, it wouldn’t perform an interval.

So I just realized that my Home Assistant thinks it is still Sunday. It is Wednesday today. I couldn’t figure out why automations were broken and now I know.

I have the following (split config). Can anyone help me fix it so that they will work again?

day_of_the_week.yaml

platform: template
sensors:
  day_of_the_week:
    value_template: "{{ now().strftime('%A') }}"
    entity_id: sensor.date

day_of_the_month.yaml

platform: template
sensors:
  day_of_the_month:
    value_template: >
        {% set suffix = ['st', 'nd', 'rd'] %}
        {% set day = now().day %}
        {% set index = 3 if day // 10 == 1 or day % 10 == 0 else (day % 10) - 1 %}
        {{ day~'th' if index > 2 else day~suffix[index] }}
    entity_id: sensor.date

month.yaml

platform: template
sensors:
  month:
    value_template: "{{ now().strftime('%B') }}"
    entity_id: sensor.date

time_date.yaml

platform: time_date
display_options:
  - 'time'
  - 'date'
  - 'date_time'
  - 'date_time_iso'
  - 'time_date'
  - 'time_utc'

your answer lies in post 1 of this thread…

entity_id is deprecated, replace that with the new as_local() instead of now() or add the sensor.time to the template itself. Exact yaml in post 1.

this seems to be what we all are doing now, as you suggest, replacing these entity_id’s in a new and dedicated group, maybe even per template sensor.

Though the expand function is magic and works beautifully, this ‘grouping’ is quite contrary to the earlier expressed reason for deprecating the all-groups: to costly for HA to maintain all those extra groups and need to have listeners for all state changes.

Just a thought.

That was before @bdraco’s changes :wink:

1 Like

haha, so we might get these all-groups back! I bet that would be even more efficient than creating them manually listing all entities, or by running an automation and use

    action:
      service: group.set
      data_template:
        object_id: all-lights
        entities: >-
          {%- for s in states.light %}
            {{s.entity_id}}{% if not loop.last %}, {% endif %}
          {%- endfor %}

I couldn’t get "{{ states.persistent_notification | length }}" to fail for me in testing.

Edit: Its probably because I have https://github.com/home-assistant/core/pull/40272 merged in and its fixed there.

1 Like