Indeed… Won’t work with timestamp_local(default=now()) == now(), though, so that one is not an option.
Probably, timestamp_local(default=0) == 0 will be the easiest.
Can you explain why the first test, using now(), not work but the second one will? Is it because there might be a few microseconds of difference between the two instances of now()?
Yes. now() will be evaluated at the time of invocation, then a second time at the time of comparison.
That’s theoretical, though. It might work, but isn’t safe anyway.
It would work if you set a variable as now
Ofc, but that starts to be a whole lot of coding and resources for a bloody useless default 
I’m trying to figure out what problem they are trying to solve with forcing users to add defaults to all the filters all of a sudden?
Templates have worked fine forever (of course there may be some edge cases - there is for everything) so why make everyone go thru the trouble now to add this to every filter template?
What’s the purpose?
1 Like
You should watch the release party sometime. You’ll get a firsthand peak into the reasoning being things, including this.
FWIW, I just helped someone who didn’t understand why they are now getting a warning for this:
'00:00' | timestamp_custom('%H:%S', False)
We both know that’s invalid. In previous versions, the function wasn’t getting what it needed so it quietly did nothing and passed along the string. Now it warns the user that this isn’t valid (it needs a timestamp, not a string) and, unless a default value is supplied, the December release will flag this as an error.
Unfortunately, the user didn’t understand the warning message and was confused by its presence because the template “worked before”. In this case, “worked” was by pure chance because the input was already in the desired output format (the timestamp_custom function isn’t even needed here)
That’s good, no question about it. But what will happen now is that users will just blindly paste some snippet with a default and forget about it.
The warning is gone, but the issue is still there, which basically solves nothing.
Also, the (currently) warning is pushed at each scan_interval.
That’s a pretty good incentive to fix those asap 
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