Ensmart BMS Academy 📞 +91 99410 42612 Home
Products
Solutions
Knowledge Hub
Company
Contact Get a Demo →

MQTT for IoT in Buildings — Light Protocol for Light Devices

Copied to clipboard ✓
MQTT for IoT in Buildings — Light Protocol for Light Devices — infographic

A Bengaluru Co-Working Office, 240 Tiny Sensors

Asha is the IT lead at a Bengaluru-based co-working chain. The flagship office covers four floors and seats 600 members. The CTO has approved a smart-office pilot: ``` 200 occupancy sensors (one per desk cluster) 40 air-quality sensors (CO2, VOC, PM 2.5 per zone) 30 desk-availability lights (LED with controllable colour) 20 meeting-room status displays (large e-ink panels at each room door) ``` All 290 devices are battery-powered or POE Lite. None of them have the room — physical, electrical, or budgetary — to run a BACnet IP stack. Their job is to wake up every minute, send a small reading, and go back to sleep. The BMS team suggests BACnet MS/TP. Asha runs the math: ``` 290 devices on MS/TP would need 9-10 segments Each segment needs 120-ohm termination, biasing, daisy-chain wiring The wiring cost alone exceeds the cost of the sensors Battery life under MS/TP polling: under 6 weeks ``` This is not what BACnet is built for. There is a better protocol for tiny devices. Every single one of these problems has one solution — MQTT, the protocol designed for tiny devices that wake briefly and sleep most of the time.

What MQTT Is Built For

MQTT (Message Queuing Telemetry Transport) was published by IBM in 1999 to send sensor data over very thin links — the original use case was monitoring oil pipelines through satellite. It is now the dominant IoT protocol. ``` MQTT design priorities: Low overhead A typical MQTT message is 2-byte header + payload. Compare to BACnet's 8-12 bytes of overhead per packet. Battery friendly Devices can sleep, wake briefly to publish, and sleep again. No keep-alive polling required by the protocol. Asynchronous Publishers and subscribers do not need to know about each other. The broker mediates everything. Topic hierarchy Messages are tagged with a topic path (e.g., office/floor3/zone-A/occupancy). Subscribers can filter by full topic or wildcard. Quality of Service levels QoS 0 — fire and forget (lowest overhead) QoS 1 — at least once delivery (acknowledged) QoS 2 — exactly once delivery (highest reliability) ``` For occupancy and air-quality sensors that wake every minute, MQTT QoS 0 is enough. The overhead per message is single digits of bytes, and the device can sleep 99 percent of the time.

Architecture — Broker, Publishers, Subscribers

``` Layer 1 — Devices (Publishers) Each sensor has an MQTT client. Wakes, connects to broker, publishes its reading on a topic. Disconnects, sleeps until next interval. Layer 2 — MQTT Broker A small server (often inside the building, on an edge gateway, sometimes in cloud). Receives all messages. Distributes them to subscribers based on topic. Layer 3 — Subscribers Dashboards, analytics platforms, and crucially, an MQTT-to-BACnet bridge that translates relevant topics into BACnet objects for the BMS to consume. ``` For Asha's site: ``` Topics published by sensors: building/blr-flagship/floor3/zoneA/occupancy → 0 or 1 building/blr-flagship/floor3/zoneA/co2 → ppm building/blr-flagship/floor3/zoneA/voc → index building/blr-flagship/floor3/zoneA/pm25 → µg/m³ building/blr-flagship/floor3/desk-status/desk-37 → "free" / "occupied" building/blr-flagship/floor3/meeting/conf-A → "open" / "booked" Subscribers: Operations dashboard (subscribes to .../co2, .../pm25) Member-app server (subscribes to .../desk-status/+) BMS bridge (subscribes to .../zoneA/co2, .../zoneA/occupancy) Building manager Slack alerts (subscribes to .../+ with QoS thresholds) ``` The BMS sees the relevant topics translated into BACnet objects (AV-301 "Floor 3 Zone A CO2" etc.) and uses them for demand-controlled ventilation.

