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?
darn… quite simply overlooked that… 
thought the issue might also have been that because of this, the system looped in unavailable devices/integrations. I had not guarded the if b.state not in ['unavailable','unknown'] which I now added too.
but, wait, yes, I had changed that. What I hadn’t done yet, was refresh the frontend! I ran into this before, with the template-entity-row card. Log showing an error, of a config version not yet updated/refreshed.
Ive refreshed now, the unavailable sensor has left the markdown, and I’ll restart the HA instance once more.
thanks for your keen eye.
I would like to hear how I can improve this sensor template, specifically the strptime's default in a meaningful way:
{% set reversed_file_list = state_attr('sensor.home_assistant', 'file_list') | sort(reverse=True) %}
{% set files_exist = (reversed_file_list | length) > 0 %}
{% if (files_exist) %}
{% set last_backup_dt = strptime(reversed_file_list[0] | regex_findall_index(find='\d{8}_\d{6}'), '%Y%m%d_%H%M%S') | as_local %}
{{ last_backup_dt.isoformat() }}
{% else %}
unknown
{% endif %}
I could set the default as 0 or None, but in either case it seems like I’ll have another if statement to check for that before trying to call isoformat on it. It seems cumbersome and I’m wondering how I can do this more cleanly.
I’ve read klogg’s post that seems related, but unanswered.
What a mess
Heheee
Please post a few examples of the values in file_contents so we can understand the data’s format.
@123 here you go. I’m extracting the datetime from the filename.
path: /mnt/nas/Backups/home_assistant/
filter: hass-config_*.zip
number_of_files: 136
bytes: 1286294837
file_list:
- /mnt/nas/Backups/home_assistant/hass-config_20210804_000500.zip
- /mnt/nas/Backups/home_assistant/hass-config_20210620_000500.zip
- /mnt/nas/Backups/home_assistant/hass-config_20200729_030001.zip
Copy-paste this into the Template Editor and see if it reports the desired result:
{% set f = state_attr('sensor.home_assistant', 'file_list') | sort(reverse=True) | first %}
{{ 'unknown' if f is not defined else (f[-19:-4].replace('_', ' ') | as_datetime).astimezone().isoformat() }}
2 Likes
Yeah, that works perfectly. Thank you. Avoiding the strptime completely – I didn’t think of that.
Hi, i have a warning error with this sensor template:
- platform: template
sensors:
apc2_time_remaining:
friendly_name: 'APC Scrivania Remaining'
value_template: >-
{% set time = (states.sensor.apc2_battery_runtime.state | int) | int %}
{% set minutes = ((time % 3600) / 60) | int %}
{% set hours = ((time % 86400) / 3600) | int %}
{% set days = (time / 86400) | int %}
{%- if time < 60 -%}
meno di un minuto
{%- else -%}
{%- if days > 0 -%}
{{ days }} d
{%- endif -%}
{%- if hours > 0 -%}
{%- if days > 0 -%}
{{ ' ' }}
{%- endif -%}
{{ hours }} h
{%- endif -%}
{%- if minutes > 0 -%}
{%- if days > 0 or hours > 0 -%}
{{ ' ' }}
{%- endif -%}
{{ minutes }} m
{%- endif -%}
{%- endif -%}
In log have this warning:
Logger: homeassistant.helpers.template
Source: helpers/template.py:1291
First occurred: 17 dicembre 2021, 19:44:10 (1 occurrences)
Last logged: 17 dicembre 2021, 19:44:10
Template warning: ‘int’ got invalid input ‘unavailable’ when rendering template ‘{% set time = (states.sensor.apc2_battery_runtime.state | int) | int %} {% set minutes = ((time % 3600) / 60) | int %} {% set hours = ((time % 86400) / 3600) | int %} {% set days = (time / 86400) | int %} {%- if time < 60 -%} meno di un minuto {%- else -%} {%- if days > 0 -%} {{ days }} d {%- endif -%} {%- if hours > 0 -%} {%- if days > 0 -%} {{ ’ ’ }} {%- endif -%} {{ hours }} h {%- endif -%} {%- if minutes > 0 -%} {%- if days > 0 or hours > 0 -%} {{ ’ ’ }} {%- endif -%} {{ minutes }} m {%- endif -%} {%- endif -%}’ but no default was specified. Currently ‘int’ will return ‘0’, however this template will fail to render in Home Assistant core 2022.1
how can i fix the template to make the error disappear?
Thanks