Overview

If Modbus and BACnet solve the problem of device communication within buildings, MQTT answers a fundamental question of the IoT era: how do thousands of geographically dispersed sensors push data to the cloud efficiently, reliably, and at low cost? As a lightweight publish/subscribe messaging protocol designed specifically for IoT scenarios, MQTT has become the de facto standard for sensor-to-cloud integration. This article examines MQTT from three dimensions: protocol principles, core mechanisms, and engineering practice.

1. MQTT: Born for the Internet of Things

1.1 Protocol Background

MQTT (Message Queuing Telemetry Transport) was originally designed by IBM in 1999 for remote monitoring of oil pipelines. The original scenario was extremely challenging: thousands of sensor nodes spread across vast deserts, transmitting data over expensive and unstable satellite links—narrow bandwidth, high latency, and frequent disconnections. MQTT’s design goal was to achieve reliable message delivery with minimal overhead in such “weak-network” environments.

In 2014, MQTT 3.1.1 became an OASIS international standard; the MQTT 5.0 specification released in 2019 further enhanced error reporting, shared subscriptions, message expiry, and other capabilities. Today, MQTT holds an absolutely dominant position among IoT messaging protocols—leading cloud providers including AWS IoT, Azure IoT Hub, and Alibaba Cloud IoT Platform all adopt it as their standard access protocol.

1.2 Publish/Subscribe Model

Unlike Modbus’s master-slave polling or BACnet’s peer-to-peer communication, MQTT adopts a publish/subscribe model that introduces a key intermediary—the Broker:

Sensor A ──publish──▶ ┌──────────┐ ◀──publish── Sensor B
                      │  Broker  │
App C ◀─subscribe──── └──────────┘ ───subscribe──▶ App D

• Publisher: Sensor nodes that publish data to specific topics
• Subscriber: Applications that subscribe to topics of interest to receive data
• Broker: The message intermediary responsible for routing, distribution, and persistence

The greatest advantage of this architecture is decoupling: sensors don’t need to know who consumes their data, and applications don’t need to care which device the data comes from. Adding a new analytics application requires only subscribing to the relevant topics—existing sensor deployments remain completely unaffected.

1.3 Topic Design

Topics are the routing core of MQTT, using a hierarchical structure separated by slashes:

building01/3F/VAV01/temperature
building01/3F/VAV01/humidity
building01/3F/VAV01/CO2

Wildcard subscriptions are supported: - +: Matches a single level (e.g., building01/+/VAV01/temperature subscribes to VAV01 temperature on all floors) - #: Matches all remaining levels (e.g., building01/# subscribes to all data for that building)

Well-planned topic design is critical to project success. Establish a unified topic naming convention during the design phase, including dimensions such as building, floor, equipment type, device ID, and data point, to avoid chaos later.

2. Core Mechanisms

2.1 QoS Levels

MQTT provides three quality-of-service levels, offering flexible trade-offs between reliability and overhead:

Engineering experience: Sensor telemetry typically uses QoS 0—reporting temperature and humidity every 30 seconds means losing a frame occasionally has no impact on trend analysis. Alarm messages (smoke detection, equipment faults) should use QoS 1. QoS 2 has significant overhead and is rarely used in sensor scenarios.

2.2 Session Persistence and Will Messages

MQTT runs over TCP but includes a sophisticated session mechanism at the protocol layer:

• Clean Session: Whether the Broker retains session state (subscriptions, undelivered messages) after a client disconnects
• Keep Alive heartbeat: Clients periodically send PING packets to verify connection liveness (typical value: 60 seconds)
• Will Message: A client registers a “last message” at connect time; if the connection drops abnormally (rather than disconnecting gracefully), the Broker automatically publishes it—typically used to notify systems that “a sensor has gone offline”

The Will mechanism is extremely practical for sensor monitoring: each sensor registers a Will message such as “device offline alarm” upon connecting. If the device loses power or its network fails, all subscribers immediately receive a notification—enabling automatic device health supervision.

2.3 Retained Messages and LWT

• Retained Message: The Broker keeps the last retained message for each topic; new subscribers receive the current value immediately upon connecting—effectively a “latest state cache.” For sensor scenarios, a newly connected monitoring dashboard can instantly obtain the latest readings from all devices without waiting for the next reporting cycle.
• LWT (Last Will and Testament): As described above, combined with Will messages to implement offline detection.

2.4 MQTT 5.0 New Features

MQTT 5.0, released in 2019, brings several important enhancements:

• Reason Codes: Granular operation result feedback for clearer troubleshooting
• Message Expiry: Set TTL for messages; expired messages are automatically discarded—prevents massive backlogs of stale data flooding in after network recovery
• Shared Subscription: Multiple consumers load-balance consumption of the same topic—automatically distributes traffic when multiple data processors are deployed in the cloud
• User Properties: Custom key-value metadata for flexible extension

