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:

Beginner • 25 min

Publish-Subscribe Basics

Topics, wildcards, and broker architecture.

Intermediate • 20 min

Quality of Service

QoS levels and reliability versus overhead trade-offs.

Intermediate • 15 min

Security

TLS, authentication, and access control.

Intermediate • 20 min

Advanced Topics

Packet structure, topic design, and MQTT 5.0.

Intermediate • 30 min

Practice and Exercises

Hands-on labs, pitfalls, and study resources.

13.5 Learning Path

Figure 13.1: Recommended learning sequence for MQTT Fundamentals

Recommended sequence:

1. Start with Pub/Sub Basics - Understand the publish-subscribe pattern, topics, and wildcards
2. Learn QoS Levels - Master reliability vs overhead trade-offs
3. Study Security - Configure TLS, authentication, and access control
4. Explore Advanced Topics - Packet structure, topic design patterns, MQTT 5.0
5. 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:

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:

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 =>
    `<div style="padding: 7px 0; border-bottom: 1px solid rgba(255,255,255,0.1); display: flex; align-items: flex-start; gap: 10px;">
      <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('')}
</div>
<div style="margin: 12px 0 4px; padding: 12px 14px; border-radius: 8px; background: #eef5f7; color: #2C3E50; font-size: 0.95em; line-height: 1.5;">
  <strong>Wildcard rules:</strong> <code>+</code> matches exactly one level, while <code>#</code> matches zero or more trailing levels and must be the final segment.
</div>`

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:

MQTT Publish-Subscribe Basics

Focus: Topics, wildcards, and broker architecture.

Why read it: Build the foundation and understand how messages flow between publishers, the broker, and subscribers.

MQTT Quality of Service

Focus: QoS 0/1/2 reliability versus overhead trade-offs.

Why read it: Select the right delivery guarantee for your application's battery, bandwidth, and reliability requirements.

MQTT Security

Focus: TLS encryption, authentication, and topic ACLs.

Why read it: Secure your broker against unauthorized access and eavesdropping in production deployments.

MQTT QoS and Session

Focus: Advanced session management and persistent sessions.

Why read it: Diagnose message loss and implement reliable delivery for offline devices.

MQTT Labs and Implementation

Focus: Hands-on ESP32 and Python MQTT projects.

Why read it: Apply concepts immediately with working code for real IoT hardware.

CoAP Overview

Focus: RESTful request-response protocol for constrained devices.

Why read it: Compare MQTT's pub-sub model with CoAP to select the right protocol for each scenario.

Label the Diagram