MQTT Protocol Basics & Architecture

Welcome to the MQTT Basics Guide! If you are stepping into the world of the Internet of Things (IoT), smart home automation, or embedded systems, MQTT is a term you will encounter everywhere.

In this guide, we will break down MQTT in a simple, intuitive, and human-friendly way—explaining how it works, its architecture, and why it is so widely used.

---

🧐 What is MQTT?

MQTT stands for Message Queuing Telemetry Transport. It is an extremely lightweight and simple network protocol designed for sending messages between devices.

It was created in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom). Their goal was to monitor oil pipelines via satellites under harsh constraints. They needed a protocol that would be:

1. Low Bandwidth: Efficient enough to work over slow, unstable, or expensive satellite links.
2. Low Power: Suitable for remote sensors running on batteries.
3. Low Footprint: Simple enough to run on tiny microcontrollers with very limited memory and CPU power (like the ESP8266 or ESP32).

---

🔄 The Publish-Subscribe Pattern

Standard web applications rely on the Request-Response model (HTTP), where a client (like your web browser) asks for a page and the server sends it back.

MQTT operates on a decoupled Publish-Subscribe (Pub-Sub) model. Instead of communicating directly with each other, clients exchange messages through a central mediator called a Broker.

🏠 The YouTube Analogy

To understand Pub-Sub, think of how YouTube channels work:

• The Creator (Publisher): Uploads a video under a specific channel or category.
• YouTube (The Broker): Receives the new video, manages subscriptions, and hosts the content.
• The Viewer (Subscriber): Clicks the "Subscribe" button on a channel. Whenever a new video is uploaded, YouTube automatically delivers a notification to the viewer.

The viewer doesn't need to constantly ask the creator, "Have you uploaded a new video yet?". The broker (YouTube) handles the delivery.

---

🎨 MQTT Architecture Diagram

Here is a visual representation of how MQTT clients and brokers interact:

Key Terminology:

1. MQTT Client: Any device (such as an ESP32, Raspberry Pi, server, or smartphone app) that connects to an MQTT broker to send or receive data.
2. MQTT Broker: The central server. It receives all incoming messages, filters them by topic, and forwards them to the appropriate subscribers. Examples include Mosquitto, HiveMQ, EMQX, and Adafruit IO.
3. Publish (Pub): The act of a client sending data to the broker. For example, a temperature sensor publishes 25°C to a topic.
4. Subscribe (Sub): The act of a client telling the broker it wants to receive messages from a specific topic. For example, a mobile app subscribes to monitor temperature updates.
5. Topic: A text string that represents the address/path of a message (e.g., home/livingroom/temperature). It acts like a folder path to organize messages.

---

📊 MQTT vs. HTTP (Comparison)

Why don't we just use HTTP for all IoT devices? Let's compare the two protocols:

---

🚀 What's Next?

Now that you understand the basic architecture, let's dive deeper into how messages are categorized and delivered reliably using Topics, Wildcards, and Quality of Service (QoS).