How Device Sentinel Learns

How Device Sentinel Learns

The feature underneath everything: each home's devices are learned individually. No fixed timeout exists anywhere in Device Sentinel, because no fixed timeout can be right for both a motion sensor that speaks every 30 seconds and a water meter that speaks twice a day.

Watching

Device Sentinel listens passively to Home Assistant's event bus. Every time any entity of a device reports, that device's clock is stamped. Statistics are kept per device, not per entity: any entity's activity proves the device alive.

Service entries, cloud connections, and other devices with no hardware behind them are classified out automatically and never watched. That is the Service Devices Ignored count on the device page.

Learning the rhythm

For each device, each day, Device Sentinel records the longest quiet gap: the worst silence that still turned out to be normal. Those daily maxima build a rolling two-week picture.

The device's rhythm is the trimmed maximum of that window: the single worst day is set aside as a suspected anomaly, and the rhythm is the worst of what remains. One bad day, a Zigbee hiccup or an hour of WiFi trouble, moves nothing. A spike that repeats survives the trim and correctly widens the rhythm, because a device that genuinely got slower should be learned as slower.

Only completed gaps are learned. A device that goes silent and stays silent never finishes its gap, so a freeze can never teach the system that freezing is normal.

Arming

A device is judged for freeze only after it has enough learned days to have a trustworthy rhythm (the Devices Learned count). Before that, it is judged only for going unavailable, which needs no rhythm. Each device arms itself individually; there is no global learning mode, and a device added a year from now starts learning the day it arrives without anything being switched.

Devices with no natural heartbeat, buttons and remotes that speak only when used, never establish a rhythm and are never judged frozen. This is by design and is why Devices Learned is not expected to reach Devices Watched.

Knowing when a device actually spoke

Restarts, integration reloads, and radio reconnects all produce bursts of traffic that look like devices reporting when nothing has been heard from them. A Zigbee bridge coming back publishes every device's last known state. Home Assistant starting up re-reads whatever it can. Treating any of that as a device speaking would erase the silence behind it, which is exactly the silence worth noticing.

So Device Sentinel asks a better question than whether a message arrived. Many integrations publish a last-contact time, the coordinator's own record of when it genuinely last heard from a device. Where that exists, it is the clock. A replayed message carries the old reading, so it cannot advance anything, and the silence keeps running until the device actually says something. A device whose last-contact entity is itself unavailable is treated as not heard from, which is precisely the state a stuck device sits in.

Where an integration publishes no such time, the moment a report arrives is the only evidence there is, and it counts. That includes the report a device makes when the system restarts. A nightly restart is part of a home's rhythm rather than interference to filter out, and treating it as interference had a cost worth naming: a device that is simply quiet overnight ended up with an idea of normal that covered only the hours after the restart, and was then reported for being quiet during the hours before it.

One kind of gap is still set aside. A silence that spans a period when the device was unavailable covers time that genuinely could not be observed, so it teaches nothing.

Everything survives restarts. The learned statistics, every device's clock, and any flag in progress are stored on disk: a device twenty hours into a freeze is still twenty hours frozen after a reboot.