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