Templating changes in 2021.10.0

[WeatherWitch]

Nothing wrong with Fortran

[walaj (Jon Waland)]

@petro

Is this from that really old ‘battery notification’ engine that NotoriousBDG wrote in 2017

yup.

[WeatherWitch]

Thanks once again for all your help Petro - No more errors!

The only thing I changed was

{{ (humidities | sum / humidities | count) | round(2)}}

Just to tidy up the output.

[123 (Taras)]

@petro

I don’t think he had any prior python knowledge before learning this.

Correct.

---

@bschatzow
Never used python until Home Assistant. I know just enough now to get by. Lots of online python resources (Google is your friend).

[bschatzow (Bill Schatzow)]

Does it make sense to start with Jinja tutorials?

[123 (Taras)]

Probably since most of what is shown in this thread is Jinja2 (with a smattering of python). However, good luck finding Jinja2 tutorials targeted for Home Assistant’s implementation of Jinja2.

The official Jinja2 documentation is thorough but dry and not everything it describes is implemented in Home Assistant. I found the most useful section to be the lists of Builtin Filters and Builtin Tests but not all are available in Home Assistant and there are custom filters not mentioned in Jinja2’s documentation.

[petro]

I don’t think they exist. You might get something looking up ansible, not entirely sure what the link is between the 2 but it seems to be more widely used.

[Mariusthvdb (Marius)]

duh… ofc. thanks (being quite for a moment to contemplate my blunder)

[Mariusthvdb (Marius)]

.19…20…

@bschatzow

the changes are going to force us to learn to code the templates correctly

do we already have consensus on that that would be ‘correcty’ ?

I mean we can set |float(0) but that would only mean the template always succeeds, not perse the value is useful or even correct . If the value of an mqtt sensor would be unavailable and we float it to default, it still is evaluated as 0, with rather undesired consequences…

need to default to float(none) after all then?

even worse: ive got a group with power sensors, some of which are turned off , as in dont have a power reading at all, being unavailable. the template sensor returns

Template warning: 'float' got invalid input 'unavailable' when rendering template '{{(expand('group.lights_inside_total_device_power')

on those:

          {{states('sensor.lights_inside_total_device_power')|float +
            states('sensor.lights_outside_total_device_power')|float}}

based on

          {{(expand('group.lights_inside_total_device_power')
             |map(attribute='state')|map('float')|sum)|round(2)}}

where to set a (which) default…?
testing this for a reload

|map('float',0)

which should be fine for the individual power sensors, but not for the energy sensors (they are total_increasing…)

also, the all lights power sensor (derived from the expand group template) shouldn’t default to 0 either, because it never can/will/should be 0…

[bschatzow (Bill Schatzow)]

I would hope we do. Like any computer language there are rules, definitions, etc. The problem with most of us (myself included) I really did not understand what the code was doing when I copied different examples and modified them to my system. I would think if you follow the rules and you understand what each statement is doing it “should” work. If it doesn’t I believe with the experts here someone will be able to explain why.
I am still trying to understand what each line in my “copied code” does. Most of my errors have to do with command line sensors used to show updates on core, system, hacs, etc. Other errors have to do with markdown cards that are using templates. Again, I justed edited them and changed the sensors to my sensors. This worked well for me until this release.

[DavidFW1960 (David)]

So this template…

{{ max|round(0,default='none')}}°/{{ min|round(0,default='none')}}°/{{states('sensor.kariong_rain_chance_0')|round(0,default='none')}}%

I previously used round(0) to round to 0 decimal places (I thought) Now I added the default=‘none’ as I don’t want it using 0 as the default. It also wouldn’t work without the default= part.
In the docs for round it seems that round(x,y,z) is the syntax? Where x is the rounding, y could be floor or ceiling and z is the default but I am only seeing the default in the above examples. Why do I have to use default=?

[petro]

If you don’t provide the second argument, you need to provide the word default so that the code knows it’s the value for default.

[pnakashian (Pierre)]

thanks that simplifies it quite a bit.

[Mariusthvdb (Marius)]

btw, no rest allowed: https://github.com/home-assistant/core/pull/57470

