13 MQTT Fundamentals

In 60 Seconds

MQTT is the de facto IoT messaging standard, using a publish-subscribe pattern where sensors publish data to hierarchical topics, applications subscribe to topics of interest, and a central broker handles all routing. The three QoS levels (0: fire-and-forget, 1: at-least-once, 2: exactly-once) let you trade reliability for overhead based on your application’s needs.

13.1 Learning Objectives

By the end of this chapter series, you will be able to:

Explain the MQTT publish-subscribe pattern and how brokers decouple publishers from subscribers
Design hierarchical topic structures with wildcards for scalable IoT messaging
Select appropriate QoS levels (0, 1, 2) based on reliability, battery, and bandwidth trade-offs
Configure MQTT security including TLS encryption, authentication, and topic-level ACLs
Compare MQTT with CoAP and HTTP to choose the right protocol for your IoT application

Key Concepts

MQTT: Message Queuing Telemetry Transport — pub/sub protocol optimized for constrained IoT devices over unreliable networks
Broker: Central server routing messages from publishers to all matching subscribers by topic pattern
Topic: Hierarchical string (e.g., home/bedroom/temperature) used to route messages to interested subscribers
QoS Level: Quality of Service 0/1/2 trading delivery guarantee for message overhead
Retained Message: Last message on a topic stored by broker for immediate delivery to new subscribers
Last Will and Testament: Pre-configured message published by broker when a client disconnects ungracefully
Persistent Session: Broker stores subscriptions and pending messages allowing clients to resume after disconnection

13.2 For Beginners: MQTT Fundamentals

MQTT (Message Queuing Telemetry Transport) is one of the most popular protocols for IoT communication. It works like a messaging app for devices: sensors publish updates to topics (like chat channels), and any interested device can subscribe to receive those updates. It is simple, lightweight, and works even on slow or unreliable connections.

Sensor Squad: The IoT Messaging App

“MQTT is basically a group chat for devices!” announced Max the Microcontroller. “Sammy, you publish your temperature to the topic garden/temperature. Anyone who subscribes to that topic gets your updates automatically.”

“It’s so lightweight!” said Bella the Battery happily. “The connect message is just a few bytes, and each publish is even smaller. Compare that to HTTP where just the headers are hundreds of bytes. MQTT was literally designed for devices like us – low bandwidth, unreliable networks, tiny batteries.”

Sammy the Sensor demonstrated: “I publish to garden/temperature and the dashboard subscribes to garden/# – that wildcard means it gets ALL garden messages. Temperature, humidity, soil moisture – one subscription covers everything. Wildcards are like subscribing to an entire TV channel instead of individual shows.”

“And it works even on terrible connections!” added Lila the LED. “MQTT was invented for monitoring oil pipelines via satellite – where every byte costs money and the connection drops constantly. If it can handle that, it can definitely handle our garden sensors on WiFi!”

13.3 MQTT - Message Queue Telemetry Transport

MQTT is the de facto standard for IoT messaging, enabling millions of devices to communicate efficiently through a publish-subscribe pattern. This chapter series provides comprehensive coverage of MQTT concepts, from basic pub/sub mechanics to advanced security and optimization.

Key Takeaway

MQTT decouples message producers (publishers) from consumers (subscribers) through a central broker. Sensors publish data to topics, applications subscribe to topics they care about, and the broker handles all routing. The three QoS levels (0: fire-and-forget, 1: at-least-once, 2: exactly-once) let you trade off between reliability and overhead based on your application’s needs.

13.4 Chapter Overview

This comprehensive guide to MQTT is organized into focused chapters:

Chapter	Focus	Difficulty	Time
Publish-Subscribe Basics	Topics, wildcards, broker architecture	Beginner	25 min
Quality of Service	QoS levels, reliability vs overhead trade-offs	Intermediate	20 min
Security	TLS, authentication, access control	Intermediate	15 min
Advanced Topics	Packet structure, topic design, MQTT 5.0	Intermediate	20 min
Practice and Exercises	Hands-on labs, pitfalls, resources	Intermediate	30 min

13.5 Learning Path

Recommended sequence:

Start with Pub/Sub Basics - Understand the publish-subscribe pattern, topics, and wildcards
Learn QoS Levels - Master reliability vs overhead trade-offs
Study Security - Configure TLS, authentication, and access control
Explore Advanced Topics - Packet structure, topic design patterns, MQTT 5.0
Complete Practice Exercises - Build hands-on skills and avoid common pitfalls

