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, so any entity's activity proves the device is alive.

Service entries, cloud connections, and other devices with no hardware behind them are classified out automatically and never watched. You will see these tallied as 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. This is deliberate: one bad day, like 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.

Completed gaps only: Only completed gaps are learned. A device that goes silent and stays silent never finishes its gap, meaning a freeze can never teach the system that freezing is normal. One exception runs in the safe direction: after a power cut, the silence a device had already accumulated before the lights went out is kept as a completed gap, marked truncated in the episode report. It is a lower bound on the true gap, so it can only move that day's figure toward the truth and never past it.

Bounded learning on recovery: What a gap may teach is also bounded if the device was flagged as frozen. A flagged device that suddenly speaks again might have recovered on its own, or it might have been fixed by a hand the integration cannot see. To prevent one mysterious resurrection from widening a freeze window for a fortnight, its gap is learned at most as the rhythm plus a modest allowance, generous for fast devices, small for slow ones. A genuinely slowed device will still teach its new pace within a few detections, but an outlier cannot ruin the statistics. The episode report marks when this happens with a capped label; see The Reports for the vocabulary.

Arming

A device is judged for a freeze only after it has enough learned days to have a trustworthy rhythm, shown in the Devices Learned count. Before that, it is judged only for going unavailable, which needs no rhythm to catch.

Each device arms itself individually; there is no global learning mode. A device added a year from now starts learning the day it arrives without you needing to switch anything. Devices with no natural heartbeat, like buttons and remotes that speak only when pressed, never establish a rhythm and are effectively never judged frozen. This is by design, and it is why your Devices Learned count is not expected to reach your Devices Watched count.

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. This is because a threshold that moved with a storage preference would mean two identical systems detecting differently for no reason anyone actually chose.

How much history is kept is a separate question entirely, 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 takes a season to settle, and determining if fourteen days is even the right judging window requires months of evidence to study. The long record exists to be studied, but 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 actually been heard from them. A Zigbee bridge coming back online 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.

The protocol clock: Device Sentinel asks a better question than whether a message arrived. Many integrations publish a last-contact time, which is 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 speaks. 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.

When there is no clock: Where an integration publishes no such time, the moment a report arrives is the only evidence there is, and it counts. This 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. Treating it as interference had a real cost: 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 falsely reported for being quiet during the hours before it.

Storm detection: For devices without a protocol clock, replay bursts are still caught a direct way. When one integration's devices all report in the same instant, the burst is recognized as a storm, and its stamps are excluded from learning so an integration reload cannot teach a false rhythm.

Time Nothing Was Listening

Time when nothing was listening is never counted against a device. The stretch before a restart, when the integration was not running, is credited to every device rather than held against it. A startup grace also sets aside silences already running across the first moments of a new session, so a restart can never convert an unobserved stretch into a lesson.

Gaps Treated with Care

Some silences cover time that could not be reliably observed or judged, and are set aside from learning:

• Unavailable stretches: If a 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 a recovery and more like someone fixing it, replacing a battery, re-pairing, power-cycling, the gap is set aside. A hand-fixed outage should not teach the device that being gone for hours is normal. Because the integration cannot see a hand on a device, the length of the unavailable stretch is the only thing that separates the two. Where that line sits is the blip tolerance on the Advanced screen.
• Coordinator outages: A silence spanning a coordinator outage that ended with the bridge reconnecting is set aside, because the gap measures the outage, not the device's rhythm.
• Pairing windows: A gap ending during a Zigbee pairing window is set aside as a manual re-pair.

The episode report records each of these set-asides with its specific reason. See The Reports for how to read them.

Persistence

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