Home Assistant Entity Availability and Error Monitoring

Helge's Tools
Published Jul 5, 2026

If you know a bit about my professional past (hint), you may have wondered when something like this would be coming. As for me, I was baffled to find that Home Assistant has no entity monitoring capabilities whatsoever. Nor do many third-party solutions seem to exist. This is all the more astonishing because the desire to be informed when things break should be a strong one among smart-home owners.

Confronted with this lack of functionality (and motivated by a recent heat pump failure), I decided to build my own. Unlike my cover automation, I didn’t want to create an integration. Instead, I felt that a basic capability like monitoring should rely only on what the platform natively offers, without external dependencies, so I focused on long-term stability as well as flexibility, low maintenance, and easy extensibility. Combining these seemingly contradictory requirements proved to be an interesting journey during which I learned many cool new tricks. The result exceeded my expectations. I’m sharing it as open source in the hope that others may benefit from it.

Features

Uses only native Home Assistant functionality plus a Python code generation script (required only when making changes)
Clear separation of (private) configuration and (public) code
Monitoring modes:
- Entity availability
- Entity error states
Monitors almost any type of entity through user-created template sensors that define what counts as error or unavailable and specify user-friendly names for the UI
Notifications via:
- Home Assistant persistent notifications that show up in the UI until dismissed
- Mobile and 3rd-party notifications via HA notification groups
Multi-language support for end-user-facing messages

High-Level Architecture

Code Generation Script

The above features cannot be implemented generically with what’s available in the Home Assistant platform, so I settled for the next-best thing: code generation. The actual Home Assistant automation configuration with its triggers and actions is created by a Python script from two sources: your list of monitored entities combined with the project’s monitoring code.

Entity Abstraction Layer

(Nearly) any kind of entity can be monitored. This is made possible by adding an entity abstraction layer, where the user specifies what is to be monitored and how entity states should be interpreted. Since we already have this abstraction, we’re using it to define user-friendly names for the notifications that are sent to mobile devices and show up in the Home Assistant UI, too.

Automations

The actual monitoring logic is deceptively simple: Home Assistant automations watch the user-defined monitoring entities that represent and abstract the actual entities whose status you want to know about. When one of these monitoring entities changes to an error state, the automation triggers notifications. When the state changes back to an OK state, the notifications are dismissed.

Scripts

Notifications are sent through Home Assistant scripts that perform two actions: create a persistent notification that shows up in the Notifications area of the Home Assistant UI, as well as send notifications via the built-in notifications integration. The latter natively supports mobile notifications via the Home Assistant companion app, but also many other targets via third-party integrations.

Interesting Points

Notifications and Alerts

Alerts

I didn’t use Home Assistant alerts because they’re built around the concept of repeatedly sending the same notification, which I find not to be helpful at all. These repeated notifications stack up in the Home Assistant UI and on your phone, reducing visibility and creating alert fatigue.

UI and Mobile Notifications

Apparently, there’s no single command to send a notification to the UI and to mobile devices. That’s why I’m using scripts to make the two necessary calls. Using scripts also has the advantage that we can use parameters, which makes the code cleaner and easier to understand.

Notification Groups

Mobile notification targets should be specified as notify groups. That gives you a single point of management who receives what.

Sending and Clearing Mobile Notifications

Mobile notifications can be sent and cleared (canceled/deleted) as follows.

Send:

- action: "notify.{{ notify_group }}"
  data:
    title: "{{ title }}"
    message: "{{ mobile_message }}"
    data:
      tag: "{{ notification_id }}"
      channel: "{{ channel }}"

Clear:

- action: "notify.{{ notify_group }}"
  data:
    message: "clear_notification"
    data:
      tag: "{{ notification_id }}"

Notes:

The channel is used on Android to manage notification behavior. It’s user-visible and should not be cryptic.
The tag correlates the sending and clearing commands. It must not be too long or notifications won’t be sent at all.

Template Entity Unavailability

Properly mark template entities as unavailable through the availability key. Example:

- name: "Heat Pump: Availability"
  unique_id: heat_pump_availability
  availability: "{{ states(source_entity) != 'unavailable' }}"

YAML Anchors and Aliases Reduce Code Duplication

When defining multiple similar template entities, YAML anchors and aliases can help reduce code duplication.

Usage:

Store a YAML node under an anchor name by prepending the definition with &anchor_name
Reuse the stored anchor as an alias with *anchor_name

Example:

- name: "Heat Pump: Availability"
  unique_id: heat_pump_availability
  state: &availability_sensor_state >-
    {% set raw_value = states(source_entity) %}
    {% if raw_value in ['unknown', 'none'] %}
      {{ none }}
    {% else %}
      {{ true }}
    {% endif %}

- name: "Network Switch: Availability"
  unique_id: network_switch_availability
  state: *availability_sensor_state