Skip to content

Signal Strength

TheThinkingHome edited this page Jul 18, 2026 · 29 revisions

Signal Strength

Device Sentinel watches how strong each device's radio link is, and how long it spends struggling. As of 0.4.0 this records and reports; it does not notify yet. The numbers land in the nightly report and the diagnostics, for you to read and act on.

The floor: every device's own normal

Signal numbers have no shared scale. Link quality (LQI) is defined by each manufacturer, so a device deep in the mesh may idle happily at a value that would mean death for one sitting beside the coordinator. A single global cutoff cannot tell those two apart. A per-device baseline can.

So Device Sentinel learns each device's floor: the worst link quality that device has repeatedly shown while still working. It is built the same way the freeze rhythm is, from a rolling window with the single worst day trimmed off, so one bad hour does not move it but a real decline does. The floor needs seven days to establish, the same as the freeze rhythm.

The danger line, and why there are two formulas

Below the floor sits a danger line: the point where a reading stops being normal-low and starts being trouble. The two radio scales get different formulas, because they are physically different measurements.

Link quality (LQI) runs roughly 0 to 255 and is close to linear, so its danger line is a fraction of the device's own floor. A device whose floor is 80 and one whose floor is 200 are each judged against their own normal, proportionally.

Signal power (RSSI) is measured in dBm and is logarithmic: every 10 dB is a tenfold change in actual power. On that scale a fraction is meaningless, so the danger line is a fixed decibel drop below the floor. A drop of 10 dB means the signal has fallen to about a tenth of its normal power, roughly the effect of moving twice as far from the coordinator or adding a wall.

Both lines are fixed at starting values while the first weeks of data come in. A single sensitivity control will replace them once the data shows where real devices sit.

Dwell: how long, not how often

A signal is noisy. It dips and recovers constantly, and a device that brushed its danger line for one second at 3 AM is not a problem. So Device Sentinel does not report crossings. It reports dwell: the share of each day a device spent below its danger line.

A brief dip that recovers counts only for the seconds it lasted. A link genuinely in trouble sits below the line and the percentage climbs. If a device goes silent while below the line, that silence counts as time below, because a link that died while struggling was struggling the whole time.

Reading the report

The nightly telemetry report gives each device a DWELL% column, newest day first. The way to use it:

Most of your devices should sit in the low single digits. That is normal. A device brushing its own floor a few percent of the day is a healthy device on a busy mesh, and you ignore it.

The outliers are the whole point. A device reading 20 or 40 percent spent much of its day below its normal, and that is worth looking at. And if several outliers are in the same room, that room is where your mesh is thin: it needs a router or a repeater. The percentage turns a vague "my Zigbee feels flaky" into a specific place to put hardware.

Stuck signal

Sometimes a device stops reporting its signal at all and leaves the last value frozen. In Zigbee2MQTT this shows as a link quality pinned at 255, which looks like perfect signal and is the opposite: it is the empty value of a field the device stopped filling in. Across a whole fleet, real link quality never reaches 255, so a flat 255 is always a stale reading, not a strong one.

Device Sentinel detects a signal stuck at that value for a full day and marks the device STUCK in the report. This is not a weak link; it is a lying one, and it is worth fixing because a stuck reading hides whatever the real signal is doing.

To clear a stuck signal, in order of effort:

  1. Trigger the device to force a fresh report: press its button, open and close the contact, cycle the plug.
  2. Power cycle it, or pull and reseat the battery.
  3. Re-interview or re-bind it in Zigbee2MQTT, which makes it re-establish what it reports.

On the development system this detection found five sensors stuck at 255 that every dashboard showed as healthy. Four were recovered within minutes by the steps above. The fifth, a mains plug, resisted every step and stayed stuck, which is why a stuck device is never dropped from tracking automatically. It stays on the report until you either recover it or exclude it by hand.

What you can do today

Press Scan and Enable Signal and Last-Seen Entities on the device page. Some integrations ship signal entities turned off, and this turns them on so Device Sentinel can learn from them. Entities you disabled yourself are left alone.

What is still coming

The configuration screen for this section, with the sensitivity control and a signal-only exclude list, in the same shape as Low Battery. Until it ships, the danger lines run at their fixed starting values and every device with a signal entity is watched.

Clone this wiki locally