Templating changes in 2021.10.0

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.

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

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?

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)

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

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

See:

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

1 Like

Thank you @petro and @123 you both have been very helpful in getting me through this learning curve. I am finally starting to understand what each line means in the template (still making mistakes) but getting there. This site has help me

https://jinja.palletsprojects.com/en/2.10.x/templates/#forceescape

I still don’t understand some of the arguments. Is HA using a combination of Python / Jinja for what is allowed? For example I had used the word multiply in my template ( must have copied it from someones code) and I can’t understand why instead of just using " * ". Where can I get more information on “allowed” operations?

multiply is just a filter that was added to home assistant. I’m sure someone had a reason. You’re welcome to just use *.

Where do I find the filters that were added to HA?

I would think now that they are making sure the code has the correct defaults, maybe there should be some documentation if HA is allowing differences than what is in the Jinja docs.

When you do markdown cards do they follow the jinja docs, CSS or a combination?

For those curious, the multiply filter seems to make its first appearance in a PR from 2015:

It’s not clear from the PR what problem it was intended to solve. Perhaps the only notable thing is that it automatically converts strings to float before performing the multiplication. I don’t see any reference to it in the documentation.

1 Like

Hello guys!
I have same problem as many here, and i can’t find a solution for my case anywhere. I have date and time “assembled” together and currently it works fine, but of course it will need change in December. But, all options i tried - none of them work. My code, which now results in warning:

  sensors:
    danes:
      friendly_name: "Ime dneva"
      value_template: >-
        {% set danes = ["Ponedeljek", "Torek", "Sreda", "Četrtek", "Petek", "Sobota", "Nedelja"] %}
        {{danes[now().weekday()]}}

    mesec_number:
      friendly_name: "mesec kot številka"
      value_template: >-
        {% set mesec = ["Jan", "Feb", "Mar", "Apr", "Maj", "Jun", "Jul", "Avg", "Sep", "Okt", "Nov", "Dec"] %}
        {{mesec[now().month-1]}}


value_template: "{{float (states('sensor.danes'), default='0') + ', '
        }}{{ now().day }}.{{float (states('sensor.mesec_number'), default='Januar')
        }} - {{ now().hour }}:{{as_timestamp(states('sensor.date_time_iso')) | timestamp_custom('%M')}}"

If i try "float(‘Pon’) is an error. If i insert "default = “Pon” at the end i always get “Pon”, no matter what day it is (Pon meand Mon in my language).

Some help would be very appreciated…

Why is that value_template trying to do? Give an example of the output you want it to produce.

I think it’s a phonetic date

Exactly. Above “composition” gives me today’s date and current time:

Sre, 13. Okt - 20:53

Which would be (in english) : Wed, 13th. Oct - 20:53
If there’s any easier way i’m very open to suggestions. I’m not skilled programmer, i manage to “assemble” thing like this with internet searh&help (from you, guys!) and that’s pretty much it…

Copy-paste this into the Template Editor and see if it reports the date and time in your desired format:

{{'{}, {}. {} - {}'.format(states('sensor.danes')[:3], now().day, states('sensor.mesec_number'), (now().time()|string)[:5])}}
1 Like

Yeeeeah! It works! Thanks a lot! Now I will play a bit with your template in Template Editor to try understand how it works… i like to at least try to understand what i’m doing…

Now only thing left in core’s log is warning for my sensor “sensor.danes”. How do i change this into new format:

    dan:
      friendly_name: "dan"
      icon_template: mdi:calendar-range
      value_template: "{{ float (states('sensor.danes'))}}"

this sensor should give me only day of the week. I have same template for month name, too. It’s easy for “native englishmen”, since they have such names easier available (it’s not needed to convert to local)…

to be honest, i’m not quite sure why “float” is needed for strings…?

EDIT: is this correct? It gives correct result in template editor… I removed [:x]part, because day length is “day dependant”…

{{'{}'.format(states('sensor.danes'),(now().time()|string))}}

I don’t see how it can do that with this template:

{{ float (states('sensor.danes')) }}

The value reported by sensor.danes will be the name of the current weekday from this list:

["Ponedeljek", "Torek", "Sreda", "Četrtek", "Petek", "Sobota", "Nedelja"]

The float function can’t convert non-numeric strings into numbers. When it can’t convert the string it simply reports 0 by default (or whatever default value you specify).

Effectively, you are trying to do this and it will always report 0

{{ float("Sreda") }}

2 posts were split to a new topic: Template help: value_json is undefined

I guess i wrote wrong… with day of the week i meant NAME of that day (as you already figured it out…).
So, if i understand correct float is for conversion to numbers and as such not needed in my case? As i said, i made this on the base of what i found on the internet, and since it worked i left it this way… if this is the case then my question is really in wrong place. Sorry for that, my basic question is how to add default to float…

2 posts were split to a new topic: Time template troubles