Understand how MQTT and IoT communication protocols enable smart building applications — how MQTT works, the publish-subscribe model, and how IoT devices connect building systems to cloud platforms and analytics tools.
The Rise of IoT in Buildings
Traditional building automation uses BACnet, Modbus, and proprietary protocols designed for closed, deterministic control systems. The Internet of Things (IoT) revolution has brought a new class of devices — inexpensive wireless sensors, cloud-connected meters, and IP-enabled equipment — that don't natively speak BACnet but generate valuable data. MQTT (Message Queuing Telemetry Transport) has emerged as the de facto standard for IoT device communication in buildings and across industry.
What Is MQTT?
MQTT is a lightweight, publish-subscribe messaging protocol developed by IBM in 1999 for low-bandwidth, high-latency networks (originally satellite links for pipeline monitoring). It is now an OASIS standard (ISO/IEC 20922) and has become the dominant IoT protocol due to its minimal overhead, simplicity, and ability to run on microcontrollers with limited memory.
MQTT runs over TCP/IP and requires only a ~2-byte header per message — far lighter than HTTP/REST. A sensor running on a coin cell battery can publish temperature readings via MQTT for months. This makes MQTT suitable for battery-powered wireless sensors throughout a building.
The Publish-Subscribe Model
MQTT uses a broker-based publish-subscribe architecture:
- Publisher — a device (temperature sensor, energy meter, occupancy sensor) that sends data to a topic
- Broker — a server (Mosquitto, HiveMQ, AWS IoT Core) that receives messages from publishers and routes them to subscribers. The broker decouples publishers from subscribers — neither needs to know about the other
- Subscriber — an application (analytics platform, BMS, dashboard) that registers interest in a topic and receives all messages published to it
- Topic — a hierarchical string identifier for a data stream, e.g., "building/floor3/zone4/temperature" or "campus/building-a/meter/kwh"
When a CO₂ sensor publishes "415 ppm" to "campus/hvac/zone12/co2", every subscriber to that topic (the BMS, an analytics platform, a real-time dashboard) receives the value simultaneously — without the sensor needing to know who is listening.
MQTT in Building Applications
Edge-to-cloud data pipelines — IoT sensors and meters publish to a local MQTT broker (an edge gateway), which forwards to a cloud MQTT broker (AWS IoT Core, Azure IoT Hub). Cloud analytics platforms subscribe and process data at scale across entire building portfolios.
Wireless sensor networks — LoRaWAN and Zigbee-connected sensors publish occupancy, temperature, and energy data to MQTT brokers. These sensors can be deployed anywhere in a building with no wiring, enabling granular monitoring that would be prohibitively expensive with wired sensors.
BACnet-MQTT integration — Translation gateways (SoftDEL, Niagara, Tridium) bridge BACnet devices to MQTT topics, making traditional BMS data available to cloud analytics and machine learning platforms.
Spark Plug: MQTT for Industrial Systems
The Eclipse Sparkplug specification (developed by Cirrus Link) defines a standardized payload schema for MQTT in industrial applications, ensuring consistent device metadata, data quality timestamps, and birth/death certificates (session management for reliable device state tracking). Sparkplug B is increasingly adopted in smart building and IIoT applications where data interoperability across platforms is required.