Freeze Detection

Freeze Detection

A frozen device is the failure nothing else catches: the device stops reporting, but its entities keep showing the last healthy value. The temperature reads 21 degrees forever. Everything looks fine, and nothing is.

Device Sentinel catches this, along with the plainer cases where a device goes unavailable or unknown.

The Four Ways a Device Can Be Down

Device Sentinel categorizes a down device into one of four states based on what its entities show and how long it has been silent:

• Frozen: The device has stopped reporting, but its entities still show their last values. It has been silent past its learned window.
• Unavailable: Every live entity on the device reads unavailable.
• Unknown: Every live entity on the device reads unknown.
• Not reported: The device has shown zero activity in the 48 hours since it was first seen. This is checked ahead of the others because a device with no activity has no learned rhythm to miss. Even a once-a-day device will have spoken twice in 48 hours, so total silence means a device that never started, a stale registry ghost, or a monitor whose target is gone. These are yours to sort out: fix it, delete it from Home Assistant, or exclude it if it is meant to be silent.

The liveness rule: Underneath all of these is a single rule: if any live entity on a device still reports a real value, the device is alive, no matter how many of its sibling entities have dropped. A device is only considered down when nothing on it is reporting. If a down device shows a mix, some entities unavailable and some frozen, it takes its worst category, because a device with most of its entities unavailable is a dead device whose others simply have not caught up yet.

How a Device Is Judged

Every device is measured against its own learned rhythm, never a fixed timeout.

Device Sentinel has been learning how often each device speaks since installation, counting activity from any entity on the device. A device that reports every 30 seconds is judged on a scale of minutes; a device that reports twice a day is judged on a scale of hours. No single timeout could be right for both, which is why there are no timeout tiers to configure. The amount of history you choose to retain on the Advanced screen affects stored history only; it never changes how this detection behaves.

The freeze window: The window is the device's learned rhythm plus a grace margin. A device is flagged frozen when it is silent past this window while its entities still hold values.

Arming: A device is only judged frozen once it has learned enough days to have a trustworthy rhythm. Until then, it is watched for unavailable and unknown states, but never called frozen, because a device with no established rhythm has no window to miss. Devices with no natural heartbeat, like buttons that only speak when pressed, learn a very long rhythm and so are effectively never called frozen for ordinary quiet.

Tuning the Window: The Grace Sliders

The grace margin added to the learned rhythm follows a curve you shape with two sliders on the Freeze Detection configuration screen. The rhythm itself is measured, never chosen; these sliders only tune how patient the integration should be past each device's own normal.

• Delta low (1 to 8 minutes, default 3): The grace a fast device gets. This keeps a chatty device from being called dead just for missing a couple of routine reports. Raise this if a chatty device is being flagged too soon.
• Delta high (4 to 12 hours, default 8): The grace a slow device gets. This catches the slowest devices in a bounded time. Lower this if a slow device should be caught faster.

These sliders do not just cap the ends; they shape the whole curve between them, so moving either re-tunes every device in the fleet. At the defaults, a device that reports roughly once an hour gets about double its normal rhythm before it is flagged.

The Most Accurate Clock: Last-Seen Entities

For the most reliable freeze clock, press Scan and Enable Signal and Last-Seen Entities on the device page.

Where a device has a last-seen entity, that entity is the clock. It is the coordinator's own record of when it genuinely heard from the device, meaning a bridge or hub republishing a last known state cannot make a silent device look alive. Some integrations ship last-seen and signal entities disabled by default. Turning them on, which the button does for you, is the single most useful action you can take for freeze accuracy. Entities you disabled yourself are left alone.

Surviving restarts: A freeze in progress survives a restart because the silence is measured from a clock Device Sentinel keeps itself, not a value Home Assistant resets at every reboot. Detection is live: a device flagged at 11 AM shows at 11 AM, and the moment it genuinely reports again, the flag clears.

What Happens When a Device Goes Down

The moment a verdict is reached, the device joins the problem list as its own item and the device-family phone push fires, subject to your settle periods and quiet hours. Both of the integration's storage files are saved at that exact moment, so the verdict survives power cuts.

Each silence past its window is recorded as a row in the silence_episodes report, noting its duration, what ended it, and what it taught the statistics. A mysterious recovery while flagged is capped, so it cannot widen a device's freeze window unchecked; that vocabulary is explained in The Reports.

• The nightly report leads with a Down devices section, showing what is in trouble now, worst first, or an all-clear line.
• The count entity: The Device: Frozen count reports how many devices are down right now, with each one's category and duration carried in its attributes. It ships disabled by default because the problem list is the intended place to read this data, but you can enable it from the entities page if you want it on a dashboard.

The Freeze Exclude List

This configuration screen carries a freeze exclude list using the same three tiers as the others: by integration, by label, or by single device.

A freeze-excluded device keeps its clock and its learned rhythm, so it is still watched and re-including it is instant. It is simply never given a freeze, unavailable, unknown, or not-reported verdict. This is intended for devices that are intermittent by nature: a sensor that travels, a seasonal device, or something you want watched for battery and signal but never called down.

In the telemetry report, an excluded device's STATUS reads "Excluded (FRZ)".

How it interacts: When you exclude at a broader level, like an integration, everything it covers disappears from the narrower lists. Remember the dropped-not-parked rule: if you later undo a broad exclusion, you must re-pick any individual devices you still want excluded.

Versus Global Exclusions: A globally excluded device is judged by nothing at all and does not even appear in this list. Use the freeze exclude when you want a device watched for battery and signal but not called down; use Global Exclusions when you want it left alone entirely.