The Diagnostic Reports

Device Sentinel writes three diagnostic files behind the scenes, tucked away in your config/device_sentinel/ folder. A fourth, stack_probe.md, appears only when Z-Wave, Matter, Philips Hue, SmartThings, Tuya or Lutron Caséta is turned on under Extended Diagnostics.

Think of these files as the integration's scratchpad. You don't need to read them every day, and they won't throw alerts on your dashboard. They exist for one reason: when a device acts up, or when you want to know why the integration made a specific decision, the exact history is sitting right there in plain text.

(Looking for the plain-language summary instead? Head to The Daily Brief, or the dashboard's Battery Trends and Signal Trends tabs.)

The first three files are rewritten at startup, at midnight, at your scheduled brief time, and when you press the Regenerate Reports button on the device page.

1. device_telemetry.md (Learned Statistics)

This is where the integration keeps its homework. It contains one row per watched device, sorted alphabetically by name so you can quickly scan for the hardware you are troubleshooting.

• The Math: You get the learned daily maxima, today's running maximum, the rhythm so far, and each link's recent signal days beside its normal and the line a bad day falls below. If you've ever stared at a freeze window and wondered, "How on earth did it decide on three hours?", the exact math is right here. Each device shows the rhythm from both freeze rules, TRIMMED and LOG-NORMAL, with RULE IN USE naming the shorter and WINDOW the wait it is judged by, and a line above the table counts how many devices used each rule that day.
• The Status: See at a glance whether a device is currently "Reported" normally, or "Muted" by a global or section-specific rule. The code in brackets names which rule: GLB for a global mute, or BAT, SIG and FRZ for the battery, signal and freeze screens.
• The Faults: Up top, before the big chart, every active fault is listed by family (Freeze, Battery, Signal). It shows how long the fault has lasted and its standing on your Problem List: [○ open], [✓ acknowledged], or [✗ removed from list] if you deleted the item by hand while the fault was still live. (Acknowledged faults stay visible here on purpose. Checking a box silences your phone, it doesn't blind your diagnostics).

2. classification.md (Classification)

If a device isn't showing up where you expect it to, this table tells you why in a single glance.

It marks whether a device is watched or set aside, and instead of a cryptic checkmark, it tells you exactly why a device was set aside: was it a cloud service with no hardware? Did Home Assistant turn it off? Does it lack entities? Is it a clone of hardware another integration already watches? Or did you explicitly exclude its integration?

It also audits your muting rules, telling you exactly which global rule caught a silenced device, and points out duplicate names shared by different devices. The line above the table counts your devices: how many devices are watched, how many are set aside and for what reasons, and how many entities exist with no device behind them at all.

3. silence_episodes.md (Silence Episodes)

This is the detective file. It answers the one question the other files can't: When a device went dark for hours and then magically came back, did it choose to speak, or did a server reboot force it to wake up?

A row opens once a device's silence is halfway from its normal longest gap to the point where it would be called frozen, long before any judgment is passed. It logs when the silence started, how long it ran, and how it ended (whether it resumed on its own, or if an intervention like a system restart or bridge reconnect revived it).

The LAG Column (Finding Stuck Radios)

This column measures the time from an intervention (like a server reboot) to the device's very first report.

If you see the exact same devices popping up with a lag of a few "seconds" every single night, your server restart is what revived them. You have a stuck-radio problem, and widening your freeze windows would only sweep it under the rug. If the lag is measured in "hours," the device wasn't stuck at all; it just has a long reporting rhythm that your system restarts keep interrupting.

What Was Learned? (The LEARNED Column)

When a gap closes, the integration decides whether to use that gap to calculate the device's normal rhythm.

If the gap was a natural, clean cycle, it gets learned. But if the silence was caused by something else, a power outage, a reboot, you changing the battery, a pairing window, or a mesh failure, the gap is safely set aside. This column tells you exactly which gaps were discarded and why, proving that the system isn't learning that being broken or unplugged is "normal."

Here is what you will see in that column:

Reads	Means
yes	A clean, natural cycle. Learned in full.
yes (truncated)	An intervention cut the silence short, so what was learned is a lower bound.
yes (downtime out)	Learned, with the time Device Sentinel itself was stopped taken out of the gap.
no (unavailable) / no (unknown)	The device sat unreachable partway through, so the return may have been your hands rather than a real recovery.
no (bridge down)	The silence overlapped a coordinator outage. The outage takes the blame.
no (upstream down)	The silence overlapped an outage of the device's broker, integration or network. The outage takes the blame.
no (unclean shutdown)	A power loss or crash. Nothing was listening, so the gap measures the outage.
no (pairing)	It came back during a Zigbee pairing window, so this was your re-pair.
no (clock jump)	The system clock jumped during the silence, so its length can't be trusted.
no (handled)	ZHA announced the device was re-paired, reconfigured or removed.
no (maintenance)	It recovered inside an open Maintenance Mode window.
no (disabled)	The device was switched off in Home Assistant for part of the silence.
capped (74m -> 15m)	It was already reported frozen when it spoke, and nobody knows what revived it, so the statistics learn its rhythm plus a modest allowance instead of the whole gap.