Eclipse Mosquitto is a lightweight, open-source message broker that routes MQTT packets between IoT sensors and central servers using a publish-subscribe architecture. If you are building a fleet of ESP32 temperature sensors or wiring a Raspberry Pi smart home hub, Mosquitto is the software traffic cop sitting in the middle, ensuring data gets from your edge devices to your dashboard without the massive overhead of HTTP. It fundamentally changes a real IoT installation by replacing constant, battery-draining polling with asynchronous, event-driven messaging. A common mistake is confusing Mosquitto with the MQTT protocol itself: MQTT is the set of rules (the language), while Mosquitto is the actual server software (the post office) that speaks it.
Before diving into the architecture, it helps to see how Mosquitto stacks up against other brokers you might encounter when sizing a Raspberry Pi or local server for your IoT fleet.
| Broker Software | Idle RAM Footprint | Max Concurrent Connections | Protocol Support | Best Use Case |
|---|---|---|---|---|
| Eclipse Mosquitto | ~15 MB | ~20,000 (hardware dependent) | MQTT 3.1.1, 5.0, WebSockets | Raspberry Pi, Home Assistant, local edge hubs |
| HiveMQ (Community) | ~250 MB (JVM) | Unlimited (licensed) | MQTT 3.1.1, 5.0 | Enterprise Java environments, massive cloud scale |
| EMQX (Open Source) | ~100 MB (Erlang VM) | 1,000,000+ | MQTT 3.1.1, 5.0, CoAP, LwM2M | High-throughput cloud IoT platforms, smart city grids |
| Adafruit IO (Cloud) | N/A (Managed SaaS) | Restricted by tier | MQTT 3.1.1, REST | Quick prototyping, hobbyists avoiding local server maintenance |
The Publish-Subscribe Architecture in Practice
In a traditional point-to-point network, if your central dashboard wants to know the temperature of five different rooms, it must send an HTTP GET request to each ESP32's IP address and wait for a response. This is called polling. It requires every sensor to have a web server running, keeps the Wi-Fi radio active, and drains batteries rapidly.
Mosquitto flips this model using Publish-Subscribe (Pub/Sub). Your ESP32 sensors are publishers. Your Home Assistant dashboard is a subscriber. Neither knows the IP address of the other. They only know the address of the Mosquitto broker.
home/kitchen/temperature. The post office (Mosquitto) looks at its routing table, sees that your phone app (receiver) has subscribed to the home/kitchen/# route, and delivers the letter. The sender and receiver never interact directly, which decouples your hardware from your software.
This decoupling changes how you wire and code your installations. You no longer need to hardcode IP addresses into your ESP32 firmware. If your Raspberry Pi server changes IP addresses, you only update the broker address in your devices, and the entire mesh continues to function. Furthermore, Mosquitto supports Retained Messages. If a sensor publishes a temperature reading and goes to deep sleep, Mosquitto holds that last known value. When your dashboard boots up an hour later, it instantly receives the retained message rather than showing a blank state.
Payload Math: Mosquitto vs. HTTP REST Polling
To understand why Mosquitto is the default choice for battery-powered edge devices, we need to look at the actual byte-level overhead on the wire. Let us run a worked numeric example for an ESP32 sending a 5-byte temperature payload (22.5C) to a local server every 60 seconds.
Scenario A: HTTP GET Polling
If the server polls the ESP32 via HTTP, the ESP32 must host a web server. A minimal HTTP response includes the payload plus mandatory headers:
- HTTP Headers:
HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\nContent-Length: 5\r\nConnection: close\r\n\r\n(Approx. 85 bytes) - TCP/IP Handshake: SYN, SYN-ACK, ACK (Approx. 120 bytes overhead per connection)
- Payload:
22.5C(5 bytes) - Total per transaction: ~210 bytes
Scenario B: Mosquitto MQTT Publish (QoS 0)
If the ESP32 wakes up and publishes to Mosquitto using Quality of Service 0 (fire and forget):
- MQTT Fixed Header: 2 bytes
- Topic Name:
home/lab/temp(13 bytes + 2 bytes for length prefix = 15 bytes) - Payload:
22.5C(5 bytes) - Total per transaction: 22 bytes
By switching from HTTP polling to Mosquitto MQTT, you reduce the network payload from 210 bytes to 22 bytes—an 89% reduction in bandwidth. Over a 24-hour period (1,440 transmissions), the HTTP method pushes ~302 KB of data, while Mosquitto pushes just ~31 KB. For an ESP32 running on a 2000mAh LiPo battery, this drastic reduction in Wi-Fi radio transmit time is often the difference between a device that lasts three days and one that lasts three weeks.
Where You Meet Mosquitto in Practice
You will rarely interact with Mosquitto via a graphical user interface. It is a headless background service (daemon) that operates silently. Here is where it physically and logically lives in modern IoT stacks:
1. Home Assistant and Smart Home Hubs
If you run Home Assistant on a Raspberry Pi 4 or an Intel NUC, the official MQTT Add-on is literally just a Dockerized wrapper around Eclipse Mosquitto. When you configure Zigbee2MQTT or Z-Wave JS to push device states to Home Assistant, Mosquitto is the bridge translating those RF mesh signals into standard MQTT topics that your automations can read.
2. ESP32 and Arduino Firmware
When writing firmware for an ESP32-WROOM-32, you will use libraries like PubSubClient or the asynchronous AsyncMqttClient. You point the library to your Mosquitto server's IP and port.
3. Raspberry Pi Edge Servers
For standalone industrial or agricultural monitoring where internet access is unreliable, you can install Mosquitto directly on a Raspberry Pi using the package manager (sudo apt install mosquitto mosquitto-clients). The Pi acts as the local broker, logging sensor data to a local SQLite database or InfluxDB instance via a Node-RED subscriber, ensuring your data pipeline survives internet outages.
Common Confusions and Edge Cases
Is Mosquitto the same thing as MQTT?
No. MQTT (Message Queuing Telemetry Transport) is the protocol—the standardized set of rules defining how packets are formatted and routed. Eclipse Mosquitto is a specific software application (a broker) that implements those rules. You can use the MQTT protocol with other brokers like HiveMQ or EMQX, but Mosquitto is the most popular open-source implementation for edge computing.
What are QoS levels and how does Mosquitto handle them?
Quality of Service (QoS) defines the delivery guarantee between the publisher, the broker, and the subscriber. Mosquitto strictly enforces these rules:
- QoS 0 (At most once): Fire and forget. Mosquitto routes the packet once. If a Wi-Fi packet drops, the data is lost. Use this for high-frequency temperature readings where a missed packet is irrelevant.
- QoS 1 (At least once): Mosquitto guarantees delivery but may send duplicates. The ESP32 must acknowledge receipt (PUBACK). Use this for state changes like a smart lock status.
- QoS 2 (Exactly once): A complex four-part handshake ensuring no duplicates and no losses. Use this sparingly (e.g., financial metering or chemical dosing), as it adds significant latency and battery drain.
Why isn't my ESP32 receiving the last message when it wakes up?
This is usually a failure to use Retained Messages. When your ESP32 publishes a payload to Mosquitto, it must explicitly set the retain flag to true (e.g., client.publish("home/temp", "22.5", true);). Mosquitto will then store that specific payload in RAM. When your ESP32 wakes from deep sleep and reconnects, Mosquitto instantly pushes the retained payload before any new data is generated.
Does Mosquitto store historical data?
No. Mosquitto is a message router, not a database. It only holds data in volatile memory for active subscribers or retained flags. If you need to graph historical temperature trends over a month, you must set up a separate subscriber (like Telegraf, Node-RED, or a custom Python script) that listens to the Mosquitto topics and writes the incoming payloads to a time-series database like InfluxDB.
