How Device Sentinel Learns

How Device Sentinel Learns

Device Sentinel relies on a single mechanical rule: devices have individual reporting rhythms. A fixed timeout fails across a diverse fleet because a motion sensor reporting every 30 seconds requires a completely different baseline than a door sensor checking in twice a day.

Watching

The integration monitors the Home Assistant event bus and when an entity reports, the system updates the parent device's clock. Tracking liveness at the device level means any sensor activity proves the underlying hardware is online.

The system ignores service integrations and cloud connections. These filtered items appear as the Service Devices Ignored count on the device page.

Learning the Rhythm

Device Sentinel records the daily longest normal quiet gap for each device. These daily maximums build a rolling two-week picture for every monitored device.

A device's rhythm is the trimmed maximum of that window. The system sets aside the single worst day as a suspected anomaly and uses the worst remaining gap. One bad day, such as a Zigbee hiccup or WiFi trouble, changes nothing. A repeating spike survives the trim and correctly widens the rhythm.

Completed gaps only: The system only learns from completed gaps. A device that goes silent and stays silent never finishes its gap. A freeze will never teach the system that freezing is normal behavior.

Arming

Devices arm individually without a global learning mode and after a 7-day learning window. A new device begins learning the moment it connects. Hardware lacking a heartbeat, such as push buttons, never establishes a rhythm and avoids freeze judgments entirely. Consequently, your Devices: Watched count will always exceed your Devices: Learned count.

Learning and Judging Are Different Questions

Each verdict relies on a specific recent window. The three detectors use different windows to measure different behaviors.

The freeze rhythm: Fourteen days. The reporting rhythm is the trimmed maximum of the last fourteen daily gaps. Testing on real fleets showed this length maintains accuracy while filtering out anomalies.

The signal floor: Thirty days. The floor is a trimmed minimum. A shorter window forgets true low points. Testing at fourteen days caused erratic signal floors because older data aged out too quickly.

The battery slope: Seven days. The battery detector watches for when a cell leaves its plateau and begins falling toward empty. A longer window averages the plateau with the drop, masking the exact failure rate it needs to catch.

Data retention is a separate setting on the Advanced screen. History is kept much longer because some trends require months to analyze. The short windows make the decisions, while the long record provides audit data.

Knowing When a Device Actually Spoke

Restarts, reboots, integration reloads, and coordinator reconnects generate traffic bursts that mimic device reports. A Zigbee bridge returning online publishes last-known states. Treating this traffic as real reports would erase the silences the system needs to detect.

The protocol clock: Device Sentinel checks for a last-contact time published by the coordinator. This clock records when the hardware actually communicated. If the last-contact entity is unavailable, the system treats the device as unheard.

When there is no clock: If an integration lacks a last-contact time, the arrival of a report counts as evidence. This includes reports generated during a system restart. A nightly restart is treated as part of the home's normal rhythm. Filtering restarts out would falsely flag devices that are simply quiet overnight.

Storms and Polling

For hardware without a protocol clock, the system attempts to identify replay bursts. When an entire integration's devices report simultaneously, the system classifies the burst as a storm and excludes the timestamps from the learning baseline.

A storm is logged with an opening, a closing, a duration, and a device count in the system events log. Repeated storms collapse into a single summary line.

Certain integrations poll their hardware on a timer. This behavior mimics a hub reconnecting. If the system detects enough storms within a single hour, it reclassifies the integration as a poller and learns its bursts normally.

Gaps and How They Are Measured

The system sets aside gaps that it cannot reliably judge:

• Unavailable stretches: The system learns brief mesh hiccups. It sets aside long unavailable stretches because the eventual return usually indicates a manual repair. The blip tolerance setting defines this threshold.
• Coordinator and broker outages: If Zigbee2MQTT or the MQTT broker fails, the system logs the outage and clears the devices of blame. The system names the coordinator or broker failure rather than reporting a massive list of unexplained offline hardware.
• Pairing windows: Gaps that end during a Zigbee pairing window are ended and ignored as manual re-pairing.

The daily brief explains a returning device using the recorded event in effect when it went quiet. Restarts, broker outages, coordinator drops, and integration reloads explain their respective devices. Groups collapse into single summary lines. The silence episode report records each of these with its specific reason. See The Diagnostic Reports for details.

Persistence

All learned statistics, device clocks, and active fault flags survive reboots. A twenty-hour freeze remains a twenty-hour freeze after a system restart.