The Signal Report

Signal is experimental. Everything here is recorded and reported, and nothing here raises a phone alert yet. The one exception is a link stuck at a "rail" value, which is a false reading rather than a weak one, and does notify. Weak-link alerting will not wake you up until it has been proven to predict real failures. If your mesh misbehaves, see Help Map Signal Failures at the foot of this page to help us build that logic.

The signal report answers one simple question: which radio links are worse today than they usually are?

It is an HTML page written beside the daily brief and whenever you press Regenerate Reports.

Judged Against Itself

There is no universal number for a healthy signal. A motion sensor in the garden lives its entire life at a signal level that would mean a dead sensor if it were sitting in the living room, yet both can be perfectly reliable.

Because of this, Device Sentinel never compares a device to a fixed threshold or to other devices on your network. Every device is judged against its own history alone.

• Two Scales: Devices report in either LQI (0 to 255, higher is better) or RSSI (dBm, closer to zero is better). The integration judges each device on whatever it reports, and the two scales are never mixed.
• Ghost Readings: A reading stuck exactly at a "rail" value (255 LQI or -128 RSSI) is a stale ghost report, not a strong link. Devices pinned there for three days are flagged as "railed" directly on your Problem List. This report handles the opposite problem: a working link that is suddenly struggling.

What Makes a "Bad Signal Day"

At midnight, Device Sentinel looks at the low edge of the day for each device. It deliberately ignores single dropped packets, which are just noise, and figures out where the link actually sat when it was struggling.

It then compares that daily low to the device's historical normal, looking at two things:

1. Did the signal drop by a meaningful amount (e.g., 25 LQI points)?
2. Did it fall far outside the device's usual jitter?

Both gates matter. You need the flat drop to stop a trivial wobble on a rock-solid device from throwing a flag. You need the jitter check to stop a naturally bouncy sensor from being flagged every day just for doing what it always does.

How to Read the Strip

The top of the report is a colored strip: one row per device, worst first, with one cell per day. A ringed cell means a bad signal day.

Only devices worth looking at appear here. If a device has not dropped significantly below its own normal, it stays off the strip. You always get at least five rows, so a quiet fleet still shows you something to read a band against, and never more than twenty, so a broker outage that drops everything does not put your whole house on the page. (The full fleet is hidden behind a toggle for when you need to go hunting).

Look for vertical bands. If three devices all show a bad day on Tuesday, they share a cause. Routers serve by radio topology, not by the room they sit in. If several devices scattered across your house drop on the same day, you don't have a sudden mass-failure of end sensors. You have one dead router.

The Biographies

Below the strip, up to eight devices get a paragraph and a chart of their own. This shows exactly what the signal fell from and to, whether it has come back, and what happened to the device's reporting rate. A reporting rate that suddenly spikes on a bad day is the link frantically retrying to send messages, which is proof that the link is actually struggling.

Where It Lives

The page is signal_report.html in your config/www/device_sentinel/ folder. The strip shows the last 14 days, and dated copies are kept for 30.

To put it on a dashboard, drop a standard Home Assistant Webpage card and point it at /local/device_sentinel/signal_report.html. It will always display the most current version.

You can tune the sensitivity of this report on the Signal Strength configuration screen.

Why the Old "Dwell" Chart Is Gone

Previous versions of this integration used a "Dwell" metric, which tracked how long a device sat near its own floor.

It failed because it chased a sinking floor. If a router died and a sensor's link broke, its baseline descended to meet the new, terrible reality. Within a week, a permanently broken link read as perfectly "healthy" again because it was no longer dropping. It was just dead. On the reference fleet, one broken device's floor fell from 226 to 139 in three days while its actual signal sat flat.

The proof arrived with the first ground-truth event on record: a router unplugged on 18 August that took four devices down with it. Dwell caught one of them. The bad signal day caught all four.

The new report compares today against history, not against a line that has already surrendered.

Help Map Signal Failures

We know how to spot a weak link. What nobody knows yet is exactly which signal pattern predicts a device actually going offline.

A link can sit low for months and never miss a report, while another looks perfectly healthy and drops out weekly. Turning on live phone alerts before that relationship is mapped would mean a stream of warnings about devices that are fine, which just teaches you to ignore the system.

We need data on real failures to settle this. A healthy mesh cannot answer the question, however long it runs.

If your mesh is flaky, you can help. Open an issue at the Device Sentinel repository titled contribute signal, and attach two things:

1. A diagnostics download: (Settings > Devices and Services > Device Sentinel > 3-dot menu > Download diagnostics). It carries device names and no passwords or tokens.
2. Your signal report: Found at config/www/device_sentinel/signal_report.html.

Most importantly: Tell us in the issue which devices actually give you trouble and roughly how often. That human context is the piece no file contains, and it is exactly what turns a spreadsheet of numbers into a real answer.