For large-scale sensor deployments (tens of thousands of devices online simultaneously), MQTT 5.0’s enhanced features significantly reduce operational complexity.

3. Engineering Practice for Sensor MQTT Integration

3.1 Typical System Architecture

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│ Temp/RH     │     │  Current    │     │   CO₂ Sensor     │
│ Sensor      │     │  Sensor     │     │                  │
│(MQTT direct)│     │(MQTT direct)│     │ (MQTT direct)    │
└──────┬──────┘     └──────┬──────┘     └────────┬────────┘
       │                   │                      │
       │ MQTT over TCP/TLS │ MQTT over TCP/TLS    │
       ▼                   ▼                      ▼
┌─────────────────────────────────────────────────────┐
│                Broker Cluster (HA)                   │
│            (EMQX / Mosquitto / Cloud IoT)           │
└──────────┬──────────────────────┬───────────────────┘
           │                      │
    ┌──────┴──────┐        ┌──────┴──────┐
    │ Time-Series │        │ Real-Time   │
    │ DB (InfluxDB)│       │ Alert Engine│
    └──────┬──────┘        └─────────────┘
           │
    ┌──────┴──────┐
    │ Visualization│
    │ (Grafana)   │
    └─────────────┘

For legacy sensors that don’t natively support MQTT (such as Modbus RTU devices), an edge gateway can perform protocol conversion: the gateway polls Modbus devices locally and publishes data upstream via MQTT—this “Modbus + MQTT” hybrid architecture is a typical pattern in building projects.

3.2 Security Practices

MQTT transmits in plaintext by default. Public deployments must implement proper security:

Transport Encryption (TLS) - Use MQTTS (MQTT over TLS, default port 8883) - Certificate management: Cloud IoT platforms typically provide automatic device certificate distribution; self-hosted Brokers can use Let’s Encrypt

Authentication and Authorization - Username/password authentication: Basic measure; enforce password strength - Client certificate authentication (mTLS): Device-level mutual authentication; highest security - ACL (Access Control Lists): Restrict each device to publishing/subscribing only within its own topic namespace, preventing device A from impersonating device B

Best practice: Assign unique credentials to each sensor, isolate topics by device ID, and use ACLs to implement the classic permission model of “devices can only write to their own topics; applications can read all topics.”

3.3 Message Payload Design

MQTT payloads typically use JSON or binary formats:

JSON (human-readable, ~30% bandwidth overhead):

{
  "device_id": "b01-3f-vav01",
  "timestamp": 1758096000,
  "temperature": 23.5,
  "humidity": 45.2,
  "co2": 680
}

Binary formats (e.g., Protocol Buffers, bandwidth-efficient): Suitable for massive device fleets with high-frequency reporting; encoded size can shrink by 60–80%, but requires additional encoding/decoding logic.

For battery-powered wireless sensors (e.g., LoRaWAN + MQTT gateway architecture), an aggregated reporting strategy is recommended: the gateway caches data from multiple sensors locally and uploads in batches, significantly reducing communication overhead.

3.4 Common Issues and Troubleshooting

Frequent disconnections: - Check Keep Alive settings—some NAT gateways silently drop TCP connections with no data flow for extended periods - Verify whether Broker’s max_connections and OS file descriptor limits have been reached - In weak-network environments, consider MQTT over WebSocket (ports 80/443) for better penetration

Message delays or loss: - QoS 0 messages may be dropped under high Broker load; upgrade critical data to QoS 1 - Check Broker message queue backlog (messages queued metrics) - After network partition recovery, clients with Clean Session=false can receive messages queued during the offline period

Device connection failures: - Verify ACL configuration—topic mismatch is the most common cause - TLS handshake failure: check certificate chain completeness and validity - Client ID conflicts: MQTT requires unique client IDs; duplicate IDs cause mutual kicking (one device disconnects the other)

4. MQTT vs Other IoT Protocols

In building energy monitoring scenarios, MQTT is best suited for the upstream “sensor → cloud platform” data channel; CoAP fits ultra-low-power terminals; HTTP serves REST API integration with third-party systems.

5. Summary

With its minimalist protocol design, flexible publish/subscribe model, and outstanding weak-network adaptability, MQTT has become the preferred protocol for IoT sensor data delivery to the cloud. For building automation and energy monitoring professionals, mastering MQTT means bridging the “last mile” from field sensors to cloud big data platforms. Combined with edge gateway protocol conversion, even traditional Modbus/BACnet devices can seamlessly join the MQTT ecosystem, enabling IoT upgrades of existing systems.

As MQTT 5.0 adoption grows and cloud IoT platforms mature, the barrier to connecting sensors to the cloud has dropped significantly—choose a reliable Broker, plan your topic namespace well, harden security, and your sensor network will be ready for the future.