Core: Templates: Round is no longer honored on whole numbers. e.g. 1.0, 2.0, etc.

[Petro31]

The problem

Rounding is no longer honored as a result of the new template typing. All whole numbers will be truncated to an int.

ex:

{{ '1.1' | round(1) }} # returns 1.1
{{ '1.0' | round(1) }} # returns 1
{{ '1.1' | float | round(1) }} # returns 1.1
{{ '1.0' | float | round(1) }} # returns 1

After follwing the code in the forgiving_round method, it appears as if the bug is beyond that. I would assume that it's coming from the new template changes because the values that leave forgiving_round contain the floating point decimals.

Environment

• Home Assistant Core release with the issue: 0.118
• Last working Home Assistant Core release (if known): 0.116.4
• Operating environment (OS/Container/Supervised/Core): NA
• Integration causing this issue: template
• Link to integration documentation on our website: NA

[Petro31]

Even strongly formatting it fails

{{ "%0.1f" | format('1.0' | round(1)) }}

[frenck]

The result of the template is evaluated and considered an integer, which is as intended with the native template types.

[Petro31]

Yep I know that, just want to be clear: This is not desired from a user perspective. Users want their sensors to display the number of sig figs that they output.

[Petro31]

In all honesty, I hope this sparks UI changes that fix sigfigs. The backend shouldn't care about this and the display should be handled on the frontend. Maybe it's time for a global precision that can be adjusted per sensor numerical sensor.

[tdejneka]

I can't duplicate your results using 0.118.0. The '1.0 isn't represented as an integer (1) but as a float (1.0). I don't understand why it "works for me".

For good measure, I even set legacy_templates: false (even though this is the default in 0.118), restarted, and the results remain correct. I continue to get 1.0 where you indicate you get 1.

[Petro31]

@tdejneka because the template is returning more than 1 value. Only use 1 template with no comment and it will return the values I listed.

The template resolver tries to type the entire template. So when you have multiple returned values, it typically types it as a string.

[tdejneka]

when you have multiple returned values, it typically types it as a string.

Learned something new!

I can now confirm the problem you've reported:

... and the multi-line behavior:

[tdejneka]

I believe this may be a related example. I was recently struggling with a template in 0.118 that refused to respect a join(', ') filter. The result continues to be a list.

By adding another line in the Template Editor, boom!, now the join is respected and the result is a comma-delimited string:

[Petro31]

Yes, it's also screwing with the write to file integration. You can no longer write JSON to the file because it errors. There'll be endless bugs from this change.

[Mariusthvdb]

added to that, it makes the template editor an unreliable tool, which is really kind of disturbing.

[Petro31]

added to that, it makes the template editor an unreliable tool, which is really kind of disturbing.

No... it makes it reliable with template types. You should stop fighting this and learn what it’s doing.

[Mariusthvdb]

huh? you're telling me to stop fighting this and learn what its doing while your own words are:

Yes, it's also screwing with the write to file integration. You can no longer write JSON to the file because it errors. There'll be endless bugs from this change.

I'll stop, yet left utterly confused by your own conclusion.

[tdejneka]

My principle concern is what happens when I attempt to convert a list to a comma-delimited string using the join(', ') filter. Based on what the Template Editor reports, the join filter is ignored and the list remains a list.

The inability to convert a list to a comma-delimited string would represent a significant loss of functionality.

[Petro31]

huh? you're telling me to stop fighting this and learn what its doing while your own words are:

Yes, it's also screwing with the write to file integration. You can no longer write JSON to the file because it errors. There'll be endless bugs from this change.

I'll stop, yet left utterly confused by your own conclusion.

Are you kidding me? This is an issue with templates and I asked you to drop the stuff about the dev tools template editor.

[Petro31]

My principle concern is what happens when I attempt to convert a list to a comma-delimited string using the join(', ') filter. Based on what the Template Editor reports, the join filter is ignored and the list remains a list.

The inability to convert a list to a comma-delimited string would represent a significant loss of functionality.

I’m sure it will be fine in most cases and the issues will be fixed when we come across them.

[elupus]

@frenck after format() it should really be considered string. What causes it to become number after that?

[Petro31]

@elupus Template typing changes that occurred in .118

[elupus]

@Petro31 i'm aware of them. I understand why the original problem occurs. Just rounding a value doesn't change it's type (just python that happens to be funny about it and remember weird formatting). The type remains floating point, which have no notion of number of decimal digits.
However, formatting a value should be changing the type from number to str. Something causes it to remain a number, which is invalid.

[elupus]

So to fix format() we need to skip parsing the result here: https://github.com/home-assistant/core/blob/c157fbef1e88b3f34fe230fb153f362b7d187215/homeassistant/helpers/template.py#L364-L393 if the result was the output of a format() function. Not sure how to do that yet.

[balloob]

So things that use cv.string validator will be able to turn parsed objects into their original strings. But I am assuming this is used for a template sensor. In that case we should just register the state template to not parse the template after rendering it.

[frenck]

For the template sensor that could make sense, as the states are still strings in the end.