Would the division not keep creating a float, which Marco is now seeing?
I believe that, for integer division, one must use two slashes instead of the one, like ((time % 3600) // 60). Or just go back to converting it after .
Bringing my rant from here over here, to avoid pissing off nice people like @petro.
I want to understand something. The warning says: “this template will fail to render in Home Assistant core 2022.1”. Does this mean:
a. The template will give a warning/error in the logs and will not have a default value anymore
or
b. The system will refuse to start when it sees such a construct (w/o a default)
?
If a), then I don’t really see the reason for the warning, and I, for my part, won’t need to make any changes, because I don’t want to hide “default” assignments to zero.
If b), that is IMHO a very poor decision, because “fixing” this warning will hide actual bugs.
I still believe this change is not warranted and it’s been implemented as a workaround for a specific problem, but it will affect a lot of HA deployments out there.
the only reason I can see for the change is that there were some users who were getting erroneous results in their templates and had no idea it was happening or why.
I think I would have handled it differently if that was the case.
I think it would have been sufficient to maintain the default “defaults” but also log a warning/error that the template was forced to fall back to the default values.
that way it shows users where (and if) they made a mistake but also provides for using the built-in default if that was already sufficient for what someone needs without the need for extra coding or trying to figure out the complexities of which defaults are needed and the required syntax.
the “make it easy” mantra always seems to be undermined by these types of changes.
It will produce an error instead of a warning. If it happens at startup (likely) you’re entity won’t be created. If it happens randomly but the entity already exists (i.e. after startup), you’ll just get an error.
I have this template sensor with availability template:
template:
- sensor:
- name: Living TV Volume Level
unit_of_measurement: "%"
availability: >-
{{ state_attr("media_player.living_tv", "volume_level") not in
[None, unknown, 'none', 'unknown', 'unavailable'] }}
state: >
{{ (state_attr("media_player.living_tv", "volume_level") * 100)
| int }}
icon: >
{% set vol = states('sensor.living_tv_volume_level')
| int %}
{% set lvl = (( (vol-1) // (100/3) ) | int) + 1 %}
{% set icons = ['off','low','medium','high'] %}
{% if 0 <= lvl <= 3 %}
mdi:volume-{{ icons[lvl] }}
{% else %}
mdi:volume-{{ icons[1] }}
{% endif %}
The log shows this entry:
Logger: homeassistant.helpers.template
Source: helpers/template.py:1291
First occurred: 22:45:38 (5 occurrences)
Last logged: 22:45:53
...
Template warning: 'int' got invalid input 'unknown' when rendering template '{% set vol = states('sensor.living_tv_volume_level') | int %} {% set lvl = (( (vol-1) // (100/3) ) | int) + 1 %} {% set icons = ['off','low','medium','high'] %} {% if 0 <= lvl <= 3 %} mdi:volume-{{ icons[lvl] }} {% else %} mdi:volume-{{ icons[1] }} {% endif %}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
An availability template does not stop the state template from attempting to resolve. It just masks the result. I think there is a PR in progress to alter this behaviour. Either way your issue is with the icon template that this PR will not address. Just supply a default value for your use of |int in this template.
I’m 99% sure it already went through but it only affects state. Not the other templates. his icon template is causing the problem as that’s the only string to int conversion that will fail on startup. The others aren’t conversions that would result in a failure.
I’ve discovered that templating the icon attribute is also determined by the availability attribute. When attribute is False, the sensor state is ‘unavailable’, and the sensor icon is not templated. The icon attribute will not be set.
This is awesome, but had to be pointed out to me by someone else.
Perhaps melding this into the Official Docs AND melding your sample availability example into the related docs for that would be more helpful. (I had NO CLUE how to use that before this article)
No offense, I use the community pages here but I always look first at the official Docs and put more weight in what they say rather than random guessers. I do take what you say an a few others as 99.5% correct, but there are lots of other advise in here that, well, not so much… That’s why I look to the Official Docs first and would not have found this without Thanasis’s help. Wouldn’t have known to look…
I am getting an error when using a value template for an automation to control air conditioning. Hoping someone can help fix up my code It doesn’t specify the error, just says “error while processing template”.
Basically it triggers an automation when a temperature sensor goes above or below a certain value, in this case above 24 degrees.
The second argument for round is method. I.e. rounding to the floor, cieling, or just a normal round. You need to use round(0, default=0) if you don’t plan on providing a method for the round.
Also, if you provide a default for the round, you don’t need a default for the int.
.
though it might be luck this works considering this is comparing strings…
It doesn’t specify the error, just says “error while processing template”.