37  MQTT Knowledge Check

In 60 Seconds

This knowledge check tests your MQTT mastery through 10 scenario-based multiple-choice questions and 4 application scenarios covering QoS selection, topic hierarchy design, session configuration, wildcard usage, retained messages, Last Will Testament, and protocol comparison decisions between MQTT, CoAP, HTTP, and AMQP.

37.1 Learning Objectives

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

  • Apply MQTT Knowledge: Solve real-world scenarios involving QoS selection, topic design, and session management
  • Debug Complex Systems: Analyze multi-client MQTT systems with mixed configurations
  • Compare Protocols: Determine when MQTT is optimal versus CoAP, HTTP, or AMQP
  • Design Production Systems: Make architectural decisions for scalable MQTT deployments

37.2 Prerequisites

Required Chapters:

Estimated Time: 20 minutes

37.3 Key Concepts Reference

  • MQTT: Message Queuing Telemetry Transport - lightweight publish-subscribe protocol
  • Broker: Central message server managing topic subscriptions and message routing
  • Publish: Send message to topic (publisher doesn’t need subscribers to exist)
  • Subscribe: Register interest in topic pattern (receives all matching messages)
  • Topic: Hierarchical message category (e.g., home/kitchen/temperature)
  • Wildcard: Single-level + or multi-level # subscriptions
  • QoS (Quality of Service): 0 (fire-and-forget), 1 (at-least-once), 2 (exactly-once)
  • Payload: Arbitrary binary data (protocol-agnostic)
  • Last Will Testament: Message sent if client disconnects unexpectedly
  • Retain: Server keeps last message to deliver to new subscribers
  • TLS/SSL: Encryption for security (port 8883)
  • Authentication: Username/password or certificate-based

37.4 Knowledge Check Questions

Test your understanding of MQTT protocol with these scenario-based questions:

37.5 Understanding Check: Protocol Application

Apply your MQTT knowledge to these real-world scenarios:

Situation: You’re deploying 100 sensors to a factory network. The IT team asks which ports need to be opened in the firewall for MQTT communication.

Think about:

  1. Why does MQTT use port 1883 (not 80 like HTTP or 443 like HTTPS)?
  2. When would you use port 8883 instead of 1883?
  3. What’s the trade-off between these two ports in terms of security and performance?

Key Insight:

  • Port 1883 = unencrypted MQTT (fast, minimal overhead, ~50ms latency)
  • Port 8883 = TLS encrypted MQTT (secure, +10-20% overhead, ~65ms latency)

For factory sensors on an internal network (isolated from internet): Port 1883 may be acceptable - lower overhead, faster processing.

For cloud connectivity or sensitive data: Always use 8883 - TLS encryption prevents eavesdropping, man-in-the-middle attacks.

Verify Your Understanding:

  • Can you explain why IoT protocols often use non-standard ports rather than 80/443?
  • What security implications does each port have for industrial deployments?
  • How would firewall rules differ for internal vs cloud-connected sensors?

Situation: You’re configuring message delivery guarantees for different sensor types in a smart building.

Compare these requirements:

  • Temperature sensors: Reading every 30 seconds
  • Door lock commands: Critical security actions
  • Motion alerts: Important but occasional loss acceptable

Think about:

  1. What happens if a QoS 0 temperature reading is lost? (Next reading arrives in 30s)
  2. What happens if a QoS 0 door unlock command is lost? (Security breach - door stays locked)
  3. How does QoS 1 protect against the door lock scenario?

Key Insight:

QoS 0 (At most once): Fire-and-forget, no acknowledgment, 1x message overhead

  • Use for: Frequent replaceable data (temperature every 30s - missing one reading OK)
  • Energy: Lowest (~1.5 mJ per message)

QoS 1 (At least once): Publisher waits for PUBACK, retries if timeout

  • Use for: Critical commands (door locks, alarms) - must be delivered
  • Energy: Medium (~3 mJ per message, 2x overhead due to ACK)
  • Trade-off: Possible duplicates (handle with idempotent operations)

QoS 2 (Exactly once): 4-way handshake, no duplicates or losses

  • Use for: Financial transactions, medication dispensing
  • Energy: High (~6 mJ per message, 4x overhead)
  • Trade-off: Rarely needed in IoT due to complexity