13.6 Why MQTT?

The Challenge: Scalable Device Communication

The Problem: Traditional request-response patterns (like HTTP polling) don’t scale for IoT:

N devices x M polls/hour = billions of wasted requests
Servers must track every device connection
Devices waste energy checking for messages that aren’t there

The Solution: Publish-subscribe messaging with a central broker:

Decouple senders from receivers
Store messages for offline devices
Push instead of poll
Scale to millions of devices

13.7 MQTT Cost at a Glance

Interactive Calculator: MQTT Message Cost

Calculate monthly cloud messaging costs for your IoT fleet:

Show code

viewof mqttDeviceCount = Inputs.range([100, 100000], {
  value: 10000,
  step: 100,
  label: "Number of devices:",
  width: 300
})

viewof mqttMsgRate = Inputs.range([0.1, 10], {
  value: 1,
  step: 0.1,
  label: "Messages per minute per device:",
  width: 300
})

viewof mqttCostPer1M = Inputs.range([0.5, 5], {
  value: 1,
  step: 0.1,
  label: "Cost per 1M messages ($):",
  width: 300
})

mqttMonthlyMessages = mqttDeviceCount * mqttMsgRate * 1440 * 30
mqttMonthlyCost = (mqttMonthlyMessages / 1000000) * mqttCostPer1M
mqttYearlyCost = mqttMonthlyCost * 12

Monthly Messages

${Math.round(mqttMonthlyMessages / 1000000).toFixed(1)}M</div> <div style="font-size: 0.9em; opacity: 0.9;">Monthly Cost: <span style="font-size: 1.3em; font-weight: bold;">$

Yearly Cost: $

Key Insight: At devices publishing msg/min, you’ll send ${(mqttMonthlyMessages / 1000000).toFixed(1)}M messages/month costing **$${mqttMonthlyCost.toFixed(2)}/month** or **$/year**.

13.8 MQTT at a Glance

Feature	Description
Pattern	Publish-Subscribe (via broker)
Transport	TCP (port 1883) or TLS (port 8883)
Message Size	Up to 256 MB (typically KB)
QoS Levels	0 (fire-forget), 1 (at-least-once), 2 (exactly-once)
Key Features	Retained messages, Last Will, Session persistence
Protocol Versions	3.1.1 (2014), 5.0 (2019)

Interactive Calculator: QoS Overhead Comparison

Compare bandwidth usage across MQTT QoS levels:

Show code

viewof qosPayloadSize = Inputs.range([10, 1000], {
  value: 100,
  step: 10,
  label: "Payload size (bytes):",
  width: 300
})

viewof qosMessagesPerDay = Inputs.range([100, 10000], {
  value: 1440,
  step: 100,
  label: "Messages per day:",
  width: 300
})

// MQTT packet overhead (approximate)
qos0Overhead = 2  // Fixed header only
qos1Overhead = 4  // Fixed header + PUBACK
qos2Overhead = 10 // Fixed header + PUBREC + PUBREL + PUBCOMP

qos0TotalPerMsg = qosPayloadSize + qos0Overhead
qos1TotalPerMsg = qosPayloadSize + qos1Overhead
qos2TotalPerMsg = qosPayloadSize + qos2Overhead

qos0DailyKB = (qos0TotalPerMsg * qosMessagesPerDay) / 1024
qos1DailyKB = (qos1TotalPerMsg * qosMessagesPerDay) / 1024
qos2DailyKB = (qos2TotalPerMsg * qosMessagesPerDay) / 1024

