The Daily Brief
One report is written for a person rather than for whoever maintains the system, and this is it. Where the other files explain the machinery, the brief answers two questions in plain language: what is wrong now, and what happened since yesterday.
It is an HTML page in www/device_sentinel/, one file per day, named daily_brief_YYYY-MM-DD.html, and fourteen are kept. Beside the dated files sits daily_brief.html, always a copy of the newest write, so a dashboard Webpage card pointed at /local/device_sentinel/daily_brief.html always shows the current brief. It is written whether or not anything is configured to receive it, because it is a report first and a message second.
Two paragraphs at the top, and the part most people will read.
The first tells the window's history in the order it happened. A device stopped reporting at 1:02 AM, recovered at 3:03 AM after two hours when the Zigbee bridge reconnected, a battery fell to 14% at 3:02 PM. The second says what is standing right now, worst first.
These are the same sentences the notification engine sends. The brief is emailed on the schedule you set and repeats a report you have already had a chance to read; the phone pushes fire in the moment a problem appears. Both draw from the same detections, so the brief and the phone never disagree.
Above the device lines sits what happened to the house, because a reader who knows the broker was down will not read fifty consequences as fifty faults. Each event carries a duration:
- Restarts, with the span nothing was listening, and unclean shutdowns.
- Coordinator outages and pairing windows: "The z2m bridge went down at 1:40 AM. The z2m bridge came back at 1:41 AM after 1m."
- Broker outages: "The MQTT broker went down at 1:47 AM. The MQTT broker came back at 2:04 AM after 17m."
- Integration reloads: "The reolink integration reloaded at 4:12 PM."
Repetition collapses. An integration that reloads over and over reads as one line rather than two sentences each time: "The tplink_router integration reloaded 20 times between 12:50 PM and 1:56 PM, up to 5 device(s) at a time."
What needs attention, as a table: the device, the problem, when it started, and how long it has been going. Sorted worst first.
This section is always current. It is read at the moment the file is written, not bounded by the window, so a brief written at 7 AM tells you where things stand at 7 AM whatever period its history covers.
The events, newest first, with their exact times. The prose above is for reading; this is for scanning and for looking up when something happened.
A recovery names a cause only where a recorded event was in effect when the device went quiet and reaches that device. A restart explains any device. A broker outage explains devices that speak through it. A coordinator outage or a pairing window explains its own stack. An integration reload explains only its own devices. So the phrases you will see are: revived by a restart, by an unclean restart, by the MQTT broker going down and coming back, by the z2m bridge going down and coming back, by a z2m pairing window, or by an integration reloading.
Every device explained by the same event collapses to one sentence in the prose: "74 devices went unavailable at 1:50 AM and recovered, revived by the MQTT broker going down and coming back." A single device keeps its own sentence with its own timing. The grouping is for the prose only; the table below still lists every device separately, which is the point of having a table.
Where nothing fits, the brief says no intervention recorded. That phrasing is deliberate. Device Sentinel can see a restart and a reconnect happen; it cannot see you rebinding a device, pulling a battery, or replacing one. So the absence of a cause it recognizes is not evidence that nothing was done, and the report does not claim otherwise. On a healthy fleet most recoveries have no recorded cause, and that is correct rather than a gap.
For a freeze verdict on a Zigbee2MQTT device, the brief also carries what Zigbee2MQTT says about that device, with the timeout it judges by. See The Bridge and Broker Sensors for what that second opinion is and why it never lifts a verdict.
The window runs from one brief to the next rather than by calendar day, so a problem that starts at 11 PM and ends at 2 AM stays in one report instead of being split across two. Set the brief time to midnight on the Notifications and Daily Brief screen if you would rather have calendar days.
The file is named for the day its window opened. With a 7 AM brief, daily_brief_2026-07-23.html covers 7 AM on the 23rd through 7 AM on the 24th, so you read it on the morning of the 24th and it contains a few hours of that morning. That is deliberate rather than an oversight: the file is named for the day it is mostly about, and the alternative would leave the small hours of every night filed under the day before they happened.
Between one brief and the next, the file is rewritten as an in-progress version whenever reports are generated: by the Regenerate Reports button, at startup, and at midnight. Each version replaces the last and is marked in progress.
That working copy always covers the last twenty-four hours, wherever in the day you open it, so a dashboard card shows a full day rather than the handful of hours since your brief time. The dated file for each day is a separate thing and does not move: it stays bounded by your brief time, as described above.
At the brief time it is written once more, complete, and a new window opens behind it under tomorrow's name. So for most of the day there is one file being revised, and shortly after the brief hour there are two: yesterday's, finished, and today's, just begun.
Nothing is lost when a version is replaced. The brief is only a rendering of the incident record, which keeps fourteen days of everything that happened.
Excluded devices. This is a report, and exclusion suppresses reporting.
Acknowledged problems. Acknowledging something is the statement that you know about it and do not want reminding, and the brief is a notification that happens to be a file. Acknowledged faults are still recorded in full in the other reports and in the diagnostics, where an audit belongs. If an acknowledged device recovers on its own, that is reported, because the acknowledgment ends when the problem does.
The integration's own machinery. No learned rhythms, no freeze windows, no lag values, no exclusion reasoning. Those belong in the diagnostic files and would only get in the way here.
The brief is emailed on its schedule to whoever is listed under Send the Full Brief To on the Notifications and Daily Brief screen, most often an email address through SMTP. What arrives is the page itself, tables and styling included, so the brief in your inbox is the same document as the one on your dashboard. If a signal anomaly line is present, its link to the chart always carries a full address, so it opens from a phone rather than dying in your inbox. It uses your external Home Assistant address where one is set, which is what works when you are away from home, and your internal address otherwise. Both are set under Settings, System, Network, and it is worth setting at least one. The file is written whether or not a target is set. The live phone pushes are a separate channel, described on that same screen: they fire the moment a problem appears, while the brief repeats a report you have already had a chance to read rather than raising an alarm in the moment.