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