MQTT Protocol Explained for ESP32

1. Introduction

MQTT (Message Queuing Telemetry Transport) is one of the most widely used communication protocols in the Internet of Things (IoT) world. It powers everything from home automation systems to industrial sensor networks, and it is the go-to choice for ESP32-based projects that need to send or receive data over Wi-Fi.

2. Understanding Traditional Client-Server Communication

Before diving into MQTT, it helps to understand how a normal client-server connection works. In this model, a server is a program that stores and manages data, while a client is a device or program that connects to the server to send or request data.

When Client 1 sends data, the server stores it temporarily or permanently. If Client 2 later wants that same data, it must send a request to the server, which then looks up the stored data and replies. This works well for small, simple applications, and the speed of communication depends on the underlying protocol — for example, a raw TCP socket connection is much faster than an HTTP-based request.

3. The Problem: Scaling to Many Devices

Now imagine a scenario with one server and hundreds — or even thousands — of clients, all wanting access to data from one another. Every client would need to request data individually from every other client, creating a tangled, inefficient mesh of connections.

This is exactly the kind of scenario where a smarter communication model is needed — and that is where MQTT comes in.

4. How MQTT Solves This: The Broker Model

MQTT follows the same basic client-server idea, but changes the roles and terminology to make communication far more efficient:

• Broker — replaces the traditional "server". It does not permanently store data by default; instead, it instantly relays messages between devices.
• Publisher — a client that sends (publishes) data to the broker.
• Subscriber — a client that registers interest in certain data and receives it automatically when published.
• Topic — a named channel (like temp or humidity) used to organize and route messages.

In this model, Client 1 (for example, an ESP32 with a DHT22 sensor) publishes temperature and humidity readings to two topics. Client 2, a mobile app, has subscribed to both topics, so it instantly receives both values. Client 3 has only subscribed to humidity, so it only receives that value — with no polling and no manual request required.

Publisher and Subscriber Are Not Fixed Roles

A single device can act as both a publisher and a subscriber at the same time. For example, an ESP32 might publish sensor readings on the temp and humidity topics, while simultaneously subscribing to an led topic to receive on/off commands from a mobile app.

5. Practical Example: ESP32 Weather Station with LED Control

Let's walk through a simple real-world scenario using the roles described above. Below is the conceptual flow of MQTT topics and messages — not full source code, but the sequence of commands/messages you would conceptually issue when working with an MQTT client library (such as PubSubClient on the ESP32).

Step 1 — Connect the ESP32 to the Broker

Step 2 — Publish Sensor Data

Step 3 — Subscribe to the LED Control Topic

Step 4 — Handle Incoming Messages

6. Summary

MQTT is often described as a lightweight publish/subscribe messaging transport, ideal for constrained devices like the ESP32 and unreliable or low-bandwidth networks. Its strength comes from three simple ideas:

• Broker-based routing — no direct device-to-device requests are needed.
• Topic-based filtering — devices only receive the data they actually subscribed to.
• Dual roles — any client can publish and subscribe simultaneously, enabling two-way communication (e.g., sensor reporting + remote control) over a single connection.