Signal Strength

Signal Strength

Device Sentinel watches how strong each device's radio link is, and how long it spends struggling. The feature records and reports these struggles, while alerting only on stuck, "railed" signals. The daily 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, meaning a device deep in the mesh may idle happily at a value that would mean a dead link for one sitting right next to the coordinator. A single global cutoff cannot tell those two apart, but a per-device baseline can.

Device Sentinel learns each device's floor: the worst link quality that device has repeatedly shown while still working. It is built from a rolling window of daily lows, with the worst readings trimmed off, so one bad hour does not move the baseline but a genuine decline does.

One rule covers both radio scales. For LQI, a lower number is worse; for RSSI (measured in dBm), a more negative number is worse. Below the floor is below the floor either way, so there is no separate formula and no asterisk on RSSI.

The Floor Is the Line

The floor is not just a baseline to sit under. It is the line itself. Dwell counts the time a device spends at or below its own trimmed floor.

This is a deliberate design choice that makes the whole feature testable. A line set below the floor could only ever catch catastrophe: on a healthy day nothing would reach it, the reading would be zero, and you would have no evidence the detector works at all. A line set at the floor is brushed by a healthy device during its bad moments. This gives a small, nonzero reading that proves the detector has teeth, and is clearly exceeded by a device that lives at its lows, which is the anomaly you want to catch.

How the Floor Is Chosen: The Trim Ladder

The floor is the lowest reading a device has shown, after trimming off a few of the very lowest as spurious. How many it trims grows as the device builds history:

• Under a week: Trim nothing. The floor is the plain lowest reading, meaning the line is live from the very first day.
• At a week: Trim the single lowest reading.
• At two weeks: Trim the two lowest readings.

The floor settles from "worst ever seen" toward "typical worst" as the history earns trust. Note that this trims the lowest values, which is the exact opposite of how the freeze rhythm trims its highest gaps. For signal, a spuriously bad reading is the anomaly to set aside; for rhythm, a spuriously long gap is. Both trim the outlier; the outlier just sits at a different end.

Rail values never feed the floor. A link quality pinned at 255 (or an RSSI at -128) is the empty value of a field the device stopped filling in, not a real reading, so it is filtered out before the floor is computed. A device whose entire history is rail has no floor at all, rather than a false one.

Sensitivity: Tuning the Line

The Signal Strength config screen has one sensitivity control for the whole fleet. It shifts the floor up or down by trimming more or fewer of the low readings. Its five settings read as words, from calmest to most reactive: Calm, Stable, Normal, Watchful, Sensitive. The nightly report shows the current setting in the SIGNAL column header.

• Calm and Stable are less sensitive. The floor sits at the rawest low and is rarely crossed.
• Watchful and Sensitive are more sensitive. The floor sits higher and is brushed more often. Weak moments register sooner.
• Normal sits in the middle and is where most installs should stay.

The goal to aim for: some of your devices should show small readings in the 0 to 5 percent range. That is the proof the line sits where normal variation just reaches it, so that a real problem stands out as big and obvious. If nothing ever touches the line, the line is telling you nothing.

This control is not retroactive. Changing it recomputes the floor for readings that arrive afterward, and dwell already counted today stays counted. A full clean day is needed to see a change's true effect. This is why it lives on the config screen, setting the expectation of "this configures behavior going forward," rather than acting as a live entity that implies an immediacy it cannot deliver.

Dwell: How Long, Not How Often

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

A brief dip counts only for the seconds it lasted. A link genuinely in trouble sits at or below the floor and the percentage climbs. If a device goes silent while below the floor, that silence counts as time below, because a link that died while struggling was struggling the whole time. Both dwell and the below-since moment survive restarts, so counting does not reset on a reboot.

Reading the Report

The nightly telemetry report gives each device a SIGNAL column and a DWELL% column. SIGNAL shows the daily minimums the floor is chosen from, newest first, with three marks:

• The floor (the line dwell measures against) is bold on its earliest recorded appearance.
• Readings strictly below the floor are struck through: the trimmed lows set aside so a spurious bad reading does not define the line.
• Rail fill values are shown in italic.

A value equal to the floor is never struck, so the same number is never both the line and an outlier. A device confirmed stuck at the rail is marked with a warning sign at the front of its cell. The marks let you check the line against the readings behind it at a glance: if a device's line looks wrong, its lows show you why.

How to use it: most of your devices should sit in low single digits. That is the design working. The outliers are the whole point. A device reading 20 or 40 percent spent much of its day at or below its normal-worst. If several outliers are in the same room, that room is where your mesh is thin and needs a router or repeater. The percentage turns a vague "my Zigbee feels flaky" into a specific place to put hardware.

Stuck Signal (The Rail)

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. While this looks like perfect signal, it is the exact opposite: it is the empty value of a field the device stopped populating. Real fleet link quality never reaches 255, so a flat 255 is always a stale reading, not a strong one.

Device Sentinel calls a signal railed when its daily low sits at the type's fill value (255 for LQI, -128 for RSSI) for three consecutive days. Confirming it over three days means a rail that comes and goes within a day never trips, while one that holds is caught.

This is currently the only active alert for signals. A railed device becomes a signal problem now: it lands on the problem list, updates the persistent card, and sends a signal-family phone push like any other fault. It is marked in the nightly report. A rail is not a weak link; it is a lying one, and it is worth fixing because it hides whatever the real signal is doing.

A signal held at a plausible value, a real reading that stops moving, is deliberately not called a problem. That rule was tried and removed: a strong stable link reports the same value for hours and cannot be told apart from a stuck one by the reading alone, and a whole family of window-blind devices reported a steady RSSI for hours and flagged falsely before the rule was narrowed to the rail. Genuinely dead devices are the freeze detector's job, not this one's.

Recovery steps, 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 forces it to re-establish what it reports.

During development, this detection found sensors frozen at 255 that every standard dashboard showed as healthy. Most recovered in minutes, but one mains plug resisted everything. This is why a railed device is never dropped automatically; it stays reported until you recover it or exclude it by hand.

Excluding a Device

A device that resists every recovery will report noise forever. The Signal Strength screen has a signal-only exclude list to silence it, following the same broad-to-narrow shape as Low Battery and Global Exclusions: by integration, by label, or by individual device. The same dropped-not-parked rule applies.

Exclusion suppresses judgment, not observation. An excluded device keeps recording its floor and dwell in storage; it simply stops being reported and cannot become a signal problem. Re-including the device later brings its mature history back instantly. In the report, an excluded device shows its daily lows as normal but reads "excl" in the dwell and rail columns, and its STATUS reads "Excluded (SIG)".

What You Can Do Today

• Enable Signals: Press the Enable Signals button on the device page. Some integrations ship signal entities disabled by default, and this turns them on so Device Sentinel can learn from them. Entities you disabled yourself are left alone. There are matching Enable Last Seen and Enable Battery buttons beside it for those diagnostics.
• Tune sensitivity: Open the Signal Strength config screen to set your fleet's sensitivity.
• Exclude the stubborn: Exclude any device that will not recover from a railed state.

What Alerts and What Is Still Coming

The rail alerts now. The weak-link side, the dwell, is still recording rather than alerting: it is measured and reported for you to read, but it does not raise an alert on its own yet, because where the alerting threshold should sit is being decided from real data as the system matures. Until then, read the dwell in the reports; the rail is the signal problem that speaks up on its own.