I really like the idea of templates now returning the “correct” type, instead of always returning a string.
However, I have a lot of templates. Just so I know how much work I have ahead of me, I’m wondering what others have run into.
Specifically, what sort of things will this break? Will I end up with two different types in the database, making my Lovelace history cards look funny until the old values age out? How does this affect templates which have a unit_of_measurement specified? Anything else to watch out for?
Thanks, that gives me at least a little confidence. I also take the silence about this breaking change to be a sign that others aren’t seeing a lot of problems.
There’s alot of problems but they typically won’t be in the template xxx integrations. E.g. template switch, sensor, etc.
The issues are going to be with random services using templates in the service calls.
When you run into an issue, create a post. So far, i’ve ran across 3 issues from the forum related to this change. 2 of them are already fixed. The last one is political. Of the 2 that are fixed, 1 is already in 0.118.
What Petro said, the odds are higher of a problem appearing in templates used to make service calls. Especially if the data it passes is numeric.
Case in point, an automation that receives RF codes from the Sonoff RF Bridge. The RF codes are all strings. These strings are matched to keys in a dictionary to determine what action to take. In 0.118, if an RF code string is purely numeric, it automatically gets converted to an integer. That screws up attempts to match an integer, like 606734 to a string like '606734'.
In this particular case, the RF code is received by an automation (where numerical strings are converted to integers) and passed to a python_script. The simple fix was to have the python_script convert everything it receives to a string. You can do that in a python_script but not in an automation’s template.
Another way to solve the same problem would be to change the affected dictionary keys from string to integer. So if you receive 123456 it will match with a key like 123456 (as opposed to attempting to match to it’s string version '123456').
It all seems so simple now but I’ll be the first to admit that it was a frustrating experience for me to learn the how and why this was happening and what I could and could not do to remedy it.
Another example is a list of strings where each string is a number. Something like this:
{% set x = [ "1", "2", "3" ] %}
If you use the join(', ') filter to convert it to comma-delimited string, in all previous versions you would get a string like this:
1, 2, 3
In 0.118, it produces another list, not a string, where each item in the list is now an integer:
[ 1, 2, 3 ]
There’s another quirk that involves strings that appear to be numbers in scientific notation (exponential notation). It was supposedly fixed by a PR but someone recently reported encountering it yet again. An RF code could look like this 1A4C34 or 123E45. The latter looks like a number in scientific notation (123 to the power of 45) and so the system converts it into a very large number … so large that it reports an error.
Clearly, there have been some teething pains and I imagine, as more users exercise the new feature, other quirks will be discovered and reported.
EDIT
Here’s a recent example of someone encountering numeric string to integer conversion:
EDIT
Corrected typo. Wrote 123455 when it should have been 123456.
I have a bunch of automations which use templates in conditions and in actions. Mostly I’m checking dates (like, 1st day of the month) in the condition, and outputting dates as part of one line in a log file (heat zone one came on, etc.)
Those template-generated strings are sent to to the notify service.
Should I be worried? Some of these, like the ones which only trigger on the first of the month, will take a while before I’d notice a problem. I’d hate to lose all the data between now and then.
Update: All the automations which have run so far are working fine. The dates and other values are appearing in the log files as before. The automations which run in the early morning (based on a template in the condition which evaluated a date/time value) worked, and again output the correct data.
The only one I’m still worried about is the one which runs on the first of the month, again based on a template in the condition. I’ll know by this time next week if that’s working, but so far it looks promising.
But you are buggered if the “string” it was to match to is (say) 01234 unless you remove leading 0’s, it’s an extra layer of checks (this one a manual one when you enter the match value)
Not come accross it, and don’t expect to but …
