Templating changes in 2021.10.0

what about this template in a template-entity-row complaining about not setting a default, while I explicitly have set it…:

[homeassistant.helpers.template] Template warning: 'round' got invalid input 'None' when rendering template '{% if states(config.entity) not in ['unknown','unavailable'] and
      states[config.entity] is not none %}
  {% set temp = states('sensor.pond_buiten_sensor_calibrated_temperature')|float(none)|round(2,'Not ready') %}
  {% set dark = 'Licht' if is_state('binary_sensor.dark_outside','off') else 'Donker'%}
  {{relative_time(states[config.entity].last_changed)}} ago, {{dark}} en {{temp}} °C
{% else %} Not yet set {% endif %}' but no default was specified. Currently 'round' will return 'None', however this template will fail to render in Home Assistant core 2021.12

just to make sure it exists Ive even changed to an extra if in the template, like:

    secondary: >
      {% if states[config.entity] is not none %}
        {% if states(config.entity) not in ['unknown','unavailable'] and
              states[config.entity] is not none %}
          {% set temp = states('sensor.pond_buiten_sensor_calibrated_temperature')|float(none)|round(2,'Not ready') %}
          {% set dark = 'Licht' if is_state('binary_sensor.dark_outside','off') else 'Donker'%}
          {{relative_time(states[config.entity].last_changed)}} ago, {{dark}} en {{temp}} °C
        {% else %} Not yet set
        {% endif %}
      {% else %} No entity yet
      {% endif %}

The round filter can take three parameters and the third parameter is for setting the default value. However in this example it appears in the second position so it’s not understood to be the default value.

round(2, 'Not ready')

You can either specify all three parameters, in the correct order, or do this to explicitly indicate the default parameter:

round(2, default='Not ready')
1 Like

thanks Taras, will try and yes I see that now the warning is gone.
very odd though, because I have things like

value_template: >
  {{value|round(0,none)}}

throughout the system, and no warning has been issued anywhere. Must check why…

supplying none to method results in a normal round.

Screenshot from 2021-10-17 11-30-22

You’ll notice it did not report none as the result, plus it generated a warning message:

Logger: homeassistant.helpers.template
Source: helpers/template.py:1210
First occurred: 11:29:22 (1 occurrences)
Last logged: 11:29:22

Template warning: ‘round’ got invalid input ‘junk’ when compiling template ‘value_template: > {{‘junk’|round(0,none)}}’ but no default was specified. Currently ‘round’ will return ‘junk’, however this template will fail to render in Home Assistant core 2021.12

It will report none if defined like this:

Screenshot from 2021-10-17 11-33-51

Or if all three parameters are supplied like this:
Screenshot from 2021-10-17 11-35-18

no warnings on

{{(states('sensor.zp_actuele_opbrengst')|float(0) -
            states('sensor.netto_verbruik')|float(0))|round(2,none)}}

or

{{expand('sensor.zp_actuele_opbrengst','sensor.netto_verbruik')
             |map(attribute='state')|rejectattr('state','in',['unknown','unavailable'])
             |map('float',0)|sum|round(2,none)}}

or even without any default:

      - unique_id: intercom_volume
        name: Intercom volume
        state: >
           {{states('input_number.intercom_volume')|float|round(2)}}

Petro, do I read your post correctly, that when I use round(2,none) it will work ok, defaulting to an unavailable entity, and, when I need to have it show an actual value like ‘Not yet set’ it needs to be the 3 argument, or, use the default= construction?

No warnings because round was supplied with a value it was able to convert.

1 Like

warnings will only appear if it fails to round

1 Like

ok, I see, that makes sense :wink:

you can omit defaults in places that ensure no text-to-xyz conversions happen.

I’m running the dev build and I have a ton of | int without bothering to supply a default because I know they will always be a number that is being converted.

1 Like

They have overridden some of the standard filters. For example, this PR mentions how it overrides the behavior of int

According to the docs I found on jinja both the float and int have defaults set. Not understanding the pr you referenced ? Maybe the jinja docs don’t match the code? Trying to find the correct document to follow is not easy. The template editor in HA references the jinja docs not any HA doc or any PRs.

Override means replaced. There is no default for float. It was 0. Same for int in 2021.11 when it comes out.

Not according to the documents linked in the template editor.

float(value, default=0.0)¶
Convert the value into a floating point number. If the conversion doesn’t work it will return 0.0. You can override this default using the first parameter.

Yes and if you don’t provide a default it will warning and return zero. Again, that’s changing in December and it will error. Meaning no default, this is what the breaking change is.

Not trying to be argumentative but I am not following this at all. According to the jinja docs that are still linked in HA there is a default value for the float and int. I quoted the float above. The default says 0.0. I guess you are saying that the October release rewrote the jinja filter and it removed the default values or I don’t understand what default means in the doc? Not sure why this would be changed? Hopefully someone can change the document linked to the correct information.

This is covered between the breaking changes and the HA template documentation, not the jinja documentation.

You are saying a user can find this? A new user going to template editor see the document linked there. There is no way for that user to know about a breaking change.
The template docs say:

We will not go over the basics of the syntax, as Jinja2 does a great job of this in their templates documentation.

Maybe the breaking changes should say the default values have been removed and a user needs to add them manually?

The defaults haven’t been removed yet… again it will produce an error, which means it won’t resolve and you won’t get an answer. It’s like the default is removed. There’s no mention of that because it hasn’t happened yet. The breaking change tells you what to do, add a default. So add a default. It’s zero for int and float. That was covered in the jinja docs, but again we are in the midst of the change.

Here’s the current relative docs:

edit
forget this…
it might have been was a template dev tools error
my pardon