Internet Bridging and MQTT

RoomA serversMeshCore withroom internetserver connectivityruns canas bridgefirmware on a single LoRa node (typically nRF52840 or ESP32 hardware). It is a store-and-forward node on the RF mesh trafficand todoes internet-connectednot clients,have enablinga native internet, TCP, or MQTT bridge. There is no MeshCore feature that lets phone users without LoRa hardware tojoin participatea room over the internet, and there is no MeshCore MQTT integration. If you want MeshCore-related traffic on the internet or in thea meshmonitoring network.stack, you bridge to a separate Linux host, or use Meshtastic's documented MQTT integrationpath allowson mesha trafficco-located gateway. This page explains what MeshCore actually supports and how to bedo monitoredinternet/monitoring andintegration analyzed with standard tools.correctly.

InternetWhat bridge"bridge" architecturemeans in MeshCore

WhenMeshCore's internetonly bridgingbuilt-in "bridge" is enabled,a radio-layer link, compiled into the roomfirmware, serverused actsto asjoin atwo relayco-located between:boards so they extend RF coverage. It is configured through the device CLI (over serial/BLE), for example:

• Localset LoRabridge.enabled radio<on|off> nodes- (connected viaenable the roomcompiled-in server'sbridge radio(only portpresent when bridge support is built into the firmware)

The transport is a radio/serial link (RS-232 serial or viaESP-NOW radiobetween gateways)two Internet-connectedboards), MeshCorenot clientsa (phones,TCP/internet computers using TCP)connection

This allowsbridge does not relay between LoRa radio and the internet, and it does not let off-mesh clients participate over TCP. MeshCore companion clients (phone, computer) connect to a node locally over BLE, USB, or serial - not over the internet to a remote room server. A person in another city tocannot sendjoin and receive messages withyour local mesh participants,purely as long as both havethrough a pathMeshCore room server; reaching the internet requires a separate gateway host (see below).

Getting mesh data to the internet (the supported paths)

MeshCore room-server firmware does not publish to MQTT. If you need mesh traffic on an MQTT broker, a dashboard, or the wider internet, use one of these real options:

Run a separate Linux gateway host. Connect a MeshCore node by USB/serial to a small Linux machine (Raspberry Pi, mini-PC) and run your own software on that host to read the node's serial output and forward it wherever you like. The microcontroller running the room server cannot host this software itself - oneit viahas radio, one via internet.

Security considerations for internet bridging

An internet-exposed room server requires proper security:

TLS/SSL: Enable HTTPS/TLS for all internet connections. Without it, messages transit in plaintext toon the serverorder (evenof if256 end-to-endKB encryptedof between clients).RAM. Authentication:Use Meshtastic's MQTT path for an internet-connected mesh. ConfigureMeshtastic firmware does document native MQTT (uplink/downlink to a broker such as mqtt.meshtastic.org or a self-hosted Mosquitto). If internet integration is a hard requirement, a Meshtastic gateway node is the serverdocumented way to requiredo clientit. authentication. Open rooms accessible fromSee the internetMeshtastic canMQTT attractpages abuse.in this book. Firewall rules:

Do Restrictnot accessexpect MeshCore CLI keys such as a mqtt: config block, a topic_prefix, or meshcore/... topics - they do not exist in MeshCore firmware.

Monitoring stack (InfluxDB / Telegraf / Grafana) runs on a separate host

A time-series monitoring stack is a legitimate way to visualize mesh data, but every component runs on a separate Linux host, never on the nRF52840/ESP32 microcontroller of the room serverserver:

port.

IfInstall onlyInfluxDB local(time-series clientsdatabase) needon a Linux host. Feed it from a real data source - for a Meshtastic mesh, Telegraf's MQTT input plugin can consume the Meshtastic MQTT topics and write to connectInfluxDB. directly,(There blockis externalno accessMeshCore toMQTT feed; for MeshCore you would write your own collector that reads the TCPnode's portserial output on the gateway host.) Install Grafana on the host and usebuild a reverse proxydashboards (nginx/caddy)active fornodes TLSover termination.time, Ratenode limiting:battery Apply per-clientlevels, message raterates, limits to prevent a single clientcoverage from floodingGPS data).