Verify Your Understanding:

  • Can you map each QoS level to a specific use case in your project?
  • What percentage of battery life would you save using QoS 0 vs QoS 1 for a sensor sending 100 messages/day?

Situation: Your smart home has 50 devices across 5 rooms. You need to subscribe to all temperature readings without creating 50 individual subscriptions.

Topic structure:

home/living_room/temp
home/living_room/humidity
home/bedroom/temp
home/bedroom/humidity
home/kitchen/temp

Think about:

  1. How would you subscribe to ALL temperature readings from ALL rooms with a single subscription?
  2. What pattern matches only bedroom sensors (both temp and humidity)?
  3. Why can’t you publish to home/+/temp to update all temperature sensors?

Key Insight:

Wildcard subscriptions enable efficient pattern matching:

  • + (single-level): home/+/temp matches home/bedroom/temp, home/kitchen/temp
  • # (multi-level): home/bedroom/# matches ALL topics under bedroom

Important: Wildcards ONLY work for SUBSCRIBE, NOT for PUBLISH!

  • Subscribe: client.subscribe("home/+/temp") - receives all room temperatures
  • Publish: client.publish("home/+/temp", "25") - this doesn’t work! Must publish to specific topic.

Verify Your Understanding:

  • Can you design a topic hierarchy for a 3-floor office building with 20 rooms per floor?
  • How would you subscribe to all sensors on floor 2?
  • What’s the difference between home/+/temp and home/# subscriptions?

Situation: You’re choosing between MQTT and HTTP for a battery-powered environmental monitoring system with 200 sensors.

Requirements:

  • Sensors report temperature, humidity, air quality every 5 minutes
  • Central dashboard displays all sensor data in real-time
  • Battery life must exceed 2 years on coin cell (CR2032, 240mAh)

Compare approaches:

HTTP Polling:

  • Dashboard polls each sensor: GET /api/sensor/temp every 5 minutes
  • Requires TCP connection setup (3-way handshake) per request
  • ~165 bytes overhead per reading (headers + payload)

MQTT Pub/Sub:

  • Sensors publish to topics: sensors/room1/temp
  • Dashboard subscribes once to sensors/#, receives updates automatically
  • ~22 bytes overhead per reading (MQTT header + payload)
  • Persistent TCP connection (setup once, reuse for all messages)

Think about:

  1. Which protocol wastes more battery on connection setup overhead?
  2. How does the dashboard get data in each approach (pull vs push)?
  3. What happens when you add sensor #201? Does the dashboard code change?

Key Insight:

Use HTTP when:

  • Request-response pattern natural (user clicks “get temperature”)
  • Infrequent access (once per hour or less)
  • Direct browser access needed
  • Integration with existing REST APIs

Use MQTT when:

  • Many subscribers need same data (dashboard + mobile app + analytics)
  • Real-time push updates required
  • Battery-powered sensors (persistent connection amortizes setup cost)
  • Publish-subscribe decoupling valuable (add subscribers without publisher changes)

Verify Your Understanding:

  • Can you calculate the energy savings of MQTT vs HTTP for this scenario?
  • What happens to HTTP battery life if polling interval changes from 5 minutes to 30 seconds?
  • How would you architect a hybrid system using both MQTT (sensor data) and HTTP (user commands)?

37.7 Summary

This chapter provided comprehensive practice for MQTT knowledge:

  • QoS Selection: Match QoS level to data criticality - QoS 0 for replaceable data, QoS 1 for important events, QoS 2 only for critical single-execution commands
  • Wildcard Mastery: Use + for single-level and # for multi-level matching, but only in SUBSCRIBE operations
  • Session Management: Persistent sessions (clean_session=false) enable offline message queuing; clean sessions suit pure publishers
  • Security Configuration: Production deployments require TLS (port 8883) with authentication and ACLs
  • Protocol Selection: MQTT excels for publish-subscribe patterns with many subscribers; HTTP suits request-response with infrequent access

37.8 What’s Next

Continue your learning journey with these related chapters:

  • Compare: CoAP - Learn the alternative request-response protocol for constrained devices
  • Enterprise: AMQP Fundamentals - Understand advanced message queuing for enterprise IoT
  • Protocols: IoT Protocols Overview - Survey the full protocol landscape