only a few left, this being a prominent one in the log:

          {%- set tracker_timestamp = as_timestamp(strptime(states('sensor.afvalwijzer_next_date'),'%d-%m-%Y')) %}
          {%  set months = ['Januari','Februari','Maart','April','Mei','Juni','Juli','Augustus','September','Oktober','November','December'] %}
          {%- set wdays = ['Zondag','Maandag','Dinsdag','Woensdag','Donderdag','Vrijdag','Zaterdag'] %}
          {%- set wday = tracker_timestamp|timestamp_custom('%w')|int %}
          {%- set month = tracker_timestamp |timestamp_custom('%m')|int %}
          {{tracker_timestamp|timestamp_custom(wdays[wday]  ~ ' ' '%-d' ' ' ~ months[month-1])}}

it sees 3 warnings:

2021-10-12 00:53:36 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'strptime' got invalid input 'Geen' when rendering template '{%- set tracker_timestamp = as_timestamp(strptime(states('sensor.afvalwijzer_next_date'),'%d-%m-%Y')) %} {%  set months = ['Januari','Februari','Maart','April','Mei','Juni','Juli','Augustus','September','Oktober','November','December'] %} {%- set wdays = ['Zondag','Maandag','Dinsdag','Woensdag','Donderdag','Vrijdag','Zaterdag'] %} {%- set wday = tracker_timestamp|timestamp_custom('%w')|int %} {%- set month = tracker_timestamp |timestamp_custom('%m')|int %} {{tracker_timestamp|timestamp_custom(wdays[wday]  ~ ' ' '%-d' ' ' ~ months[month-1])}}' but no default was specified. Currently 'strptime' will return 'Geen', however this template will fail to render in Home Assistant core 2021.12
2021-10-12 00:53:36 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'as_timestamp' got invalid input 'Geen' when rendering template '{%- set tracker_timestamp = as_timestamp(strptime(states('sensor.afvalwijzer_next_date'),'%d-%m-%Y')) %} {%  set months = ['Januari','Februari','Maart','April','Mei','Juni','Juli','Augustus','September','Oktober','November','December'] %} {%- set wdays = ['Zondag','Maandag','Dinsdag','Woensdag','Donderdag','Vrijdag','Zaterdag'] %} {%- set wday = tracker_timestamp|timestamp_custom('%w')|int %} {%- set month = tracker_timestamp |timestamp_custom('%m')|int %} {{tracker_timestamp|timestamp_custom(wdays[wday]  ~ ' ' '%-d' ' ' ~ months[month-1])}}' but no default was specified. Currently 'as_timestamp' will return 'None', however this template will fail to render in Home Assistant core 2021.12
2021-10-12 00:53:36 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'timestamp_custom' got invalid input 'None' when rendering template '{%- set tracker_timestamp = as_timestamp(strptime(states('sensor.afvalwijzer_next_date'),'%d-%m-%Y')) %} {%  set months = ['Januari','Februari','Maart','April','Mei','Juni','Juli','Augustus','September','Oktober','November','December'] %} {%- set wdays = ['Zondag','Maandag','Dinsdag','Woensdag','Donderdag','Vrijdag','Zaterdag'] %} {%- set wday = tracker_timestamp|timestamp_custom('%w')|int %} {%- set month = tracker_timestamp |timestamp_custom('%m')|int %} {{tracker_timestamp|timestamp_custom(wdays[wday]  ~ ' ' '%-d' ' ' ~ months[month-1])}}' but no default was specified. Currently 'timestamp_custom' will return 'None', however this template will fail to render in Home Assistant core 2021.12

please help me out where to ad some defaults? Though this mentions the input being invalid, and I am not sure how to handle that. The input is ok however, and currently as intended…

the only other warningI get is on the DST sensor:

