Meshtastic MQTT Overview

Meshtastic's MQTT module extends a LoRa mesh network over the internet by bridging packets between the radio air interface and an MQTT message broker. A gateway node - a Meshtastic device with a working Wi-Fi or Ethernet connection - uplinks packets it hears over LoRa to the broker and optionally downlinks packets received from the broker back to the local mesh. This page explains the architecture, the public broker, and the trade-offs of the approach.

What MQTT Does in Meshtastic

MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe protocol designed for constrained devices and unreliable networks. In the Meshtastic context it serves as the internet backbone that connects isolated mesh islands:

• Uplinking - the gateway node listens for LoRa packets from nearby nodes, re-serialises them as MQTT payloads, and publishes them to the broker under a well-known topic hierarchy (msh/<region>/<channel>/<node_id>).
• Downlinking - the gateway subscribes to the same topic hierarchy; when the broker delivers a message published by a gateway in another location, the local gateway broadcasts it over LoRa to its nearby mesh.

The net effect: two mesh islands in different cities share a common channel as if they were on the same local RF network - provided both have an internet-connected gateway and use the same channel encryption key.

Public MQTT Server: mqtt.meshtastic.org

The Meshtastic project operates a community MQTT broker at mqtt.meshtastic.org on port 1883 (unencrypted) and port 8883 (TLS). This server is free to use for experimentation and for joining the global mesh.

• Anonymous access - no credentials required to connect to the public broker.
• No privacy guarantee - any message published to the public broker is visible to anyone who subscribes to the same topic.
• Unencrypted at the MQTT layer - if you use the default channel key (AQ== / all-zeros), your messages are readable by any MQTT subscriber. Always configure a custom channel key for any sensitive or private use.

Privacy note: Even with a strong channel key, MQTT metadata (sender node ID, timestamp, GPS coordinates if position sharing is enabled) may be visible to the broker operator and any subscriber on the same root topic. Use a self-hosted broker for sensitive deployments.

Self-Hosted Broker Option

For deployments requiring privacy, control, or reliability guarantees, run your own MQTT broker (Eclipse Mosquitto is the standard choice). A self-hosted broker lets you:

• Require authentication (username + password or TLS client certificates).
• Restrict topic access with ACLs.
• Enable TLS on port 8883 with a Let's Encrypt or self-signed certificate.
• Bridge your private broker to the public one selectively.
• Log and retain messages for audit or replay.

MQTT Topic Hierarchy

Meshtastic publishes to a structured topic hierarchy:

msh/<region>/2/e/<channel_name>/!<node_id_hex>

Examples:

msh/US/2/e/LongFast/!abcd1234
msh/EU_868/2/e/MyCommunity/!1a2b3c4d

• msh - root topic for all Meshtastic traffic.
• <region> - geographic region prefix (US, EU_868, AU_915, etc.).
• 2/e - protocol version 2, encrypted payload.
• <channel_name> - the channel name configured on the node (e.g. LongFast, MyCommunity).
• !<node_id_hex> - the 8-character hexadecimal node ID of the sender.

The payload is a base64-encoded protobuf ServiceEnvelope containing the encrypted MeshPacket. Only devices that share the same channel key can decrypt the inner packet.

Uplink vs. Downlink

Direction	What it does	When to enable
Uplink	Sends LoRa packets heard locally to the MQTT broker	Always on for a gateway node
Downlink	Receives packets from the broker and broadcasts them over LoRa	When you want the local mesh to hear remote traffic

Caution with downlink: enabling downlink on multiple gateways in the same RF coverage area causes duplicate transmissions and wasted air time. In a coverage area with more than one gateway, designate a single gateway for downlink and disable it on the others.

JSON vs. Protobuf Payload Formats

Meshtastic supports two payload formats on MQTT:

• Protobuf (default) - binary-encoded, compact, but requires a protobuf decoder to read. This is the format used by actual Meshtastic devices and by the public broker.
• JSON - human-readable, easier to consume by Node-RED, Home Assistant, scripts, etc. Published to a parallel topic msh/<region>/2/json/<channel>/!<node_id>. Enable in the Meshtastic app under MQTT → JSON output.

JSON mode is ideal for integration work but produces larger payloads. Disable it on resource- constrained brokers with many active nodes.

Common Use Cases

• Global channel bridging - join your local LongFast mesh to the worldwide LongFast MQTT cloud.
• Remote node monitoring - a solar-powered node deep in the field uplinks its telemetry (battery voltage, environment sensor data) to MQTT; you query the broker from home.
• Alert forwarding - a Node-RED flow subscribes to MQTT, detects specific messages, and forwards them to Telegram or Discord.
• Mesh analytics - pipe MQTT JSON output into InfluxDB/Grafana for network coverage and message delivery statistics.