Template sensor with numeric unit still crashes on `{{ none }}` – issue #93386 still relevant

[7wells]

Hi all,

this is a follow-up to GitHub issue #93386, which was closed in 2023 with the statement that template sensors with numeric expectation should return either a number or Python None.

While this makes sense in theory, it unfortunately doesn’t always work in practice – even with correct templates.

Problem summary

In recent HA versions (confirmed 2025.6.x), using {{ none }} in a template sensor with unit_of_measurement or device_class still leads to this error:

ValueError: could not convert string to float: 'None'

This happens because internally, {{ none }} sometimes gets converted to the string 'None', not Python NoneType, even though the template syntax is 100% correct.

Real-world impact

This breaks many use cases:

• optional numeric sensors (e.g. finance, energy, ratios)
• fallback logic based on availability of source data
• robust template-based analytics

Returning 0 instead is not acceptable in most cases (e.g. price or valuation calculations), and removing the unit altogether is not an option either.

Current workaround (not ideal):

{% if valid %}
  {{ value }}
{% endif %}

→ This avoids the error but suppresses the explicit fallback (none).
→ The sensor stays in unknown, but unintentionally.

Proposed solution

Home Assistant should:

1. Ensure that Jinja {{ none }} is always treated as Python None, not as the string 'None', even in numeric sensors with unit_of_measurement.
2. Apply stricter internal typing where needed (e.g. use is None checks instead of loose str() coercion).
3. Optionally: support an explicit mode like strict_numeric: true in template sensors to enforce clear numeric output (number or NoneType, no strings).

Question

Could the original GitHub issue be revisited or re-opened?
Or should we start a new issue with a formal reproducible case?

I am happy to provide real examples, logs and templates if needed.

Thank you!

Thank you for considering this and for maintaining an outstanding and powerful templating system.

This one detail is still a footgun, especially for users trying to do things the right way.

[tom_l]

The correct way to handle this is with the availability option. e.g. Why an availability template is important for energy template sensors

[7wells]

Thanks @tom_I – the availability: approach is definitely useful and helps avoiding the float(none) error in sensors with unit_of_measurement.

The underlying issue still remains: When a value_template returns none (even properly without quotes), HA internally treats it as a string, not as an actual Python None. This triggers a crash in any numeric sensor with a unit defined – even though one would expect the value to be ignored or marked unavailable.

It would be great if Home Assistant could properly handle none in numeric templates – or at least interpret it as None internally, so users don’t have to use availability: for every numeric template entity. Especially when partial input values are valid and we’d still want to compute or display fallback values.

Thanks again for pointing to the current best practice, especially if (since?) I have missed something!

[petro]

@7wells

This happens because internally, {{ none }} sometimes gets converted to the string 'None', not Python NoneType, even though the template syntax is 100% correct.

This is not correct. {{ none }} is always processed as a NoneType. The only way it’s processed as a string is if the returned value has quotations. I.e. the returned value is actually "None" not None or none.

@7wells

Ensure that Jinja {{ none }} is always treated as Python None, not as the string 'None', even in numeric sensors with unit_of_measurement.

This already happens, however None is typically interpreted as unknown in template entities, this is not always the case however there is a PR to add this to trigger based template sensors.

@7wells

Apply stricter internal typing where needed (e.g. use is None checks instead of loose str() coercion).

This makes no sense, this seems like you’re pulling this from AI.

@7wells

Optionally: support an explicit mode like strict_numeric: true in template sensors to enforce clear numeric output (number or NoneType, no strings).

The numeric state is handled upstream from template entities on the inheriting class. Meaning, there’s nothing we can do directly from the template integration.

@7wells

Could the original GitHub issue be revisited or re-opened?

No. I will not revisit this. Make proper templates. Your entire post appears to come from AI assumptions instead of real issues.

@7wells

Or should we start a new issue with a formal reproducible case?

At best, if the template entity returns the actual None object, the entity will be set unknown. I’d have to verify with the upstream lib that sensors can be set unknown in the first place.

[7wells]

Thanks @petro – I appreciate your reply.

