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}}
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
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.
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…
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.
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.
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 }}
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?
