MQTT

There is a protocol that sits quietly underneath a significant proportion of the world’s IoT infrastructure, moving data between sensors and servers and dashboards without anyone much noticing it is there. It is not glamorous. It does not have a marketing budget. It has been around since 1999, which in internet years makes it practically ancient. And yet if you are building anything involving sensors, radio networks, or home automation, you will almost certainly end up using it.

MQTT. Message Queuing Telemetry Transport. A name that tells you almost nothing useful about what it actually does.

What it actually does

MQTT is a publish/subscribe messaging protocol. The publish/subscribe model is worth understanding properly because it is meaningfully different from the request/response model that most people encounter first through the web.

In a request/response model, one thing asks and another thing answers. Your browser asks for a web page, the server returns it. The relationship is direct and symmetrical. It works when both parties are available at the same time and when the requester knows exactly who to ask.

In a publish/subscribe model, things are decoupled. A sensor publishes a temperature reading. It does not care who is listening. A home automation system, a database, a dashboard, and an alerting service might all be listening. All of them receive the reading. None of them needed to ask for it. The sensor does not need to know they exist.

The thing that makes this possible is a broker. The broker sits in the middle, receives published messages, and routes them to anyone who has subscribed to the relevant topic. Topics are hierarchical strings that work a bit like folder paths: home/office/temperature, mesh/EU_868/sensor/battery, garden/soil/moisture. Publishers write to topics. Subscribers read from topics. The broker handles everything in between.

MQTT was designed for satellite links and oil pipelines in the late 1990s. Constrained environments, unreliable connections, bandwidth measured in kilobits. It has aged extraordinarily well because those constraints never went away. They just moved to a billion small sensors.

Why it matters for this setup

I have been building out a self-hosted network across three sites in Greater Manchester. The pieces are coming together: Ubiquiti routers, a homelab server on the way, MeshCore nodes for off-grid mesh communication, and eventually LoRaWAN sensors for environmental monitoring. The question of how all of these things talk to each other keeps coming back to the same answer: MQTT.

Here is the problem it solves. A temperature sensor in my back garden transmits a reading over LoRaWAN. The LoRaWAN gateway receives it. Now what? The reading needs to get to a database for logging, to a dashboard for display, and potentially to a home automation system for triggering something. Without a common messaging layer, I am writing custom integrations between every pair of things. With MQTT, the gateway publishes to a topic, and anything that cares subscribes. New consumers can be added without changing the gateway. The architecture stays clean.

MeshCore has native MQTT integration. A stationary MeshCore node with a network connection, exactly the kind of thing that will live in the homelab, can act as a gateway: receiving messages from the mesh over LoRa and publishing them to MQTT topics on a local broker. From there, Home Assistant, Node-RED, InfluxDB, Grafana, Telegram notifications, all of it can consume mesh messages without touching the radio layer at all. The mesh does its thing. MQTT carries it into the broader infrastructure.

LoRaWAN networks work the same way. The network server (ChirpStack, in the self-hosted world) receives uplinks from sensors and publishes them via MQTT. Every sensor reading becomes a JSON message on a topic. Every downlink command starts as a message published to the right topic. The application layer, whatever it is, never needs to understand LoRaWAN framing or radio physics. It just reads from and writes to MQTT topics.

The broker

The broker is the piece of infrastructure that makes all of this work. The standard self-hosted choice is Mosquitto, from the Eclipse Foundation. It is mature, lightweight, runs comfortably on a Raspberry Pi or a homelab LXC container, and supports TLS and username/password authentication. There are also hosted options for when local infrastructure is not the right answer for a particular deployment, but for a self-hosted setup with the server section of this series in progress, a local Mosquitto instance is the correct call.

A broker running on the homelab becomes a central message bus for the whole network. Every sensor, every gateway, every consumer connects to it. Topics are cheap. Subscribers are cheap. The model scales from a single sensor to thousands without fundamental architectural changes.

What is coming in this series

This is the introduction. What follows is a series of posts working through the practical implementation:

The broker: Installing and securing Mosquitto on the homelab. TLS configuration, authentication, topic permissions. Getting something running that the rest of the infrastructure can trust.

MeshCore integration: Configuring a MeshCore node as an MQTT gateway. What topics look like, what the JSON payload contains, and how to subscribe to mesh messages from other systems.

ChirpStack and LoRaWAN: How the LoRaWAN network server publishes sensor data via MQTT. The topic structure, the payload format, and how to get sensor readings into a database.

Node-RED: The visual wiring layer that sits between MQTT and everything else. Transforming payloads, triggering automations, routing messages to multiple destinations.

Grafana and InfluxDB: Storing time-series data from sensors and visualising it. Battery levels, temperatures, GPS tracks, all of it in a dashboard that does not require poking at a command line.

Alerting: Publishing to a Telegram bot or Pushover when something interesting happens on the mesh or when a sensor reading crosses a threshold.

Each post in the series builds on the previous ones. By the end, the homelab is a proper IoT hub: receiving data from MeshCore and LoRaWAN sensors, storing it, visualising it, and acting on it, all running on infrastructure I own and control.

A note on why bother

There is a version of this that lives entirely in the cloud. Sensors talk to a vendor platform, a vendor dashboard shows the data, vendor APIs let you build integrations. It works. For many people it is the right answer.

For me, the whole point is that the data stays on my infrastructure. A temperature reading from my back garden is not sensitive information by any reasonable definition, but the habit of routing everything through someone else’s platform, accepting their terms, depending on their uptime, is one I have been deliberately moving away from. MQTT running on a local broker is part of the same instinct that runs through everything else in this series: own the infrastructure, understand the tools, do not depend on systems you cannot see or control.

The protocol is 25 years old. It will outlast whatever cloud platform would otherwise be handling this.