Topic Taxonomy — The Most Important Decision

The single biggest determinant of MQTT success is the topic naming convention. Once 290 sensors are deployed, renaming topics is painful. Get it right on day one. ``` Recommended pattern: building/<building-code>/<floor>/<zone>/<measurement> Avoid: building/<vendor-brand>/... (vendor lock-in) /room1/sensor1/data (no hierarchy, no clarity) building.flagship.floor3.co2 (dot-separated; some clients prefer slashes; mixing breaks) Wildcards subscribers can use: building/blr-flagship/floor3/+/co2 all zones on floor 3, CO2 only building/+/+/+/occupancy every occupancy sensor in every building building/blr-flagship/# everything in this building ```

Retained Messages — The Late-Joiner Trick

When a new dashboard or new BMS bridge connects to the broker, it has missed all the messages published before it joined. MQTT solves this with retained messages: the broker holds the most recent message per topic and delivers it to any new subscriber on subscribe. ``` Sensor publishes (with retain flag) CO2 = 850 ppm on topic .../zoneA/co2 Broker stores "850 ppm" against that topic New subscriber connects receives "850 ppm" immediately Dashboard shows current state without waiting 60 seconds for the next publish ``` This is critical for occupancy and air-quality dashboards — operators see the current state immediately, not blank screens.

MQTT to BACnet — Why You Still Need the Bridge

The BMS needs the air-quality data for demand-controlled ventilation. The BMS speaks BACnet, not MQTT. A small bridge — typically running on an edge gateway — does the translation: ``` MQTT topic BACnet object ───────────────────────────────────────────────────────────────── building/.../floor3/zoneA/co2 → AV-301 (writable) building/.../floor3/zoneA/occupancy → BV-301 (read-only) building/.../floor3/zoneA/pm25 → AV-302 ``` The BMS controllers read AV-301 and AV-302 as native BACnet objects and feed them into the AHU's CO2-driven damper logic.

Security

MQTT is light, and that lightness can become a security risk if deployed without thought. Three things are essential: ```
  1. TLS encryption between device and broker.
No clear-text MQTT on production buildings.
  1. Username/password or certificate authentication for every device.
No anonymous publish/subscribe on production topics.
  1. Topic-level permissions on the broker.
Sensors can publish only to their own topic prefix. Dashboards can subscribe but not publish to sensor topics. ``` The broker (Mosquitto, EMQX, HiveMQ, etc.) handles these natively. Configuration is one-time and worth the hour.

When MQTT Is the Wrong Answer

``` Do not use MQTT for: - Critical control of HVAC equipment (use BACnet). - Equipment with safety interlocks (use hardwired or BACnet). - Devices that must respond deterministically within milliseconds (use industrial protocols or BACnet MS/TP). - Long-term audit-grade records (validated EnvMS, not MQTT). ``` MQTT is excellent for telemetry from many small devices — it is not a control protocol.

Why This Matters Now

Indian smart-office and smart-building deployments are increasingly mixed-protocol — BACnet for HVAC and utilities, MQTT for IoT sensors and member-app integrations, OPC UA for any factory tie-ins. The bridges between them are now standard products, not custom code. Asha's 240 sensors connect via MQTT, are visible to her BMS via the bridge, and feed her member app via direct subscription. Battery life is over 18 months. The BMS gets the air-quality data it needs for DCV. The wiring cost is zero — everything is wireless. BACnet runs the building. MQTT carries the IoT. The bridge between them is the modern smart-office architecture. Light protocols for light devices, heavy protocols for heavy control — and a small server that quietly translates one to the other.

Related Topics


Related Topics


Related Topics


Related Topics

Was this answer helpful? ✓ Thanks — your feedback was recorded.

Have a different question?

✦ Ask the AI BMS Mentor → More from Protocols →