2021-10-12 00:53:37 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'timestamp_local' got invalid input '167 days, 0:00:00' when rendering template '{%- set ns = namespace(previous=2,spring=none,fall=none) %} {%- set today = strptime(states('sensor.date'),'%Y-%m-%d').astimezone().replace(hour=ns.previous) %} {%- for i in range(365) %} {%- set day = (today + timedelta(days=i)).astimezone() %} {%- if ns.previous - day.hour == -1 %} {%- set ns.spring = today + timedelta(days=i)|timestamp_local %} {%- elif ns.previous - day.hour == 1 %} {%- set ns.fall = today + timedelta(days=i)|timestamp_local %} {%- endif %} {%- set ns.previous = day.hour %} {%- endfor %} {{([ns.spring,ns.fall]|min).isoformat()}}' but no default was specified. Currently 'timestamp_local' will return '167 days, 0:00:00', however this template will fail to render in Home Assistant core 2021.12

but that was before I deleted |timestamp_local. Must re-read this thread again to understand why I can now take that out, or why that caused the error…

[bschatzow (Bill Schatzow)]

I though I understood what to do but I have a simple sensor that is giving a warning.

platform: template
sensors:

  total_distance_mtr_miles:
    friendly_name: "miles_walked"
    unit_of_measurement: 'miles'
#added round(2,default=0) 10/8/2021
    value_template: "{{ states('sensor.total_distance_mtr') | multiply (1/1609.3444) | float(2) | round(2,default=0)}}"

• Template warning: ‘multiply’ got invalid input ‘unavailable’ when rendering template ‘{{ states(‘sensor.total_distance_mtr’) | multiply (1/1609.3444) | float(2) | round(2,default=0)}}’ but no default was specified. Currently ‘multiply’ will return ‘unavailable’, however this template will fail to render in Home Assistant core 2021.12
  Tried float (defaultt=0) and it didn’t help.

[123 (Taras)]

@bschatzow

‘multiply’ got invalid input ‘unavailable’

It’s saying that the value multiply received was unavailable. That means the result of states('sensor.total_distance_mtr') was unavailable.

Even if it wasn’t unavailable, the sensor’s state value is a string and you can’t do arithmetic with strings (you have to first convert them to numbers using float or int).

[bschatzow (Bill Schatzow)]

I thought I did with the float? It has worked for several years as is. Is the order wrong in the statement? I tried float | multiply (changed order) and no difference. It is just converting the garmin meters to miles. Why would the Meters be a string?

[petro]

The float is applied to what comes before it. That’s how filters work.

what_filter_is_apply_to | filter

You’re applying the filter to

multiply (1/1609.3444) | float(2)

it should be

states('sensor.total_distance_mtr') | float(2) | multiply (1/1609.3444) | round(2,default=0)

also, I think multiply needs a default too.

Also multiply converts strings to floats for you.

so…

states('sensor.total_distance_mtr') | multiply (1/1609.3444, 0) | round(2,default=0)

[bschatzow (Bill Schatzow)]

On multiple you don’t need , default=0?

[petro]

No, multiply only takes 2 arguments. So you don’t need to call out the names because you aren’t omitting an argument.

See:

Updating Templates with the new default values in 2021.10.x

I keep seeing the same question about the new default argument for the templating. This post will cover all possible ways to define default. All the methods that were changed: acos as_timestamp asin atan atan2 cos float log round sin sqrt strptime tan timestamp_custom timestamp_local timestamp_utc Each of them have the exact same default functionality but a different number of arguments. There are multiple ways to use these functions, and this is where all the confusion lies. Understandi…

the only reason you need to use the word default is when the argument you are trying to set is not the next argument that’s required.

I.e. my_method(arg1, arg2=True, arg3=47) requires 3 arguments named arg1, arg2, and arg3. arg1 is required and arg2 and arg3 are optional, because they have a default value for them. When you omit arg2 and arg3, they auto populate my_method with True and 47. Meaning if you call my_method with my_method(7), arg1 will have 7, arg2 will have True, and arg3 will have 47. Well, what happens when you want to supply my_method with arg3 as 50 instead of 47? Well you have 2 options. Populate all 3 arguments; my_method(7, True, 50) or supply the single argument you want to populate my_method(7, arg3=50).

This is why you see default used and not used all over the place. FYI you can also supply all 3 and it still works; my_method(7, arg2=True, arg3=50).