Signal Strength

Signal Strength

Device Sentinel watches the radio link quality of every device that reports one, LQI from Zigbee and RSSI from WiFi and Bluetooth, and turns the noise into one readable number per device per day. This page explains how the line is drawn, what the three sliders do, how to read the dwell chart, and what alerts today.

The Floor: Every Device's Own Normal

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 Line: A Margin Above the Floor

The floor is the baseline, and the line the day is judged against sits a small margin above it. Dwell counts the time a device spends at or below that line.

The margin exists because a floor drawn from a device's own history is, by construction, rarely touched: almost every device would read exactly zero almost every day, and a measure that reads zero for everything cannot tell you which room needs a router. Lifting the line a little above the floor means a link hovering just above its own worst still registers a small number, so most healthy devices show low single digits, and a device in real trouble stands out as big and obvious against them.

The margin is a percentage of the device's own floor, so it scales with the device: 5 percent of a 200-point floor adds 10 points, while 5 percent of a 40-point floor adds 2. A strong link can absorb larger swings than a weak one before either is worth reporting, and the formula respects that. On RSSI the percentage is taken against the size of the number rather than its sign, so the line moves the same direction on both scales.

The Three Sliders

The Signal Strength config screen has three controls for the whole fleet. They do different jobs, and the nightly report shows both: the current Anomaly Trim word in the SIGNAL column header, and the dwell each device recorded against the resulting line.

Sensitivity (0 to 10 percent, default 5) sets the margin: how close to the floor a reading must be to count as weak. At 0, only readings at or below the floor register, and the integration behaves exactly as it did before the margin existed. Higher values catch links that hover just above their baseline.

Anomaly Trim (five positions, shown as words: None, Light, Normal, Deep, Deepest) sets where the floor itself sits, by choosing how many of the very lowest daily readings are set aside as one-off flukes before the floor is taken. None trims nothing, so the floor is the device's genuine worst day and is rarely crossed. Deepest trims the most, raising the floor toward typical operation.

Red Threshold (5 to 20 percent, default 10) belongs to the dwell chart below: it sets where yellow turns red, and every red device is pulled out as an anomaly and described in full. It colors the chart and nothing else; no alert fires from it.

How many readings the trim can set aside also grows as a 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.
• A week: The single lowest is set aside.
• Two weeks on: The two lowest are set aside, plus or minus the Anomaly Trim setting.

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.

Neither slider is retroactive. Changing one recomputes the line 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 they live on the config screen, setting the expectation of "this configures behavior going forward," rather than acting as live entities that imply an immediacy they cannot deliver.

Dwell, Not Crossings

A radio signal is noisy. It dips and recovers constantly, and a device that brushed its line 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 line.

A brief dip counts only for the seconds it lasted. A link genuinely in trouble sits at or 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. Both dwell and the below-since moment survive restarts, so counting does not reset on a reboot.

The Dwell Chart

The chart is where the whole fleet reads at a glance: one colored bar per device that spent any time at or below its line, for yesterday, the last 7 days, and the last 30 days. Open it at /local/device_sentinel/signal_dwell.html, or put it on a dashboard with a Webpage card pointed at that address. A dated copy per day is kept for two weeks beside the always-current file.

The colors: green up to 5 percent is a healthy link brushing its line, which is the design working; yellow up to your Red Threshold is worth a glance; red above it is weak. Every red device also appears in the Anomalies table at the top with its room, its integration, its learned floor, its current reading, the direction it moved since the day before, and how many consecutive days it has been over the threshold. One day over is a bad day; a run is a bad link, and several red bars naming the same room is where your mesh needs a router.

If any anomalies exist, the morning brief names them and links the chart.

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 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 floor 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 floor against the readings behind it at a glance: if a device's floor looks wrong, its lows show you why. The dwell beside them is measured against the line, which sits the Sensitivity margin above the bold floor.

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.
• Put the chart on a dashboard: A Webpage card pointed at /local/device_sentinel/signal_dwell.html shows the current chart wherever you look for it.
• Tune the line: Open the Signal Strength config screen. Sensitivity is the one to reach for first; Red Threshold shapes the chart; Anomaly Trim is set-and-forget for most fleets.
• 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.