qos1Increase = ((qos1DailyKB - qos0DailyKB) / qos0DailyKB * 100)
qos2Increase = ((qos2DailyKB - qos0DailyKB) / qos0DailyKB * 100)
html`<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 15px; margin: 15px 0;">
  <div style="background: #2C3E50; color: white; padding: 15px; border-radius: 8px;">
    <div style="font-size: 0.85em; opacity: 0.9;">QoS 0 (Fire-and-Forget)</div>
    <div style="font-size: 1.8em; font-weight: bold; margin: 8px 0; color: #16A085;">${qos0DailyKB.toFixed(1)} KB/day</div>
    <div style="font-size: 0.8em; opacity: 0.8;">Baseline</div>
  </div>
  <div style="background: #E67E22; color: white; padding: 15px; border-radius: 8px;">
    <div style="font-size: 0.85em; opacity: 0.9;">QoS 1 (At-Least-Once)</div>
    <div style="font-size: 1.8em; font-weight: bold; margin: 8px 0;">${qos1DailyKB.toFixed(1)} KB/day</div>
    <div style="font-size: 0.8em; opacity: 0.8;">+${qos1Increase.toFixed(1)}% overhead</div>
  </div>
  <div style="background: #E74C3C; color: white; padding: 15px; border-radius: 8px;">
    <div style="font-size: 0.85em; opacity: 0.9;">QoS 2 (Exactly-Once)</div>
    <div style="font-size: 1.8em; font-weight: bold; margin: 8px 0;">${qos2DailyKB.toFixed(1)} KB/day</div>
    <div style="font-size: 0.8em; opacity: 0.8;">+${qos2Increase.toFixed(1)}% overhead</div>
  </div>
</div>
<div style="margin: 12px 0 4px; padding: 12px 14px; border-radius: 8px; background: #eef5f7; color: #2C3E50; font-size: 0.95em;">
  <strong>Key Insight:</strong> For ${qosPayloadSize}-byte messages sent ${qosMessagesPerDay} times/day, QoS 1 adds ${qos1Increase.toFixed(1)}% overhead while QoS 2 adds ${qos2Increase.toFixed(1)}% overhead compared to QoS 0.
</div>`

Interactive Calculator: MQTT vs HTTP Cost Comparison

Compare the true cost of MQTT persistent connections vs HTTP polling:

viewof compDevices = Inputs.range([1000, 50000], { value: 10000, step: 1000, label: “Number of devices:”, width: 300 })

viewof compPollRate = Inputs.range([1, 60], { value: 1, step: 1, label: “Polls per minute:”, width: 300 })

viewof compCloudCost = Inputs.range([0.5, 3], { value: 1, step: 0.1, label: “Cost per 1M messages ($):”, width: 300 })

viewof compAlbCost = Inputs.range([100, 500], { value: 200, step: 50, label: “Monthly ALB/Gateway cost ($):”, width: 300 })

// MQTT: 1 message per poll compMqttMonthlyMsgs = compDevices * compPollRate * 1440 * 30 compMqttMonthlyCost = (compMqttMonthlyMsgs / 1000000) * compCloudCost

// HTTP: request + response = 2 messages per poll, plus ALB compHttpMonthlyMsgs = compMqttMonthlyMsgs * 2 compHttpMonthlyCost = (compHttpMonthlyMsgs / 1000000) * compCloudCost + compAlbCost

