Detecting Failed or Degraded Meshtastic Nodes

How to distinguish a real infrastructure fault from normal radio uncertainty, observer gaps and stale data.

Failure is not the same as silence

A node absent from one application may be outside that observer’s path, filtered from a limited node database, transmitting infrequently or hidden by congestion. A map may show cached information long after the last packet. Conversely, a node that still sends telemetry can have a damaged antenna and provide little useful service.

Detection should therefore combine several indicators and compare them with an expected baseline. Permanent infrastructure needs explicit expectations: normal reporting interval, known observers, representative test links and the longest ordinary gap under current settings.

Define useful states

Status	Meaning	Typical action
Operational	Expected service and health evidence are present	Continue monitoring
Suspected degradation	One indicator changed materially	Seek independent evidence
Degraded	Repeated evidence shows reduced function	Plan correction and update status
Suspected offline	Expected signals are absent	Check observers, paths and backhaul
Offline	Independent checks support unavailability	Recover remotely or schedule visit
Status unknown	Monitoring is insufficient	Do not claim either health or failure

Use multiple health dimensions

Presence: NodeInfo, telemetry or other packets received recently by more than one observer.
Power: battery minimum, charging recovery, voltage trend and reset behavior.
Radio: RSSI, SNR and delivery rate on stable paths in both directions.
Routing: expected neighbors, traceroute observations and relayed service.
System: uptime, repeated reboot pattern, temperature and module behavior.
User evidence: credible reports from the intended coverage area.

No universal RSSI or SNR threshold defines failure. Compare the same endpoints, antenna orientation, preset and approximate conditions. A 12 dB shift on a stable path may be more meaningful than whether a single reading looks “good.”

Understand monitoring blind spots

Meshtastic nodes have constrained memory. On many embedded devices the NodeDB is limited, and older or less relevant entries can be removed as new nodes appear. Mobile apps and dashboards may retain a larger history. Treat each observer as a partial view, not the central truth.

MQTT dashboards add another layer. Broker, internet, gateway and decoding problems can make healthy radio infrastructure disappear. Check whether direct LoRa observers still hear the site before classifying it. Equally, an MQTT packet from one gateway does not prove broad RF coverage.

Detect antenna degradation

A loose connector, water-filled coax, cracked antenna or changed orientation may not stop transmissions. Look for lower received signal on several paths, disappearance of one sector, increased asymmetry, fewer neighbors and higher packet loss while device power remains normal. Compare against commissioning tests and ask observers around the site, not only in one direction.

Detect power degradation

For mains sites, repeated gaps after power interruptions may expose poor restart behavior or a failed supply. For solar sites, trend the lowest overnight voltage and time required to recharge. Progressive decline, later daily recovery or resets near a similar voltage suggests energy trouble. Correlate with weather and temperature before concluding that the battery has failed.

A practical confirmation sequence

Confirm that the alert matches the node’s expected reporting interval.
Check at least one independent LoRa observer.
Separate radio observations from MQTT or application status.
Review recent configuration, firmware, power and weather changes.
Test a known two-way path without creating excessive traffic.
Attempt authorized remote administration if already configured.
Classify the incident and update the public status honestly.
Dispatch a site visit only with a defined objective and recovery kit.

Avoid alert storms

Do not transmit health checks every few seconds across the mesh. Device telemetry itself consumes airtime. Collect passive observations, use reasonable intervals and perform active tests only when needed. Monitoring that congests the channel can create the degradation it reports.

Use persistence and hysteresis: require more evidence to declare failure than one missed interval, and require stable recovery before immediately returning a node to operational. Keep the raw timestamps so maintainers can review the decision.

Document the baseline and incident

Without commissioning evidence, diagnosis becomes guesswork. Store expected intervals, known direct links, normal power curves and seasonal behavior. For each incident, record first detection, observers, symptoms, changes, actions and resolution. Over time, recurring patterns reveal weak hardware or design practices.