What is MQTT? The messaging protocol behind most IoT sensor platforms

If you have looked at almost any IoT sensor spec sheet, you have run into the acronym MQTT. It shows up next to LoRaWAN, cellular, and HTTP as one of the ways a device can get its readings off-site. Unlike those other options, MQTT is not a radio technology or a transport, it is a messaging protocol: a set of rules for how a device announces "here is a reading" and how anything interested in that reading finds out about it, without either side needing to know much about the other.

Publish and subscribe, not request and response

The core idea behind MQTT is publish/subscribe. A sensor does not call up a server and ask "do you want my reading?" the way a browser requests a web page. Instead, it connects once to a broker (the always-on server in the middle) and publishes its readings to a topic, a named channel like site-42/vibration/device-7. Anything that wants those readings, a dashboard, an automation flow, a database writer, subscribes to that topic and receives every message the moment it is published. The sensor never needs to know who, if anyone, is listening.

This decoupling is the whole point. A sensor manufacturer building a battery-powered device does not want to implement a web server, manage incoming connections, or handle retries from every system that might want its data. It wants to open one lightweight connection, publish a small message, and go back to sleep to save power. MQTT was designed from the ground up for exactly that constraint.

Why MQTT beats polling for sensor data

The alternative most people reach for first is HTTP: have the sensor call an API endpoint, or have a server poll the sensor’s API on a schedule. This works, and Nodenet supports it for devices that only speak REST. But it has real costs at sensor scale. Polling means either missing changes between polls or polling so frequently that you are mostly making requests that return "nothing new." Every poll is a fresh HTTP handshake: TCP connection, TLS negotiation, headers, all repeated for what is often a single number.

MQTT keeps one persistent, lightweight connection open and pushes data the instant it exists. There is no polling interval to tune, no missed readings between polls, and the per-message overhead is a few bytes of header rather than a full HTTP request. On a cellular or LoRaWAN-backed connection where every byte and every radio wake-up costs battery, that difference is not cosmetic, it is the difference between a sensor lasting a year on a battery and lasting a month.

Quality of service and why it matters on flaky networks

Construction sites, farms, and remote installations do not have reliable WiFi. MQTT was built with this in mind: every message can be published at one of three quality-of-service levels, from "send it and don’t worry about it" up to "guarantee it arrives exactly once, even if the connection drops mid-publish." A vibration threshold breach on a structural sensor is exactly the kind of message you want delivered with a guarantee, even if the device’s connection cuts out for ten seconds right as it happens. That reliability is built into the protocol, not something every device manufacturer has to reinvent.

A real example: alerting a site team the moment a threshold is crossed

Take a noise sensor monitoring a demolition site. It publishes a reading to its topic every few seconds. An automation flow (see our Node-RED explainer) is subscribed to that same topic, and the moment a reading crosses the site’s threshold, it fires a notification, no polling loop checking "has anything changed" every few seconds, just an instant reaction the moment the message is published. The same reading is also being written to storage and rendered on a live Grafana dashboard, all subscribed to the same MQTT topic independently.

How this fits into a multi-tenant platform

A shared broker used by many organisations only works safely if every tenant’s topics, credentials, and traffic stay separate. Nodenet sidesteps that problem entirely: every tenant, on every tier, gets its own broker instance in its own isolated namespace from day one, not a shared broker with per-device credentials layered on top.

• MQTT is a publish/subscribe protocol, not a request/response one: devices publish once, anything subscribed receives it instantly
• It keeps one lightweight, persistent connection open instead of repeating a full HTTP handshake per reading
• Quality-of-service levels let you choose "best effort" or "guaranteed delivery" per message
• It is the default choice for battery-powered, cellular, or otherwise unreliable-network sensors
• A broker like Mosquitto sits in the middle: sensors publish to it, dashboards and automation subscribe to it

MQTT is one piece of the wider ingestion, storage, dashboard, and automation stack. See our IoT stack overview for how it connects to everything else, or our integrations page for the full list of protocols Nodenet supports.