MQTT for Beginners — The Protocol That Powers Most Real AIoT Systems

When I built my first IoT project, devices communicated with an HTTP API. My temperature sensor made a POST request every minute. The dashboard polled an endpoint every ten seconds. This worked, barely, but it was slow, battery-hungry, and didn't scale past a handful of devices.

Then I learned MQTT and understood why it dominates the IoT protocol space.

What MQTT Actually Is

MQTT is a publish-subscribe messaging protocol designed for constrained devices and unreliable networks. Instead of direct device-to-device communication, devices connect to a central broker. Publishers send messages to named topics. Subscribers receive messages on topics they've subscribed to.

The broker is the only persistent connection — devices can connect briefly, publish or subscribe, and disconnect. The overhead of an MQTT message is as low as 2 bytes. Compare that to an HTTP request with kilobytes of headers for every communication.

• Broker model: all devices connect to one central broker
• Topics are like channels: 'home/living-room/temperature', 'plant/moisture/sensor-1'
• Publishers send to a topic; all subscribers to that topic receive the message
• QoS levels: 0 (fire and forget), 1 (at least once), 2 (exactly once)
• Retained messages: broker stores last message, new subscribers get it immediately

Why It's Better Than HTTP for IoT

HTTP is request-response: your device asks, the server answers. MQTT is event-driven: something changes, everything interested is notified immediately. For IoT, the second model is almost always correct. Your temperature sensor doesn't want to poll an endpoint — it wants to say 'temperature changed' and have every interested party know.

Battery efficiency is dramatically better. An ESP32 publishing an MQTT message uses roughly 1/10th the energy of making an equivalent HTTP request, because the connection overhead is amortized across many messages (keep-alive connection) rather than paid per request.

HTTP is a conversation. MQTT is a broadcast. IoT devices almost always need to broadcast, not converse.

Setting Up a Local Broker in Bangalore

The standard local MQTT broker is Mosquitto — free, open-source, runs on Raspberry Pi. Install with apt, configure authentication (don't run an open broker on your network), and it handles hundreds of connections with minimal resources.

For cloud MQTT with a free tier, HiveMQ Cloud and EMQX Cloud have free tiers that cover hobby projects. These are useful for remote access to your home system — your devices publish to the cloud broker, and you subscribe from your phone wherever you are.

The Topic Design Decision

MQTT topic design matters for maintainability. The convention is hierarchical: location/device-type/device-id/measurement. Example: home/sensor/living-room-temp/celsius. This lets you subscribe to home/# for everything at home, or home/sensor/+/celsius for all temperature readings, or a specific device.

Design your topics before you start. Renaming them later means updating firmware on every device, which is painful.