No idea; this situation is all new to me. I’m learning of its effects mostly from users of the Sonoff RF Bridge. Some use an automation and python_script I developed a long time ago that is now misbehaving due to strings being automatically converted to integers. I don’t know how to prevent these unsolicited type conversions.
EDIT
Short answer is you cannot prevent type conversions BUT, most of the time it proves to be an asset, not a liability.
The use-case I described in my previous post turned out to be a nothing-burger. The type conversion isn’t nearly as aggressive as I first presumed (mea culpa). As you can see below, the comma-delimited list of light names is handled as a string and not a list:
Where the type conversion appears to be most noticeable is when numeric values are involved. For example, this list of strings when run through join should produce a comma-delimited string. However, because the list items are detected to be numeric, they get converted to integers and the whole thing is preserved as a list.
That’s a very special use-case and I’ll hazard a guess that the average user is not likely to encounter it in normal usage.
All this to say, once its peculiarities are understood, it’s not too difficult to accommodate them. However, I’ll temper my statement by saying I haven’t explored all its possible implications; there may be use-cases where automatic type conversion by inference does indeed complicate things. Time will tell.
With update from 0.117.6 to 0.118.2 I’ve lost all my lovelace cards. I’m using lovelace via yaml config file and I only get an empty page when openning my views. I also have that error:
22/11/2020 à 14:39:00 ERROR ERROR SyntaxError: invalid regexp group
URL: https://192.168.xx.xx:8123/frontend_latest/chunk.36b0722b88395b178fa2.js
Line: 1, column: 36
Error: {}
Anybody can point me from where to check to solve that issue
OK
upon further digging and leaving it to run for few days… it appears that solaredge reporting is using UTC time rather than local time… as i can see values but way behind… as in … in night time … solar edge is reporting power export…
is there a way to fix the utc - local time discrepancy??? or have to wait for another release???
currently running 0.118.2
With the css flex settings during the last update, I can’t make the cards bigger in Inspector anymore wth a pixel edit. Does anyone know what to change or how to get around that? I have a 4K screen but the editor continues to be tiny, especially inside multiple vertical/horizonal. Does anyone know what I need to change in Inspector? I tried everything and it still knocks me down to max 845px for editor and preview no matter how many times or places I change it. My screen is quite a bit bigger.
I’d also like to disable that nonsense of the box jumping sizes constantly, which doing a pixel correction also fixed. Who on earth thought a code editor should change sizes while you’re using it?
Thanks for the new version. I am trying to update the core inside my hass.io running on raspberry pi 2 to no avail. The supervisor log says:
20-11-23 09:22:46 ERROR (SyncWorker_4) [supervisor.docker.interface] Can’t install homeassistant/raspberrypi2-homeassistant:0.118.2 → 404 Client Error: Not Found (“no such image: homeassistant/raspberrypi2-homeassistant:0.118.2: No such image: homeassistant/raspberrypi2-homeassistant:0.118.2”).
Am I missing something or is raspberry pi 2 not supported starting from this version?
Thanks for the update, guys. But I have a question about new templates. Some of my automation scripts refuse to work since update, and I can sum up the problem to this behavior:
Clear your cache and refresh your page. Chuck errors are usually unfixable for the users because it’s a bug in the code. Or it’s using cached code running with new code (more likely), which would be fixed when you clear the cache and refresh the page.
When the string contains what appears to be a number.
You may have noticed that it not only converted each numeric string to an integer, it also converted the entire comma-delimited string to a list.
This is the new behavior in 0.118 where it infers the type based on appearance. Given my limited experience with it so far, it tends to do this more noticeably with numeric strings. For example, it will leave {{ "a, b" }} as a string and not convert it to a list containing two items.
Isn’t this behaviour documented under The Breaking Changes - Templates, section of the 0.118.0 release blog?
You can temporarily turn this behaviour off by adding this to configuration yaml.
homeassistant:
legacy_templates: true
The Breaking Change in the blog is a duplicate of this on Github
I have read the ‘breaking changes’ before upgrading and did not find anything concerning in section “The following templates can be impacted by this”. Provided examples were also outside of my use cases.
Thanks for the information. I was not expecting this (meaning I was not expecting for something to look at my string literal and modify on it), hence my question. Little background on my use case: I was just passing a string of phone number(s) in certain format to an external service and now the content of data is affected. If I use country code format +XX with a phone number then the conversion to number takes place and ‘+’ is removed. If I use 00XX country code format, then there is no conversion and it stays as a string.
I will eventually create a solution for this on my end, but I am curious if is there a way to force a string to stay as a string?
I’ve yet to move to .118, so can’t test this for myself, but what do you get if you add a string filter? e.g. {{ "491111222333, 491111222333" | string }}
Given ‘I can’t say for certain’ as I’m sitting on 0.117.6 due to the datetime issue with input_datetimes - but I’d guess it turns the string, into a string, which then gets turned into a ‘list’ (of integers)
Based on the explanation given to me of how it works, no.
The template is treated like a ‘black box’. Regardless of what you do inside the curly braces, it only examines the output of the template and, based on its appearance, decides how to convert its type (or not convert it). It doesn’t inspect what goes on inside the template.
Where you can control a value’s type is in python_script, AppDaemon, and pyscript.
I used to think that would work (final filter is string, float, int, list, etc) until I learned how the type assignment actually works. See my previous post with the ‘black box’ analogy.