compSavings = compHttpMonthlyCost - compMqttMonthlyCost compSavingsPercent = (compSavings / compHttpMonthlyCost) * 100 compYearlySavings = compSavings * 12 html<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 20px; margin: 15px 0;"> <div style="background: linear-gradient(135deg, #16A085 0%, #2C3E50 100%); color: white; padding: 20px; border-radius: 8px;"> <div style="font-size: 1.1em; font-weight: bold; margin-bottom: 10px;">MQTT (Persistent)</div> <div style="font-size: 0.85em; opacity: 0.9;">Messages: ${(compMqttMonthlyMsgs / 1000000).toFixed(1)}M/month</div> <div style="font-size: 2.2em; font-weight: bold; margin: 15px 0; color: #8ff3cc;">$${compMqttMonthlyCost.toFixed(2)}</div> <div style="font-size: 0.85em; opacity: 0.9;">Monthly cost</div> </div> <div style="background: linear-gradient(135deg, #E67E22 0%, #E74C3C 100%); color: white; padding: 20px; border-radius: 8px;"> <div style="font-size: 1.1em; font-weight: bold; margin-bottom: 10px;">HTTP (Polling)</div> <div style="font-size: 0.85em; opacity: 0.9;">Messages: ${(compHttpMonthlyMsgs / 1000000).toFixed(1)}M/month</div> <div style="font-size: 2.2em; font-weight: bold; margin: 15px 0;">$${compHttpMonthlyCost.toFixed(2)}</div> <div style="font-size: 0.85em; opacity: 0.9;">Monthly cost incl. ALB</div> </div> </div> <div style="background: #2C3E50; color: white; padding: 20px; border-radius: 8px; margin: 15px 0; text-align: center;"> <div style="font-size: 0.9em; opacity: 0.9;">Monthly savings with MQTT</div> <div style="font-size: 2.1em; font-weight: bold; margin: 8px 0; color: #8ff3cc;">$${compSavings.toFixed(2)}</div> <div style="font-size: 1em; opacity: 0.9;">${compSavingsPercent.toFixed(1)}% reduction • $${compYearlySavings.toFixed(2)}/year saved</div> </div> <div style="margin: 12px 0 4px; padding: 12px 14px; border-radius: 8px; background: #eef5f7; color: #2C3E50; font-size: 0.95em;"> <strong>Key Insight:</strong> MQTT saves $${compSavings.toFixed(2)}/month (${compSavingsPercent.toFixed(1)}%) by using persistent connections instead of HTTP polling, eliminating ALB costs and halving message traffic. </div>

13.9 Quick Reference: When to Use MQTT

Choose MQTT when:

You need publish-subscribe (one-to-many communication)
Devices send frequent updates (every few seconds to minutes)
Multiple subscribers need the same data
Network is unreliable (automatic reconnection, QoS guarantees)
Battery-powered devices need efficient persistent connections

Choose CoAP instead when:

You need request-response (client-server pattern)
RESTful APIs are required (GET/POST/PUT/DELETE)
UDP is acceptable (lower overhead than TCP)

Choose HTTP instead when:

Integration with web services is primary goal
Infrequent communication (hourly/daily updates)
Large payloads (firmware updates, images)

Check Your Understanding: Protocol Selection

13.10 Prerequisites

Before starting this series:

Basic Networking Concepts: TCP/IP, client-server architecture
IoT Reference Architectures: IoT system layers and components
Basic programming knowledge (Python, C++, or JavaScript)

13.11 Related Chapters

MQTT Deep Dives:

MQTT QoS and Session - Advanced session management
MQTT Labs - Hands-on implementations with ESP32 and Python
MQTT Comprehensive Review - Broker internals and message flow

Protocol Comparisons:

CoAP Protocol - RESTful alternative for constrained devices
AMQP vs MQTT - When to use which protocol
IoT Protocols Review - Comprehensive protocol comparison

Learning Hubs:

Simulations Hub - Interactive MQTT protocol demonstrations
Videos Hub - MQTT tutorial videos
Quizzes Hub - Test your MQTT knowledge

Interactive Calculator: Topic Wildcard Matcher

Test MQTT topic patterns with wildcards (+ and #):

viewof topicFilter = Inputs.text({ label: “Topic filter (use + for single level, # for multi-level):”, value: “home/+/temperature”, width: 400 })

viewof testTopic = Inputs.text({ label: “Test topic:”, value: “home/bedroom/temperature”, width: 400 })

function matchesMqttTopic(filter, topic) { const filterParts = filter.split(‘/’); const topicParts = topic.split(‘/’);

for (let i = 0; i < filterParts.length; i++) { if (filterParts[i] === ‘#’) { return true; // # matches everything from this point } if (i >= topicParts.length) { return false; // filter is longer than topic } if (filterParts[i] !== ‘+’ && filterParts[i] !== topicParts[i]) { return false; // no match } }

return filterParts.length === topicParts.length; }

topicMatches = matchesMqttTopic(topicFilter, testTopic)

// Example topics to show pattern matching exampleTopics = [ “home/bedroom/temperature”, “home/kitchen/temperature”, “home/bedroom/humidity”, “home/outdoor/temperature”, “office/conference/temperature”].map(t => ({ topic: t, matches: matchesMqttTopic(topicFilter, t) })) html

<div style="background: ${topicMatches ? '#16A085' : '#E74C3C'}; color: white; padding: 20px; border-radius: 8px; margin: 15px 0; text-align: center;">   <div style="font-size: 1.2em; font-weight: bold;">     ${topicMatches ? '✓ MATCH' : '✗ NO MATCH'}   </div>   <div style="font-size: 0.9em; opacity: 0.9; margin-top: 8px; line-height: 1.6;">     Filter: <code style="background: rgba(255,255,255,0.2); padding: 2px 6px; border-radius: 3px; word-break: break-word;">${topicFilter}</code><br/>     Topic: <code style="background: rgba(255,255,255,0.2); padding: 2px 6px; border-radius: 3px; word-break: break-word;">${testTopic}</code>   </div> </div> <div style="background: #2C3E50; color: white; padding: 15px; border-radius: 8px; margin: 15px 0;">   <div style="font-weight: bold; margin-bottom: 10px;">Example matches for "${topicFilter}"</div>   ${exampleTopics.map(ex =>

  <span style="color: ${ex.matches ? '#8ff3cc' : '#ffd0c8'}; font-weight: bold;">${ex.matches ? '✓' : '✗'}</span>
  <code style="opacity: 0.95; word-break: break-word;">${ex.topic}</code>
</div>`

).join(’’)}

Wildcard rules: + matches exactly one level, while # matches zero or more trailing levels and must be the final segment.

Decision Framework: Choosing MQTT vs CoAP vs HTTP

When building an IoT system, selecting the right application protocol significantly impacts battery life, bandwidth usage, and system complexity.

Scenario	Recommended Protocol	Justification
100 temperature sensors → 5 dashboards	MQTT	Pub-sub pattern: 100 publishers + 5 subscribers = 105 broker connections. HTTP would need 500 persistent connections (100×5)
Smartphone querying smart bulb state	CoAP	RESTful GET/PUT matches HTTP mental model. UDP reduces overhead for single request-response
Firmware update to device (10 MB file)	HTTP	Proven file transfer with resume support. MQTT 256MB limit exists but HTTP tooling more mature
Battery sensor publishing every 5 minutes	MQTT (QoS 0)	Connection persistence: TCP handshake cost amortized. CoAP UDP has no connection but requires DTLS handshake per message
Thermostat on unreliable cellular	MQTT (QoS 1)	Built-in automatic retry with PUBACK. CoAP confirmable messages require manual retry logic
Local device control (no cloud)	CoAP Multicast	Direct peer-to-peer with group addressing. MQTT requires broker infrastructure

Key Decision Factors:

Communication pattern: One-to-many → MQTT. One-to-one → CoAP
Network reliability: Unreliable → MQTT QoS 1/2. Reliable → CoAP/HTTP
Device constraints: Extremely limited → CoAP (UDP). Moderate → MQTT (TCP)
Data frequency: High (>1/min) → MQTT persistent connection. Low (<1/hour) → CoAP/HTTP per-request

Interactive Calculator: Connection Efficiency

Compare persistent connections vs polling for battery-powered devices:

viewof connUpdateInterval = Inputs.range([1, 60], { value: 5, step: 1, label: “Data update interval (minutes):”, width: 300 })

viewof connBatteryCapacity = Inputs.range([1000, 10000], { value: 5000, step: 500, label: “Battery capacity (mAh):”, width: 300 })

// Energy costs (approximate mA per operation) connMqttPublish = 20 // Just send data on existing connection connMqttKeepalive = 5 // Periodic keepalive (every 60s) connHttpConnect = 100 // TCP handshake + TLS + request + response connHttpIdle = 0 // No persistent connection

// Daily operations connUpdatesPerDay = (24 * 60) / connUpdateInterval connKeepalivesPerDay = (24 * 60) / 1 // Every minute

// Daily energy consumption (mAh) connMqttDaily = (connMqttPublish * connUpdatesPerDay + connMqttKeepalive * connKeepalivesPerDay) / 1000 connHttpDaily = (connHttpConnect * connUpdatesPerDay) / 1000

// Battery life (days) connMqttBatteryDays = connBatteryCapacity / connMqttDaily connHttpBatteryDays = connBatteryCapacity / connHttpDaily

connBatteryImprovement = ((connMqttBatteryDays - connHttpBatteryDays) / connHttpBatteryDays) * 100 html<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 20px; margin: 15px 0;"> <div style="background: linear-gradient(135deg, #16A085 0%, #2C3E50 100%); color: white; padding: 20px; border-radius: 8px;"> <div style="font-size: 1em; font-weight: bold; margin-bottom: 10px;">MQTT Persistent</div> <div style="font-size: 0.8em; opacity: 0.9;">Daily consumption: ${connMqttDaily.toFixed(1)} mAh</div> <div style="font-size: 2.2em; font-weight: bold; margin: 15px 0; color: #8ff3cc;">${connMqttBatteryDays.toFixed(0)} days</div> <div style="font-size: 0.85em; opacity: 0.9;">Battery life</div> </div> <div style="background: linear-gradient(135deg, #E67E22 0%, #E74C3C 100%); color: white; padding: 20px; border-radius: 8px;"> <div style="font-size: 1em; font-weight: bold; margin-bottom: 10px;">HTTP Polling</div> <div style="font-size: 0.8em; opacity: 0.9;">Daily consumption: ${connHttpDaily.toFixed(1)} mAh</div> <div style="font-size: 2.2em; font-weight: bold; margin: 15px 0;">${connHttpBatteryDays.toFixed(0)} days</div> <div style="font-size: 0.85em; opacity: 0.9;">Battery life</div> </div> </div> <div style="background: #2C3E50; color: white; padding: 20px; border-radius: 8px; margin: 15px 0; text-align: center;"> <div style="font-size: 0.9em; opacity: 0.9;">Battery life extension</div> <div style="font-size: 2em; font-weight: bold; margin: 8px 0; color: #8ff3cc;">+${connBatteryImprovement.toFixed(0)}%</div> <div style="font-size: 0.9em; opacity: 0.9;">${(connMqttBatteryDays - connHttpBatteryDays).toFixed(0)} extra days with MQTT</div> </div> <div style="margin: 12px 0 4px; padding: 12px 14px; border-radius: 8px; background: #eef5f7; color: #2C3E50; font-size: 0.95em;"> <strong>Key Insight:</strong> With updates every ${connUpdateInterval} minutes, MQTT extends battery life by ${connBatteryImprovement.toFixed(0)}% by avoiding repeated TCP handshakes and TLS negotiations. </div>

Real Cost Example: AWS IoT Core charges $1/million messages. A fleet of 10,000 devices: - MQTT (1 msg/min): 10,000 × 1 × 1,440 = 14.4M msgs/day = $14.40/day ($5,256/year) - HTTP (same rate): each poll generates a request + response = 28.8M messages/day = $28.80/day ($10,512/year) + ALB (~$200/month = $2,400/year) = $12,912/year - MQTT saves ~59% ($7,656/year) due to persistent connections and halved message count

Putting Numbers to It

Cloud messaging costs scale linearly with message count. For $n$ devices publishing at rate $r$ messages/minute:

\[C_{\text{monthly}} = n \cdot r \cdot 1440 \frac{\text{min}}{\text{day}} \cdot 30 \frac{\text{days}}{\text{month}} \cdot \frac{\$1}{10^6 \text{ msgs}}\]

For this fleet with $n = 10,000$ devices at $r = 1$ msg/min: \[C_{\text{MQTT}} = 10,000 \times 1 \times 1,440 \times 30 \times \frac{\$1}{10^6} = \$432/\text{month}\]

HTTP requires connection overhead: each message becomes request + response (2 messages): \[C_{\text{HTTP}} = 10,000 \times 1 \times 1,440 \times 30 \times 2 \times \frac{\$1}{10^6} = \$864/\text{month}\]

Plus ALB processing fees (~$200/month), total HTTP cost = $1,064/month vs MQTT’s $432/month.

The cost ratio $C_{\text{HTTP}}/C_{\text{MQTT}} = 1,064/432 = 2.46\times$ shows persistent connections reduce cloud costs by 60%.

13.12 Start Learning

Ready to begin? Start with MQTT Publish-Subscribe Basics to understand the core concepts that make MQTT the leading IoT messaging protocol.

13.13 Knowledge Check

Matching Activity: MQTT Concepts

Match each MQTT term or feature to its correct definition or use case.

Ordering Activity: MQTT QoS 1 Message Exchange

Place the following steps in the correct sequence for a successful QoS 1 message delivery from publisher to subscriber.

Quiz: MQTT Fundamentals

💻 Code Challenge

13.14 What’s Next

After completing this MQTT Fundamentals series, continue with:

Chapter	Focus	Why Read It
MQTT Publish-Subscribe Basics	Topics, wildcards, broker architecture	Build the foundation — understand how messages flow between publishers, the broker, and subscribers
MQTT Quality of Service	QoS 0/1/2 reliability vs overhead trade-offs	Select the right delivery guarantee for your application’s battery, bandwidth, and reliability requirements
MQTT Security	TLS encryption, authentication, topic ACLs	Secure your broker against unauthorized access and eavesdropping in production deployments
MQTT QoS and Session	Advanced session management and persistent sessions	Diagnose message loss and implement reliable delivery for offline devices
MQTT Labs and Implementation	Hands-on ESP32 and Python MQTT projects	Apply concepts immediately with working code for real IoT hardware
CoAP Overview	RESTful request-response protocol for constrained devices	Compare MQTT’s pub-sub model with CoAP to select the right protocol for each scenario

Label the Diagram