Network Monitoring and Management

Building a Mesh Network Dashboard
A community mesh network dashboard gives operators a real-time view of network health - which nodes are online, battery levels, channel utilization, and connectivity maps. This page covers building a monitoring stack for a Meshtastic network. 

 Architecture Overview 
 The standard monitoring stack for Meshtastic: 
 Meshtastic nodes
 ↓ (MQTT uplink)
MQTT Broker (Mosquitto)
 ↓
Telegraf (or Python consumer)
 ↓
InfluxDB (time-series database)
 ↓
Grafana (dashboard and alerting) 
 This stack can run on a Raspberry Pi 4 or any small Linux server. Total resource requirement: approximately 500 MB RAM, 10 GB storage for 30 days of data from a 50-node network. 

 Step 1: MQTT Broker Setup 
 Install Mosquitto on your monitoring server: 
 sudo apt install mosquitto mosquitto-clients
sudo systemctl enable mosquitto 
 Minimal config at /etc/mosquitto/mosquitto.conf : 
 listener 1883
allow_anonymous true
persistence true
persistence_location /var/lib/mosquitto/ 
 For production, add TLS and password authentication. 

 Step 2: Configure Nodes to Uplink 
 On each node you want to monitor: 
 meshtastic --set mqtt.enabled true
meshtastic --set mqtt.address "YOUR_SERVER_IP"
meshtastic --set mqtt.uplink_enabled true
meshtastic --set mqtt.json_enabled true 
 JSON mode outputs human-readable JSON instead of protobuf binary - easier for custom consumers but includes less data. For full data including all telemetry, use protobuf mode and decode with the meshtastic Python library. 

 Step 3: InfluxDB 
 Install InfluxDB 2.x: 
 wget -q https://repos.influxdata.com/influxdata-archive_compat.key
sudo apt install influxdb2
sudo systemctl enable --now influxdb 
 Create a bucket named "meshtastic" with 90-day retention via the InfluxDB UI at http://localhost:8086. 

 Step 4: Python MQTT-to-InfluxDB Bridge 
 pip install paho-mqtt influxdb-client meshtastic

# bridge.py - subscribe to Meshtastic MQTT, write metrics to InfluxDB
import paho.mqtt.client as mqtt
from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS
import json, time

INFLUX_URL = "http://localhost:8086"
INFLUX_TOKEN = "YOUR_TOKEN"
INFLUX_ORG = "meshamerica"
INFLUX_BUCKET = "meshtastic"

client = InfluxDBClient(url=INFLUX_URL, token=INFLUX_TOKEN, org=INFLUX_ORG)
write_api = client.write_api(write_options=SYNCHRONOUS)

def on_message(mqttc, userdata, msg):
 try:
 data = json.loads(msg.payload)
 node_id = data.get("from", "unknown")
 if "payload" in data:
 p = data["payload"]
 pt = Point("node_telemetry").tag("node_id", node_id)
 if "battery_level" in p:
 pt = pt.field("battery_pct", p["battery_level"])
 if "voltage" in p:
 pt = pt.field("voltage", p["voltage"])
 if "channel_utilization" in p:
 pt = pt.field("channel_util", p["channel_utilization"])
 write_api.write(INFLUX_BUCKET, record=pt)
 except Exception as e:
 print(f"Error: {e}")

mqttc = mqtt.Client()
mqttc.on_message = on_message
mqttc.connect("localhost", 1883)
mqttc.subscribe("msh/#")
mqttc.loop_forever() 

 Step 5: Grafana Dashboard 
 Install Grafana and add InfluxDB as a data source. Useful panels: 
 
 Battery Voltage by Node - Time series, grouped by node_id tag 
 Online Node Count - Count distinct nodes seen in last 30 minutes 
 Channel Utilization Heatmap - Spot congestion patterns over time 
 Last Seen Table - Node name and minutes since last packet 
 

 Alerting 
 Configure Grafana alerts to notify via email, Slack, or Telegram: 
 
 Battery below 20% - node needs attention 
 Node offline (no data in 2 hours) - repeater may be down 
 Channel utilization above 30% - network congestion warning

Using meshmap.net and Community Maps
meshmap.net is the primary public Meshtastic network map, displaying nodes from around the world that have enabled MQTT uplink with position reporting. It gives operators a quick view of community coverage without building their own infrastructure. 

 What meshmap.net Shows 
 
 Node positions on an interactive map 
 Node names, last seen timestamps, and hardware type 
 Neighbor relationships - which nodes have heard each other directly 
 Signal quality (SNR, RSSI) for recent links 
 Node telemetry where reported (battery, channel utilization) 
 

 Getting Your Node on the Map 
 Requirements to appear on meshmap.net: 
 
 Your node must have a GPS fix or fixed position configured 
 MQTT uplink must be enabled, pointing to mqtt.meshtastic.org (the default Meshtastic public broker) 
 Position reporting must be enabled (not position_precision = 0) 
 
 meshtastic --set mqtt.enabled true
