Add `exception` handling to template sensors

Feature Requests
1

Problem
When Home Assistant starts, some of my template sensors fail with errors like:

TemplateError('TypeError: unsupported operand type(s) for -: 'NoneType' and 'NoneType'')

This happens because referenced sensors (e.g., sensor.a, sensor.b) are temporarily unknown or unavailable. While it’s technically possible to provide default values in the template, I prefer not to compute results based on fake or placeholder data. I’d rather detect the issue and return a controlled fallback state instead.

Proposed Solution
Introduce an optional exception block for template sensors. This block would only execute if the main state template throws an exception. For example:

template:
  - sensor:
      - name: "My Sensor"
        state: >
          {{ states('sensor.a') | float - states('sensor.b') | float }}
        attributes:
          unit_of_measurement: "kWh"
        exception:
          state: "unknown"
          attributes:
            error: "{{ error }}"
            missing_sensor: "sensor.a"

This would allow:

  • Clean handling of startup conditions or missing data
  • Easier debugging by surfacing what caused the failure
  • Avoiding the use of misleading default values

Why This Matters
Handling unavailable or NoneType states is currently clunky and hard to manage cleanly in templates. A built-in exception handler would make templates more robust, especially during startup or network issues.

Related Discussion
How to handle unknown or unavailable states in templates

2

This already happens. It just produces an error in the logs so the yaml isn’t needed. If you want the error out of your logs, use logger to remove it. The state that’s produced when an exception appears is unavailable.

Secondly, the availability template was built for these purposes. In your example this is all you’d need:

template:
  - sensor:
      - name: "My Sensor"
        state: >
          {{ states('sensor.a') | float - states('sensor.b') | float }}
        attributes:
          unit_of_measurement: "kWh"
        availability: >
          {{ 'sensor.a' | has_value }}

Much less verbose than what you’re proposing here and it has full control via templates to produce any result you’d like.

TLDR: It’s very unlikely that I add this FR.

3 Likes
3

Thanks for the reply! I see what you mean regarding availability and logging behavior — and I agree it works well for many use cases. That said, I’d like to clarify a slightly different angle I’m proposing:

  • availability controls whether the entity is available at all — which effectively hides the state and shows it as unavailable.
  • My request is more about gracefully surfacing context in the state or attributes, rather than simply hiding the sensor or suppressing logs.

For example, I’d like to show:

  • state: "unknown" or some other placeholder or smart default value
  • additionally I could show some custom attribute values on error or set attributes differently on error. Or just show the exception details.

All this without having to duplicate error-checking logic inside the main state or availability template.

So while I understand if this doesn’t align with HA’s architecture philosophy, I think the feature could help make template sensors more robust, more self-explanatory and easier to debug — especially for users less familiar with Jinja templating or error handling.

4

Already works this way.

If you use availability, the error doesn’t appear in the logs without duplicated trapping. If you don’t use availability, the error will appear in the logs and you’ll need to suppress it.

I.e. What you’re asking for already exists.

As for unknown, only some template entities can currently be set unknown. Provide None through your template and the entity will go unknown if it’s supported on that entity. I’ll slowly roll out unknown to all entities, but it will be breaking changes so it has to be rolled out slow.

1 Like
5

Thanks again for the detailed explanation — I appreciate the clarification on how availability and None behave, and it’s great to hear that support for unknown is expanding.

That said, I still believe there’s value in this feature (or something like it) to reduce repetition in more complex templates.

When a sensor relies on like 4–5 other sensors, the current approach requires duplicating availability checks (e.g., 'unknown', 'unavailable', None) both in the availability block and inside the state or attributes logic. This leads to a lot of boilerplate and fragile templates. Every time I add or change a dependency, I have to touch multiple sections to keep things in sync.

What I’m suggesting is not just about suppressing errors, but about centralizing exception handling in a clean and maintainable way. Ideally, a block like exception: could:

  • Catch template evaluation errors
  • Provide a fallback state
  • Populate useful diagnostic attributes (e.g., which sensor caused the failure)

