Signal Strength

Signal monitoring is experimental. Everything here is recorded and reported, but nothing about a weak link 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 notify you until it has been shown to predict real failures, and that takes examples of meshes that actually misbehave. If yours does, see Help Map Signal Failures at the foot of this page.

Device Sentinel watches the radio link quality of every device that reports one. It learns each device's normal range and watches for a link that sits unusually low against its own normal. This screen tunes how that judgment works and allows you to mute noisy devices from it.

1. Judged Against Itself, Never a Chart

There is no universal number for a healthy signal. A sensor two rooms from the coordinator lives its whole life at a level that would mean trouble for a sensor in the same room, yet both can be perfectly reliable.

Because of this, Device Sentinel never compares a device to a fixed threshold or to other devices. Each 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). Each device is judged on whatever it reports, and the two are never mixed.
• Rails vs. Drops: A reading stuck at exactly 255 LQI or -128 RSSI is a stale "rail" report, not a strong or weak link. A device pinned there for three days is flagged as "railed" on the problem list. This page handles the other problem: a working link that is suddenly struggling.

2. What Makes a "Bad Signal Day"

Each night, Device Sentinel looks at the low edge of the day for each device, ignoring single bad packets that are just noise.

It then compares that daily low to the device's own recent normal. A day is marked as bad only when it clears two gates:

1. The Drop Gate: The signal fell far enough in its own units (e.g., a drop of 25 LQI points).
2. The Sensitivity Gate: The fall was unusually large compared to the device's normal, everyday bounce.

Both gates are needed. The absolute fall stops a trivial wobble on a very steady device from triggering a flag. The sensitivity gate stops a naturally bouncy sensor from being flagged every day for doing what it always does.

(Note: You can view the results of this judgment on The Signal Report, which is written beside your daily brief).

3. Tuning the Sliders

These four sliders control the two gates mentioned above.

• Bad Day Drop, LQI (default 25): The flat fall in LQI points required to flag a bad day.
  • Raise it to flag fewer days. Lower it to flag more.
• Bad Day Drop, RSSI (default 6): The same flat fall in decibels, for devices that report in dBm.
  • Raise it to flag fewer days. Lower it to flag more.
• Bad Day Sensitivity (default 4.0): How unusual a drop must be compared to the device's normal bounce. This keeps erratic sensors from being flagged daily. At a setting of 4, a sensor that routinely swings 10 points needs a 40-point plunge to trigger.
  • Raise it to tolerate more bounce. Lower it to flag more days.
• Days of Signal History (default 7): How many past days are used to figure out what is "normal" for the device.
  • Fewer days react quicker and forgive quicker. More days are steadier and slower to notice a decline.

4. Signal Muting

Muting a device here stops signal judgment and reporting for that device only; its battery and freeze watching continue. If you want to drop a device from tracking entirely, use Exclusions and Muting.

The lists run from broad to narrow: Integrations > Labels > Devices.

Muting suppresses judgment, not observation. The device keeps recording its history in the background, so if you un-mute it later, it resumes reporting instantly with its history intact.

5. Help Map Signal Failures

Signal is the one part of Device Sentinel that watches without judging, and it stays that way until it earns the right to wake you.

Nobody yet knows which signal pattern perfectly predicts a device failing. A link can sit low for months and never miss a report, while another looks healthy and drops out weekly. Turning on live alerts before that relationship is mapped would mean a stream of warnings about devices that are fine, teaching you to ignore the system.

We need data on real failures to settle this. If your mesh is flaky, you can help.

Open an issue at the Device Sentinel GitHub 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 important: 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 what turns a set of numbers into a real answer.