meshtastic --set mqtt.address "mqtt.meshtastic.org"
meshtastic --set mqtt.uplink_enabled true
meshtastic --set position.position_precision 10 
 Nodes typically appear within 15-30 minutes of enabling MQTT uplink. Position is updated each time the node broadcasts a position packet. 

 Privacy Considerations 
 Your node's position is publicly visible on meshmap.net once MQTT uplink is enabled. Consider: 
 
 Use position precision to reduce location accuracy: precision 10 = ~1km accuracy, precision 7 = ~10km. This shows general area without revealing exact location. 
 Fixed infrastructure repeaters: full precision is usually acceptable and helpful for community planning 
 Personal/portable nodes: reduced precision (or disabling MQTT uplink) may be preferred 
 
 meshtastic --set position.position_precision 10 

 Alternative and Regional Maps 
 Beyond meshmap.net, several regional communities maintain their own maps: 
 
 Custom Grafana + Leaflet maps fed by self-hosted MQTT brokers give communities more control over who appears and what data is shown 
 Some communities use ATAK (Android Team Awareness Kit) with Meshtastic integration for a more sophisticated operational picture 
 meshcore.net may show MeshCore nodes in regions with active MeshCore communities 
 

 Reading Neighbor Info for Coverage Analysis 
 The Neighbor Info module in Meshtastic (Config → Modules → Neighbor Info) broadcasts a list of directly-heard nodes to the mesh. When this data reaches meshmap.net, it draws link lines between nodes that can hear each other. These link lines are the basis for understanding your network's topology: 
 
 Isolated nodes with no link lines - check if repeaters are within range 
 Nodes connected only through a single relay - identify single points of failure 
 Dense link clusters - confirm your urban repeater placement is achieving coverage

Mesh Network Change Management
A community mesh network is shared infrastructure. Changes to configuration - channel presets, node roles, frequency settings - can disrupt all users if done carelessly. This page covers change management practices that keep the network stable and community trust intact. 

 Why Change Management Matters 
 Unlike a traditional IT network with change control systems, community mesh networks are informal. A single operator changing the channel name or PSK on a key repeater can silently disconnect all users who have that repeater in their channel config. Changes that seem small to one operator can have large effects on the whole network. 

 Changes That Require Community Coordination 
 
 Change Type Impact Required Notice 
 
 Channel name or PSK change All users on that channel lose connectivity until they update Required - announce in advance, coordinate cutover time 
 Modem preset change All nodes on different preset cannot hear this repeater Required - network-wide coordination needed 
 Frequency slot change Same as preset change Required 
 Hop limit change (reduce) May isolate edge nodes from network core Recommended 
 Node role change Affects routing if changing to/from Router Recommended 
 Firmware update (minor) Minimal - backward compatible Good practice to announce 
 Firmware update (major) May affect interoperability with older nodes Required for key infrastructure 
 Node taken offline (temporary) Routing reroutes; may cause gaps Recommended - notify community 
 Node permanently removed Route cache entries become stale Required - update network documentation 
 
 

 Change Communication Channels 
 Establish at least one out-of-band (non-mesh) communication channel for network announcements: 
 
 Community Discord server with a #network-changes channel 
 Signal or Telegram group for operators 
 Email list for major announcements 
 Ham radio net for ARES-affiliated networks 
 
 Announce significant changes at least 48 hours in advance for planned maintenance. Emergency changes (a node causing harm to the network) can happen immediately but should be communicated as soon as possible. 

 Testing Changes Before Deploying 
 
 Test configuration changes on a non-critical node first (a personal portable node, not the main community repeater) 
 Verify the change works as expected with a test partner node 
 Document the before-and-after configuration 
 Have a rollback plan: know how to undo the change if it causes problems 
 Apply to production during low-traffic hours 
 

 Maintaining a Network Configuration Ledger 
 Keep a simple spreadsheet or wiki page with current configuration for every community node: 
 
 Node name and operator 
 Physical location 
 Current firmware version 
 Channel configuration (name, PSK, preset) 
 Role setting 
 Last configuration change date and who made it 
 
 This ledger prevents "mystery configuration" situations where no one knows why a node is behaving unexpectedly because the original operator is no longer reachable.