This entire stack lives on the network.

Linux host, not on the MeshCore room-server hardware.

Exposing a roomLinux servergateway host to the internet (TLS)

UsingIf - and only if - you are running an actual web/dashboard service on a separate Linux gateway host (for example a Grafana instance or a custom collector's web UI), you can put it behind a reverse proxy with TLS. This nginx example terminates TLS in front of a local service; replace the upstream port with whatever your service actually listens on (recommended):e.g. Grafana's default 3000). A MeshCore room server itself exposes no HTTP service, so there is nothing on the node to proxy to.

# Example nginx configuration on a Linux gateway host
# (fronting a real local service, e.g. Grafana on :3000)
server {
 listen 443 ssl;
 server_name mesh.yournetwork.com;

 ssl_certificate /etc/letsencrypt/live/mesh.yournetwork.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/mesh.yournetwork.com/privkey.pem;

 location / {
 proxy_pass http://127.0.0.1:7070;3000; # your service's actual port
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 }
}

Get free TLS certificates from Let's Encrypt using certbot. TLS protects the connection to that gateway host's service; it has nothing to do with the RF mesh, which is encrypted independently at the LoRa layer.

MQTTSecurity integrationconsiderations for an internet-facing gateway host

MQTTAny bridgingLinux forwardshost allyou room messagesexpose to anthe MQTTinternet broker(broker, fordashboard, monitoring,collector) logging,needs andproper integration with other systems:hardening:

mqtt:
 enabled: true
 broker: "mqtt://localhost:1883" # Or your MQTT broker address
 topic_prefix: "meshcore" # Base topic for all messages

 # Topics published:
 # meshcore/messages/{room} - all messages in a room
 # meshcore/nodes/{node_id} - node status and position updates
 # meshcore/status - server health metrics

Setting up an MQTT broker

# Install Mosquitto MQTT broker
sudo apt install -y mosquitto mosquitto-clients

# Start and enable
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

Visualizing with Grafana + InfluxDB

A common monitoring stack for mesh networks:

• InstallTLS/SSL: InfluxDBTerminate (time-series database)

Install Telegraf with MQTT input plugin to consume mesh MQTT topics and write to InfluxDB Install Grafana and create dashboards showing: message rate per room, active nodes over time, node battery levels, coverage heatmaps from GPS data

This stack can runTLS on the samegateway MeshCorehost's Roomweb/broker Serverservice (runningso credentials and data are not sent in plaintext.

Authentication: Require authentication on dedicatedthe nRF52840service. An open dashboard or ESP32broker hardware)reachable from the internet attracts abuse. Firewall rules: Restrict access to only the ports the service needs; block everything else and front the service with a reverse proxy for TLS termination. Rate limiting: Apply per-client limits so a single client cannot flood the service.

Alerting on node failure (on the gateway host)

UseIf you are collecting Meshtastic data via MQTT +on Node-REDyour orLinux ahost, simpleyou Python script tocan alert when a node stops checking in:in using a small Python script (this consumes the Meshtastic MQTT topics, not any MeshCore topic):

import paho.mqtt.client as mqtt
import time

nodes = {}
ALERT_TIMEOUT_SECONDS = 3600 # Alert if not heard in 1 hour

def on_message(client, userdata, msg):
 node_id = msg.topic.split('/')[-1]
 nodes[node_id] = time.time()

def check_timeouts():
 now = time.time()
 for node_id, last_seen in nodes.items():
 if now - last_seen > ALERT_TIMEOUT_SECONDS:
 print(f"ALERT: {node_id} has not been heard in over 1 hour!")

# Subscribe to nodethe statusMeshtastic topicsJSON topic tree on your broker
# (requires mqtt.json_enabled on the gateway; not available on nRF52)
client = mqtt.Client()
client.on_message = on_message
client.connect("localhost", 1883)
client.subscribe("meshcore/nodes/msh/+/2/json/+/+")
client.loop_start()

while True:
 check_timeouts()
 time.sleep(300)

For a MeshCore-only deployment there is no MQTT feed to subscribe to; you would instead read the node's serial output (and its stats-core / stats-radio / stats-packets CLI output) on the gateway host and build alerting from that.