There is a failure every Home Assistant user eventually encounters and few see coming: a sensor that stops updating but keeps showing its last value. It does not go unavailable. It does not throw an error. It just quietly freezes, and every automation downstream keeps acting on a reading that stopped being true hours ago.
Entity Sentinel catches the freeze hiding in plain sight, and the ordinary offline, unknown, missing failures too. Entity Sentinel watches the entities you name and flags them all: unavailable, unknown, missing, and the frozen ones nothing else sees. It publishes a clean list of exactly what went quiet and for how long, ready to notify on, display, or speak.
Ready to set it up? The Entity Sentinel README has the full walkthrough, from the ready-to-paste snippet to choosing the right freeze window for each kind of device.
What You Get
- It catches frozen sensors no ordinary check can find. It flags the sensor that has stopped reporting while still showing a value, the failure that passes every check you would think to write.
- It catches unavailable, unknown, missing, and never-reported entities in the same pass.
- It won’t false-alarm on a device that’s still alive. You name the entities to watch, and it checks the whole device for signs of life, so a quiet entity is never flagged as frozen while another entity on the same device is still reporting.
- It knows a sleepy sensor from a stuck one. A device that only checks in once a day is given room to do exactly that, so its normal long silences are never mistaken for a freeze.
- It survives restarts and power outages. The sensor comes back without crying wolf over everything that was briefly offline during the reboot.
- It watches only what you want. The list stays quiet unless something you actually care about has stopped reporting.
- It tells you what and for how long, not just a count. Each flagged entity comes with the reason it tripped, unavailable, unknown, missing, or frozen, and how long it has been silent.
A Sensor You Build On, Not an Alarm
Entity Sentinel is the sister of Battery Sentinel. Battery Sentinel answers “What batteries are running low.” Entity Sentinel answers the harder question, “What entities have stopped reporting.” Like its sister, it is a template sensor, not a notification automation: it reports, it does not alert. An automation fires once and its result is gone; a sensor persists, so once it exists, anything in your configuration can read it. Alerting, dashboards, automations, you build whatever you want on top.
Import
Before you import, read the Entity Sentinel README. Entity Sentinel is a template blueprint, not an automation blueprint: after import it will not appear in your automations list and there is no Create button. It becomes a sensor through a short piece of YAML, and the README has the ready-to-paste snippet and the full setup.
Or paste this URL into Settings, Automations & Scenes, Blueprints, Import Blueprint:
https://raw.githubusercontent.com/TheThinkingHome/Automations/main/blueprints/template/entity_sentinel.yaml
One Sensor, Many Consumers
Once the sensor exists, anything can read it. One reader is already published:
Sentinel Notify turns the sensor into a live to-do list and change-aware notifications: every entity gone quiet becomes an item on the list, by name, with the reason and how long it has been open, and your phone hears only about what is new, never again about the ones you already know. Check an item off to acknowledge it; a recovered entity quietly disappears. Read the Sentinel Notify README.
That is one consumer, not a separate product. The list is plain structured data, so you can just as easily gate an automation on it so a stale reading never drives an action, drive a health badge that reads zero when everything is reporting, or ask Assist what has dropped before you leave the house. Build your own consumer and it works the same way.
What the Sensor Looks Like
Open Developer Tools, States, and here is a sensor with one entity offline and one device frozen:
state: 2
ok: true
total_monitored: 14
unavailable_count: 1
frozen_count: 1
devices:
- name: Front Door Lock
kind: entity
entity_id: lock.front_door
area: Entry
reason: unavailable
since: '2026-07-18T14:02:11+00:00'
age: 13 minutes
- name: Freezer Probe
kind: device
entity_id: sensor.freezer_temperature
area: Kitchen
reason: frozen
since: '2026-07-18T06:10:44+00:00'
age: 8 hours
sentinel_version: 2.4.0-beta
The state is the count. The devices list is the detail, and it follows one rule: one row per problem. A dead device appears once, under the device’s own name and marked kind: device, however many of its entities you watch; an entity that fails while its device still reports is its own row, marked kind: entity, because that is a different problem with a different fix. Each row carries the reason, when it started, and how long it has been silent, and the since timestamps hold their true values straight through Home Assistant restarts. That list is the thing every reader consumes, a notification formats it, a dashboard renders it, an automation gates on it.
Questions, bug reports, and use cases I didn’t think of are welcome here. Half the fun of this is seeing where other people aim it.
Version 2.4.0-beta, July 2026.
Changelog
2.4.0-beta: Device rows identify as devices: a collapsed row carries the device’s registered name, and every row carries kind (device or entity).
2.3.0-beta: One row per problem: a whole device unavailable appears once; an entity down while its device still reports stays its own row.
2.2.0-beta: Frozen reports once per device, and the list orders by area, then name.
2.1.1-beta: The scan_interval input is echoed as an attribute, so dashboards can display the check cadence.
2.1.0-beta: The device-truth freeze clock: freeze is judged from a device’s own last-seen record where one exists, so a restart or an integration re-publish cannot rewind it. Proven live: frozen flags held their true timestamps through nightly reboots.
2.0.0-beta: The tiered rebuild: one sensor holds up to five tiers, each with its own targets and freeze window, replacing the one-sensor-per-window pattern and its aggregator.
