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.

Remembering and Judging Are Different Questions

Every verdict comes from the most recent two weeks. A device's rhythm is the trimmed maximum of the last fourteen daily gaps, and a signal floor is drawn from the last fourteen daily lows. That window is fixed and is not a setting, because a threshold that moved with a storage preference would mean two systems detecting differently for no reason anyone chose.

How much is kept is a separate question, and it is yours to answer on the Advanced screen. History is kept far longer than two weeks because some things cannot be seen in a fortnight at all: a battery barely moves, a signal floor is still settling, and whether fourteen days is even the right window is a question that needs months of evidence to ask.

So the long record exists to be studied, and the short window does the deciding. Keeping a year of history detects exactly what keeping thirty days detects.

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 treated with care. A silence during which the device also read unavailable covers time that could not be observed. If the device was unavailable only briefly, a passing mesh hiccup, the silence around it is real and is learned. If it was unavailable long enough that its return looks less like recovery and more like someone having fixed it, replaced a battery, re-paired it, power-cycled it, the gap is set aside, because a hand-fixed outage should not teach the device that being gone for hours is normal. The integration cannot see a hand on a device, so the length of the unavailable stretch is the only thing that separates the two, and where that line sits is the blip tolerance on the Advanced screen.

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.