Does anybody have a tip why this happens?
(if I remove the second line, the same Result type is shown)
Template results are always strings.
True, though the template editor itself does interpret the results. Which has lead to confusion in the past.
Try a template that just returns a number.
1 Like
What problem are you trying to solve?
I’m actually having another problem with a template sensor based on another sensor.
Have had this Template-editor problem (always listing Result type: string) for several years and just wondering if there is a connection.
My template sensor fetches attribute values from a integration sensor (Tibber), where I modify the values from the original sensor and write them as attributes in the new template-sensor.
The Template editor list the attribute values like this (i.e. same format for both):
But in the States window, they are shown differently:
Fetching values for the original sensor works fine i Apex-Charts, but not from the new sensor.
We’d need to see the code you use to modify the data.
Here’s what’s going on. The first sensor is actually a Python Dictionary (dict). When returning as a string in renders the data as a JSON string. In the states display it is rendering it as YAML. Since apex supports Dicts this works there.
In your sensors the underlying data type is a string which renders the same in both places.
So we’d need the template to return a Dict. I’m not sure if this is possible, but seeing how you are doing it would be a first step.
What do you have on line 2 and beyond? If I do the same I get “number”:
The complete template sensor:
- name: "Tibber prices adjusted"
unique_id: tibber_prices_adjusted
state: >-
{% if states.sensor.tibber_prices.state %}
{{states.sensor.tibber_prices.state}}
{% else %}
'Error'
{% endif %}
attributes:
today: >-
{% set factor = states('input_number.elprice_support_percent') | float %}
{% set limit = states('input_number.stromstotte_innslag_nok_inkl_mva') | float %}
{% set energytaxD = states('input_number.nettleie_energiledd_dag') | float %}
{% set energytaxN = states('input_number.nettleie_energiledd_natt') | float %}
{% set ns = namespace(output=[]) %}
{% for item in state_attr('sensor.tibber_prices', 'today') %}
{% if item['total'] > limit %}
{% set newprice = (item['total'] - (item['total'] - limit) * (factor / 100)) | round(4, default=0) %}
{% else %}
{% set newprice = item['total'] | round(4, default=0) %}
{% endif %}
{% if as_datetime(item['startsAt']).weekday() in [5, 6] %}
{% set newprice = (newprice + energytaxN) | round(4, default=0) %}
{% else %}
{% if 6 < as_datetime(item['startsAt']).hour < 22 %}
{% set newprice = (newprice + energytaxD) | round(4, default=0) %}
{% else %}
{% set newprice = (newprice + energytaxN) | round(4, default=0) %}
{% endif %}
{% endif %}
{% set ns.output = ns.output + [ { 'total': newprice, 'startsAt': item['startsAt']} ] %}
{% endfor %}
{{ ns.output }}
tomorrow: >-
{% set factor = states('input_number.elprice_support_percent') | float %}
{% set limit = states('input_number.stromstotte_innslag_nok_inkl_mva') | float %}
{% set energytaxD = states('input_number.nettleie_energiledd_dag') | float %}
{% set energytaxN = states('input_number.nettleie_energiledd_natt') | float %}
{% set ns = namespace(output=[]) %}
{% for item in state_attr('sensor.tibber_prices', 'tomorrow') %}
{% if item['total'] > limit %}
{% set newprice = (item['total'] - (item['total'] - limit) * (factor / 100)) | round(4, default=0) %}
{% else %}
{% set newprice = item['total'] | round(4, default=0) %}
{% endif %}
{% if as_datetime(item['startsAt']).weekday() in [5, 6] %}
{% set newprice = (newprice + energytaxN) | round(4, default=0) %}
{% else %}
{% if 6 < as_datetime(item['startsAt']).hour < 22 %}
{% set newprice = (newprice + energytaxD) | round(4, default=0) %}
{% else %}
{% set newprice = (newprice + energytaxN) | round(4, default=0) %}
{% endif %}
{% endif %}
{% set ns.output = ns.output + [ { 'total': newprice, 'startsAt': item['startsAt']} ] %}
{% endfor %}
{{ ns.output }}
icon: mdi:currency-usd
I haven’t had a chance to try this since I’m away from laptop. But I think some of elements in this thread may be applicable
Is your device set up to use a comma or a period as the decimal separator?
Does the template editor evaluate this as a number: {{ 0 }}
What about this: {{ 0,0 }}
I wonder if some commas in your template are being interpreted as decimal separators instead of list separators.
On the host, you mean? It’s running on a VM on ESXi, don’t think I’ve done any changes there, other than setting the country (Norway) and language (Eng).
{{ 0 }}
still gives result String.
I tried setting up a new VM with only the needed integration and helpers, and the template editor (and also the new sensor) works as expected there.
Looks like something might be wrong in the template engine or whatnot. It’s been 5 years, not looking forward to start over.
Found it!
configuration.yaml:
homeassistant:
...
#this bugger was the mother of all my problems..:
legacy_templates: true
...
Was in the (slow) process of setting up 5 years of work from scratch on a new VM, and added part by part testing every small change. Just saved myself a sh*tload of work 
1 Like
Thanks for sharing the solution. I don’t think I’ve ever seen that config option used before, or noticed it is in the documentation.
I definitely read about it three years ago though: https://www.home-assistant.io/blog/2020/10/28/release-117/#native-types-support-for-templates-beta
Shame I didn’t remember.
That’s a dusty old option. Like you said, it dates back to version 0.118 (November 2020) when native typing was introduced.
For those who weren’t using Home Assistant back in 2020, by setting legacy_templates to true users could choose to disable native typing and preserve the old method where templates report string values exclusively. It was meant to be a temporary solution; users could buy some time to review their templates, and making any necessary adjustments, before making the switchover to native typing.
It wasn’t meant to be used three years later …
Yeah… I wish it’d been taken out of the HA code at least a couple of years ago. The “future” will hopefully be here soon 
If only I had remember that I put it in there, to prevent potentially breaking some MQTT service, I think it was.
Oh, well, not a big deal. Glad the problem is gone and I don’t have a lot of boring work ahead.
Just ran into this. Was driving me crazy until I found out that in fact the editor is interpreting the result type in an unexpected way.