This will probably fix it:
So yeah, you have to wait for the next release.
1 Like
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?
This error occurs often if free disk space is not enough.
Anyway the Pi 2 is not recommended to run Home Assistant on.
Thanks, it was indeed the case!
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:
Is this expected behavior? Why a string literal is not a string anymore?
Thanks 
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
Or have I misunderstood entirely?
only in 0.117 I thought
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?
Thanks
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.
Hmm…I’m really far from an expert in Python and Jinja templates, but aren’t there some really good reasons to prefer/use strings, at least on occasion (as in the @mrck’s case)? Not arguing with you, just wondering why there isn’t now (with .117 and .118) a deterministic way to guarantee that a template outputs a string?
1 Like
seems that updating this morning to 118.3 all the Tasmota (beta) devices are all unavailable and not usable within HA… they all work outside of it just fine
nothing in the logs about any problems either
I tried to add a suggestion to the PR before it was accepted to make the return type explicit and configurable by adding another option to the template (something like “return_type: string” or “return_type: list”) but it was summarily rejected out of hand because “only a few people will be affected by the change”. I guess that’s true but it really sucks when you are one of the few.
5 Likes
