That’s what this is, it’s a guide to help you update those. The example you posted only has 1 of 7 ints with a default. You have to do this on every int.
Just checking here, is this an HA requirement to specify a default value? The Jinja docs seem to suggest that the default is already there (or else I have missed something obvious in this).
https://jinja.palletsprojects.com/en/latest/templates/#jinja-filters.int
I have just realised this is going to be mandated in 2021.12 - I think a more visible of warning of this should be added to the update message 
[edit]
@petro this explanation is excellent - really should be part of core Template docs.
It is. A good rule of thumb to know when it’s actually needed is:
Are you converting a state (Not state attr) to an int or float? If yes, it will need a default. Otherwise, the need is a case by case basis.
Thanks.
I think that as the Template editor points to the Jinja documentation (plus the HA documents) that perhaps this requirement for a default for certain filters could do with being emphasised.
I also note point 4 of the HA docs, that I think is now incorrect (if I have understood correctly).
If I was coming into this blind, I’m not sure this HA requirement for a default is adequately explained especially as the Jinja docs say it is not required as it has a default.
No this is specifically referring to items that are defined or undefined. If you have an object with 3 properties a, b, and c, but you try to access d. E.g.
{{ myitem.a }} # a is defined
{{ myitem.b }} # b is defined
{{ myitem.c }} # c is defined
{{ myitem.d }} # d is not defined, int or float will not return a default for this, the template will error.
So does the documentation need a point 5 along the lines of;
“The following filters must all be supplied with a default value …”
to help users?
I note that most of the examples on that page do not have defaults 
If you want to update the examples with defaults go ahead, the blurbs about the filters themselves all specify if they need a default or not
Most things don’t have defaults btw, so that might be why you’re not seeing it.
The defaults are pretty much only for converting to numbers. In this section of the docs
Sorry to be thick, but which blurb? The Jinja docs say the defaults are pre-specified.
Don’t have or don’t need?
So now I am even more confused as to when the defaults are required 
Click the link I posted. It literally lists out what functions require defaults. Stop reading the Jinja docs. Read the HA docs I posted.
1 Like
If those docs do not list a default, then the function / method does not require it. You’re making this more complicated than it is.
Function definitions are defined in the docs, this whole post describes how to read and understand the function definitions provided in the docs.
@petro thanks for your patience. Part of my point is that the docs really are not clear and that generates questions and confusion. However, I do know how difficult it is to write documents when you completely understand the subject.
I’m not trying to be difficult, I’m trying to understand and help other by possibly improving the documentation
Ok, but they are the documents linked to in the first 4 point note I posted earlier - perhaps that needs to be revised. The fact they are linked to early, implies they are the starting point (in the Template Editor is listed first). Perhaps that text on the Template editor needs revision to help users.
Is the text at the start of the note below still correct (or will it not be once 2021.12 is released?
I think the last part of this is now not correct (if omitted) - it is these sorts of conflicting messages that confuse users (me).
Please accept this is all done in good faith, I’m trying to point out the difficulties a new user is having with understanding what the documentation is trying to tell me. Good documentation is incredibly hard - I get that.
Yes I get that (and it’s the bit I understand, oddly) and I’d still say it therefore needs to be added to the docs - perhaps a link “Understanding Defaults”.
This is exactly how it behaves currently. The documents are always current. Remember, the log entry you are getting is a warning. Not an error. The warning even specifies that it will work currently but not in 2021.12. Then, it will be an error in 2021.12. We are not at 2021.12 yet.
I see how you could want this in the docs and I’m not against adding it. But everything in this post is basic coding information. Every code language uses this. At some point there needs to be a line in the sand. Are the HA docs expected to explain how math works? This falls into that grey area. That’s why I made a post about it.
1 Like
I accept that but if something is imminently being deprecated, the docs should be updated to state that and provide the information required to implement all new templates in a compliant way. As it stands, someone could implement the template the day before release completely ignorant of the changes about to happen.
Documentation should never promote methods about to be deprecated. They should always promote current best practice (with a nod to the past).
IMHO of course 
But those methods work depending on the situation. That’s the problem. I understand what you’re saying but this will never ever produce the warning and a default is not required.
{{ '1' | float }}
however this will
{{ states('sensor.xyz') | float }}
So even after 2021.12, there still will be cases where defaults are not needed.
EDIT: And these are just basic examples that also fall in the grey area of “Should HA cover this” because these are also standard in coding languages.
EDIT2: Converting a string representation of a number will always work. 100% of the time. A default will never be needed for that. A string representation of a number that sometimes has a alpha character in it will fail to convert, and that’s when the warning will be produced. Again, all of this is standard coding nuances.
1 Like
I had the exact same issue as you when I saw this in the beta. The issue is not that HA now requires a default the issue for me is that HA links to the Jinja docs that has a default value. Petro is very good at this (and very patient). He walked me through the changes with very good explainations. To find the docs it takes a lot of work to trace individual changes. I believe these changes caused unnecessary issues (and will cause more in Dec.) Again, I am not writing the code so they may indeed be necessary. Some of the functions were redefined in HA with different requirements and some new ones were added but the docs still link to Jinja.
1 Like
wow, this is hogging my system completely:
2021-11-28 16:35:47 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'unavailable' when rendering template 'Batteries below threshold:
{% set ikea = expand(integration_entities('192.168.1.99'))
|selectattr('domain','eq','sensor') %}
{% set hue1 = expand(integration_entities('Philips Hue 1'))
|selectattr('domain','eq','sensor') %}
{% set hue2 = expand(integration_entities('Philips Hue 2'))
|selectattr('domain','eq','sensor') %}
{% set count = 0 %} {% set alert_level = states('input_number.battery_alert_level')|int(default=0) %}
{% for b in expand(ikea, hue1, hue2)
if b.state not in ['unavailable','unknown'] and
if b.state|int < alert_level and
'illuminance' not in b.entity_id and 'temp' not in b.entity_id
and 'connect' not in b.entity_id%}
{{b.name}} {{b.state}}
{% endfor %}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
as a markdown card. Even though Ive added the default on the int, it somehow is not applied??
what is wrong here please?
You sure about that?