MQTT and IoT Messaging

MQTT and IoT Messaging

Introduction

When your device posts sensor data to the cloud, you need a pattern for who talks to whom. HTTP works for occasional uploads. MQTT (Message Queuing Telemetry Transport) fits many small devices sending frequent, lightweight messages through a broker that routes topics.

MQTT is everywhere in IoT labs: Mosquitto on a Pi, HiveMQ cloud, AWS IoT, Node-RED flows. This article explains publish/subscribe in plain language and how it fits Connectivity architecture.

---

Publish / subscribe — not direct chat

Device A  ──publish──►  [ Broker ]  ──forward──►  Device B (subscribed)
              "home/temp"     │
                              └──►  Dashboard (subscribed)

Role	Job
Publisher	Sends message to a topic string
Subscriber	Tells broker which topics it wants
Broker	Receives all messages, forwards to subscribers

Devices usually do not connect to each other directly — they connect to the broker. That scales when you add ten sensors and three dashboards.

In plain terms

MQTT is like a school bulletin board. You pin a note under "Building A / temperature". Anyone who asked to see that board section gets a copy. You do not hand the note to each person yourself.

---

Topics and payloads

Topic — hierarchical string, often / separated:

lab/robot01/temperature
lab/robot01/cmd/led

Payload — bytes (often JSON text):

{"temp_c": 23.4, "humidity": 41}

QoS (Quality of Service) — how hard the broker tries to deliver:

QoS	Meaning
0	Fire and forget
1	At least once (may duplicate)
2	Exactly once (heavier)

Student projects often use QoS 0 or 1 on trusted LAN.

---

MQTT vs HTTP for embedded

	MQTT	HTTP REST
Connection	Long-lived	Request per upload
Overhead	Small header	Headers + URL each time
Push to device	Natural (subscribe cmd topic)	Polling or WebSockets
Broker	Required	Just server

Use MQTT when many devices stream data or need commands pushed from cloud. Use HTTP when you post rarely to a simple REST API.

---

Typical stack on MCU

1. Wi-Fi or Ethernet link up
2. TCP connection to broker host:1883 (or 8883 with TLS)
3. MQTT CONNECT with client ID
4. SUBSCRIBE to command topics
5. PUBLISH sensor topics on timer or change

Libraries: PubSubClient (Arduino), ESP-IDF mqtt, paho-mqtt on Linux gateways.

Node-RED can subscribe, transform, and forward — common in HvA IoT exercises. Full guide: Node-RED for IoT.

---

Security basics

• TLS (mqtts://) on untrusted networks
• Username/password or certificates — not anonymous broker on internet
• Do not embed secrets in Git — use build config or provisioning

---

Videos — other ways to learn

ESP8266 + MQTT home automation

Home Automation at Home Part 1: ESP8266 & MQTT

Node-RED publish and subscribe

MQTT Publish and Subscribe Using Node Red

End-to-end demo

[DEMO] ESP8266 and Node-RED with MQTT

---

Further reading

• Random Nerd Tutorials — ESP8266 MQTT
• PubSubClient library
• Node-RED MQTT broker node

---

Relevant topics

• Node-RED for IoT
• Docker for edge and IoT
• Connectivity architecture
• Computer networks
• Wireless for embedded
• Microcontrollers overview

---

Starting points

1. Run Mosquitto on a Pi or laptop; mosquitto_sub and mosquitto_pub by hand.
2. Publish fake sensor JSON from MCU every 5 s.
3. Subscribe to cmd/# and toggle an LED from Node-RED.
4. Draw topic tree on whiteboard before coding names.

---

Focus points

• Topic naming convention — agree as a team early.
• Last will testament (LWT) — broker publishes when device drops offline.
• Keep payloads small — bandwidth and flash for JSON formatting.
• Broker IP — use static IP or mDNS consciously on lab network.

---

Key points

• MQTT uses a broker and topics for pub/sub messaging.
• Fits many IoT devices and push commands better than polling HTTP.
• QoS trades reliability for overhead.
• Pair with connectivity architecture for provisioning and security.