Thi gets my goat. Watching a video is (IMHO) not a way to get update info.
Rant over.
3 Likes
The update info is in the blog, like usual. The video is just them talking about each change, discussing what lead to the changes, and how it impacts the update process. If youâre not willing to put in the time to watch it, thatâs fine, no one is forcing you. However, if you want to know that info, watch the video. No point in making speculationsâŚ
Whatâs unmentioned in the video is that, in previous versions, you could also specify a default for float. For example, this reports -1 in 2021.9.7.
{{ 'foo' | float(-1) }}
The main difference in older versions is that if no default is supplied it reports 0 (for a value it cannot convert). Thatâs no longer true; starting with 2021.10.0, thereâs no implicit default value and you must explicitly specify it.
EDIT
To clarify, if you overlook to specify a default value in 2021.10.0, and float is unable to convert the value, it will report 0 just like in previous versions but will also post a warning message. It will become an error message in 2021.12.0. All this to say, start adding a default for the listed functions now to avoid errors in the future.
My logs were overwhelmed with warnings and errors due to this change. So it wasnât an option to put it off. The change was painful, but it is done; until the next one.
Thanks for queuing up the video and sharing. However, it is clear that there was a ton of energy expended in order to provide a very very very tiny improvement. With the added âbonusâ of having much more verbose templates. The default, default was just fine me.
What were the error messages? This change only generates a warning message. It will become an error message in the December release.
I fixed them all and I am old and donât remember. IIRC, it was downstream when the template updated (every time it updated btw, so typically every minute there was a batch of goo in my logs)
If you are truly interested, I suppose I could break things again and report back.
Iâm only interested to the extent that the changes discussed in this topic only report warnings for missing default values. They donât report them as errors and the functions continue to work the same way as they did in the past even without an explicitly specified default. It wonât be an error message until the December release.
So if you encountered a situation today where it does cause an error message, then thatâs significant. However, if you canât recall the specifics then itâs hearsay until more information is available.
1 Like
Recall, or not, it isnât hearsay, but I certainly do get and appreciate your point.
In any case, following the instructions for changes eliminates any warnings/errors in my config. While I donât think the changes were worth the effort, that is just my opinion and since I donât have the benefit of understanding the bigger picture of where it is headed in the long run it is not worth much. As I use templates extensively in my config, it was a lot of tedious changes to get back in spec, cursing under my breath the entire time. So you get my opinion free of charge if only for my own benefit.
I am a huge fan of HA in general, and so will leave it at that.
BTW, I did go recreate the conditions. It was not the template change per se that caused the errors. It was a condition that previously returned a value of âunknownâ, that now returns an error. While benign, it was something I should have been trapping and handling better anyway. I suppose that is what they were going for when they decided to make the change. So there you go!
HA is already a huge time suck. I canât see myself spending additional hours watching a youtube video about the changes when I already spend the time to read the release notes.
OK, but what was the real âproblemâ?
While itâs not the best practice to use code that works âby accidentâ it still worked as the user desired or the user would have spent more time trying to figure out why it didnât. Why enforce âgood practicesâ on users when what we have works (for us)?
I really donât care if the template doesnât work right after start-up due to a missing sensor. if it continues to not work then Iâll look into it at that point.
How is forcing a user to manually add a default value to, for example, the float function a benefit when there already was a default default value added before. what does the user gain by being forced to add, for example, default=0 to a template that already contained that as default before?
Not to mention the added time suck of having to go thru every template adding a default value if one didnât exist before. Which almost none of mine currently do.
All of that saidâŚ
I thought that at first after reading the beginning of this thread that only the templates that were not valid at the point of rendering would complain about not having a default value specified if the template contained invalid values.
But reading some of the other threads I am seeing people saying that they need to add default values to all of their templates - even the ones working correctly (and not only ones working âby chanceâ 
) .
Which one is it?
2 Likes
8 posts were split to a new topic:
No longer hearsay because you have confirmed itâs not caused by the function changes. Those only report a warning message; the lack of an explicit default value isnât reported as an error message.
The problem is that previous versions allowed one to use functions with invisible defaults that could serve to mask mistakes.
In the near future, you will have to explicitly indicate the value to be reported in the event the function canât do its job properly (i.e. because it encounters an invalid value). Basically, it makes everything more visible as well as predictable when processing an anomalous value.
but if the template is returning expected results then itâs not a mistake. Itâs working as the user intended or they would have likely noticed and fixed it.
And the user has always had the ability to add their own default value if the default default showed incorrect results.
Again, where is the huge amount of issues occurring that this change was intended to resolve?
There are many other things that cause real issues for lots of people that need fixing before some fringe thing that no one is complaining about.
1 Like
The âexpected resultsâ are often a product of testing the template with âgoodâ values. Thereâs a bit of confirmation bias at work because the user exercises the template only with expected values.
Itâs when the unexpected occurs, the âedge-caseâ, that the invisible default is reported and the final result might deviate from the norm. Perhaps this edge-case occurs on startup or when a referenced entity becomes unavailable or unknown. Either way, the glitch is masked by the functionâs invisible default value thereby influencing the final result in a potentially unexpected manner.
Sure.
And in those cases I really donât mind helping.
I mean, thatâs why weâre here.
I think the end result will be as @chasut said and templates will become more complicated and less user friendly than they are even now.
Yeah same. The certificate integration hadnât rendered a value before the template was trying to get the number of days left by comparing a time stamp to now. I never even saw the template with an error and now thereâs a bunch of crap in the logs about it. Easily fixed but seems unnecessary.
3 Likes
I am interested, but I find this a difficult way to absorb this info. Most of my forum catch up time is in the evening with my laptop on the dining table while cooking etc. To put a video on is a PITA for me and the other family members.
I donât think I was speculating. No particular criticism of the release party, a lot of people get a lot out of it, but it is just not my style 
1 Like
I donât think changing float to float(0) is complicated but to each their own.
The real deal starts in December when warning messages become error messages and failing templates.
Going by how many people never read the logs, yeah this is going to be a thing.