Even if the current system can technically handle these situations, I think a feature like this would greatly improve the developer experience, especially for complex setups.

Thanks again for considering, and for all the great work on the templating engine!

6

How many times do I need to say “no” for you to understand that I’m saying no?

All you need to use is has_value. You do not need to check for any of those values, they are covered by has_value.

Availability will do that. The error will not appear at all because availability is resolved before state or attributes.

I completely understand what you’re asking. However you’re not understanding that this is all easily done inside the templates without the extremely complicated yaml you’re suggesting.

e.g. your proposal

template:
  - sensor:
      - name: "My Sensor"
        state: >
          {{ states('sensor.a') | float - states('sensor.b') | float }}
        attributes:
          unit_of_measurement: "kWh"
        exception:
          state: "unknown"
          attributes:
            error: "{{ error }}"
            missing_sensor: "sensor.a"

however what you can do now…

template:
  - sensor:
      - name: "My Sensor"
        state: >
          {% if 'sensor.a' | has_value %}
            {{ states('sensor.a') | float - states('sensor.b') | float }}
          {% else %}
            None
          {% endif %}
        attributes:
          unit_of_measurement: "kWh"

And if you want unavailable and unknown

template:
  - sensor:
      - name: "My Sensor"
        state: >
          {% if 'sensor.a' | has_value %}
            {{ states('sensor.a') | float - states('sensor.b') | float }}
          {% else %}
            None
          {% endif %}
        availability: >
          {{ 'sensor.a' | has_value and 'sensor.b' | has_value }}
        attributes:
          unit_of_measurement: "kWh"
1 Like
7

Just clarifying to make sure my own comprehension isn’t lacking.

The template above could be written without the check in the state template because it will never be evaluated when sensor.a does not have a valid value due to the availability parameter.

- sensor:
    - name: "My Sensor"
      state: >
        {{ states('sensor.a') | float - states('sensor.b') | float }}
      availability: >
        {{ 'sensor.a' | has_value and 'sensor.b' | has_value }}
      attributes:
        unit_of_measurement: "kWh"
8

Correct. has_value makes sure the entity has a value that properly suits the entity passed to it. It essentially checks for all variations of bad states.

The resolution order for template entities is:

availability
state
icon, picture, name
all other attributes.

availability is the only one that blocks others from producing errors because availability blocks the other templates from resolving.

2 Likes
9

For what it’s worth, making the “availability” section more widely known, might be a huge help to people. I’ve been doing this about 3 months, have done some pretty complex templating, and this is the first I’ve heard of it. … and now i have to go and update all my templates :smiley:

10

I’d like to push it into the UI at some point, but I need approval from the core team.

3 Likes
11

I started trying to utilize availability more. Until at the sensor I had 7 dependencies that I would have to check “has_state” for each. It would be so much easier if I could write exception rescue block, where I could define “If something went wrong, set state to unavailable.”

12

Just check all entities in a list instead of with if statements.

{{ [ 'sensor.1', 'sensor.2', 'sensor.etc' ] | reject('has_value') | list | count == 0 }}
1 Like
13

Being that YML is a declarative language, it would seem that it would be a pretty good idea to support an array of sensor dependencies at that same level. Basically, a shorthand for what petro said.

  • sensor:
    • name: “My Sensor”
      dependencies:
      • sensor1
      • sensorN
14

The template system used to do that many years ago, until it got good enough to work them out automatically. Manually maintaining a dependency list will “rot” into a mess — just use the availability template and has_value tests in each dependant template.

3 Likes
15

At most, the only thing I’d be willing to add is an option for automatic availability without needing a template. I will not be adding a convoluted yaml mess that describes entity behavior when things have exceptions. On top of that, I’m 99% sure the core team wouldn’t even allow that.

2 Likes
16

fair. just spitballing some ideas, in that it’s a lot easier to read declarative style lists, than it is to pick them all out of code that may or may not be particularly legible :smiley: