First, What Is It

• MQTT (Message Queuing Telemetry Transport): the IoT's favorite "bulletin board" protocol — devices post messages to a Topic and subscribers of that topic see them.
• Publish/subscribe: publishers and subscribers never know each other; a Broker forwards messages, naturally suiting device reporting and control.
• Runs over TCP: default port 1883; MQTTS is the encrypted version (8883).

Breaking Down the Principle

1. Roles and Topics

• Topic: the message "channel name", layered with /, e.g., home/room1/temp.
• Wildcards: + matches one level (temp/+); # matches many levels (temp/#).

2. Connection and Message Flow

3. QoS: Message Reliability Levels

QoS	Semantics	Acknowledgment	Use case
0	At most once	None, may lose	Real-time sensor data (loss tolerable)
1	At least once	PUBACK, may duplicate	Normal control commands
2	Exactly once	Four-way handshake, no loss/dup	Critical commands (billing, switches)

4. Keep-Alive, Last Will, and Retained Messages

• Keep Alive: the client sends heartbeats; the Broker declares it offline if none arrives in time.
• LWT (Last Will and Testament): the client pre-registers a message the Broker publishes if it dies — used for online-status monitoring.
• Retained messages: the Broker remembers the last message of a topic; new subscribers receive it immediately.

How the SDK Implements It

• Related pages: MQTT Connection, MQTTS Connection

SDK MQTT flow: connect Wi-Fi → open TCP → MQTT connect (CONNECT) → subscribe → loop send/receive:

/* Flow outline: server address, port, client ID */
/* After connecting, publish to a topic; incoming messages go to the callback */
mqtt_connect(server, port, client_id, username, password);  /* flow outline */
mqtt_subscribe("home/room1/temp", qos);
mqtt_publish("home/room1/temp", data, qos);

The publish/subscribe callback model turns "device reporting + phone control" into one codebase.

Common Exam & Interview Questions

Difference between MQTT and HTTP?

MQTT is publish/subscribe over long-lived connections with push — ideal for low bandwidth, weak networks, and many IoT devices; HTTP is request/response, suited to one-off resource fetching.

How to choose QoS 0/1/2?

QoS 0 for tolerable loss (high-frequency sensor data); QoS 1 for guaranteed delivery (normal commands); QoS 2 for no loss and no duplication (critical commands) at the highest overhead.

What is a Last Will message?

The client registers LWT at connect time; when it dies unexpectedly, the Broker publishes that message so other devices know it went offline — commonly used for online-status monitoring.

What does the Broker do in MQTT?

It receives publications, forwards them to subscribers by topic, and maintains connection states. Publishers and subscribers never talk directly, decoupling devices from each other.

How does a device stay "online"?

Keep-alive heartbeats (PINGREQ/PINGRESP) prove liveness; LWT announces offline status on timeout. Cloud platforms refresh device state from these.

Have questions?

For any other questions, visit the unified Q&A and discussion board: Ai-Thinker Discussions