The Daily Brief

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.

What Is in It

In Short

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.

Now

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.

Last 24 Hours

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 says what ended it where that is knowable, a restart or a bridge reconnect, and says no intervention recorded where it is not. 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.

The Window, and What the File Is Named

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.

How the File Changes Through the Day

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.

What Is Deliberately Absent

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.

Sending It

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.