Just to clarify: I do use GPT-based tools to help understand or phrase complex issues, especially in cases where I’m unsure whether something is a bug, a usage mistake, or a limitation of the system. I think that’s a fair approach for users trying to improve their setups and avoid unnecessary bug reports.

In this case, I’m happy to provide a concrete example – and I’d genuinely welcome any input that shows where my understanding may be wrong.

What makes me think this issue isn’t just user error:

A minimal sensor like this:

- sensor:
    - name: "Test Value"
      unique_id: test_value
      unit_of_measurement: "€"
      state: >
        {% set val = none %}
        {{ val }}

…triggers a config error like:

Invalid config for 'template': expected float for dictionary value @ data['state']

Even though {{ none }} should yield NoneType, Home Assistant still appears to consider this invalid in numeric sensors with a unit – rather than treating it as unknown.

While I understand the importance of using availability: in many situations, I believe it’s not always a practical solution.

For example, when combining multiple sources with fallback logic:

{% set ask = states('sensor.stock_ask') %}
{% set bid = states('sensor.stock_bid') %}
{% if ask not in ['unknown', 'unavailable', 'None', ''] and
      bid not in ['unknown', 'unavailable', 'None', ''] %}
  {{ ((ask | float(0)) + (bid | float(0))) / 2 }}
{% elif ask not in ['unknown', 'unavailable', 'None', ''] %}
  {{ ask }}
{% elif bid not in ['unknown', 'unavailable', 'None', ''] %}
  {{ bid }}
{% else %}
  {{ none }}
{% endif %}

Here, the fallback logic is already part of the value_template. Duplicating it in availability: would not only be error-prone, but also hard to maintain. Any update to the logic would have to be done in two places – with a risk of introducing inconsistencies.

That’s why I had suggested reviewing how None is handled internally in numeric contexts: it would be helpful if returning None could consistently yield a safe state (unknown) without breaking the config or requiring extra availability logic.

Again, I truly appreciate all the work going into Home Assistant and the input from experienced contributors here. If there’s something I misunderstood, I’d be genuinely grateful to learn more.

[petro]

Unfortunately, you’re not making your case here. An availability template that works with your large template would simply be:

availability: >
  {{ 'sensor.stock_ask' | has_value or 'sensor.stock_bid' | has_value }}

To be honest, your entire post really comes off as “I have a hammer to do this job, I must use the hammer”. When in reality, there are many other tools that do the job better.

Here is a template that does the same thing as your template above combined with an availability template.

state: >
  {{ ['sensor.stock_ask', 'sensor.stock_bid'] | select('has_value') | map("states") | map('float') | list | average }}
availability: >
  {{ 'sensor.stock_ask' | has_value or 'sensor.stock_bid' | has_value }}

And if you want to have a huge list of entities that does the same thing…

variables:
  my_entities:
  - sensor.a
  - sensor.b
  - sensor.c
state: >
  {{ my_entities | select('has_value') | map("states") | map('float') | list | average }}
availability: >
  {{ my_entities | select('has_value') | list | count > 0 }}

Any one of these options will not produce errors and does not return none to the sensor.

All easy to understand templates, no need to reuse sections of code. AI won’t know this because AI doesn’t really understand the system.

[7wells]

Thanks for taking the time, @petro – your example using has_value together with select and map('float') is extremely helpful. I hadn’t realized that this combination can both ensure safe numeric conversion and elegantly avoid unavailable values in a clean way.

I’m starting to see why this is preferred over returning none directly: it avoids ambiguous state handling and ensures the entity’s value remains valid for numeric use cases – especially when a unit_of_measurement is involved.

I also appreciate the suggestion with variables: for reusability – that’s a useful trick I hadn’t applied yet.

Admittedly, I’m still catching up on these best practices. I’ve been using GPT-based tools mostly to understand what’s going wrong when I encounter edge cases, not to shortcut the process. It’s helping me grow into the system, and your input here makes a real difference.

Out of curiosity: would you say the availability template should always be preferred over returning none – even in cases where we want to return partial or fallback values?

Thanks again – I’ll take your examples and refactor accordingly.