IoT Protocols: MQTT & LoRaWAN

The older building protocols are mostly poll-driven: a master (the BMS) walks around asking each device what is your value now? over and over. It is simple and predictable, and it works when devices are few, powered and on a fast wire. But it is chatty and wasteful - most answers are unchanged - and it couples every consumer of data tightly to every producer, because the asker must know exactly who to ask and how.

Publish/subscribe (pub/sub) flips this. A device (a publisher) sends a message only when it has something to report - a new reading, a state change - to a central broker, tagged with a topic. Anyone interested (a subscriber) tells the broker which topics it wants, and the broker forwards matching messages. Crucially, publishers and subscribers never need to know about each other - they only know the broker and the topic. This decoupling is the superpower: you can add a new dashboard, a new analytics job or a digital twin as just another subscriber, without touching the sensors, and a sensor can sleep between events, saving battery and bandwidth. Event-driven pub/sub is why the modern IoT and twin data plane looks so different from a polled BMS.

There is a subtler benefit too. Polling makes scaling painful: doubling the sensors roughly doubles the questions the master must ask, and adding a new consumer means teaching it who to poll. Pub/sub scales the other way - the broker fans messages out, so adding the ten-thousandth sensor or the fifth dashboard barely disturbs anything. This is not to say polling is obsolete; for a small, fixed set of wired controllers it is perfectly sensible, which is why the older protocols still poll happily. But for sprawling, changing, battery-powered fleets, event-driven wins decisively.

MQTT (originally MQ Telemetry Transport, now an OASIS standard) is the dominant lightweight messaging protocol of the IoT, and the pub/sub model above is exactly how it works. It was designed for constrained devices and unreliable networks - tiny message headers, minimal overhead, and it runs over standard TCP/IP so it rides any IP network, wired or wireless.

At its centre is the MQTT broker (such as Eclipse Mosquitto or HiveMQ). Devices publish to hierarchical topics like site/floor2/room14/temperature, and clients subscribe to topics or wildcards (site/floor2/# for everything on floor 2). MQTT adds practical touches: Quality of Service (QoS) levels let you choose at-most-once, at-least-once or exactly-once delivery; retained messages keep the last value for new subscribers; and a last will and testament lets the broker announce when a device drops off. Because it is IP-native, decoupled and frugal, MQTT has become the common data plane connecting sensors, gateways, platforms and digital twins - very often the protocol on which a twin actually receives its live stream. It carries messages but, like a network, does not itself define their meaning; a payload convention (often JSON, sometimes with Sparkplug or a schema) supplies that.

Because MQTT is a common data plane, it is also a place where security must be taken seriously: brokers should use TLS encryption, authenticate every client, and restrict which topics a client may publish or subscribe to, so a compromised sensor cannot read or forge the whole building's data. As with the network, treat this hardening as work for qualified professionals rather than a default left open.

MQTT still assumes an IP network. For battery sensors scattered where no cable and no mains reach - a car park, a basement, a sprawling campus - you need low-power wireless that gets the reading to a gateway, which then often republishes it over MQTT.

LoRaWAN is built for long range and tiny power. Using LoRa radio in unlicensed sub-GHz bands, a sensor can reach a gateway kilometres away through walls and floors and run for years on a small battery - at the cost of very low data rates and infrequent messages. Its architecture is a star-of-stars: end devices talk to any gateway in range; gateways forward to a central network server, which deduplicates and hands data to the application. It is ideal for sparse, low-frequency telemetry: utility meters, leak and environmental sensors, occupancy counts across a large estate.

Zigbee (and its cousins Z-Wave, Thread and BLE) serves the shorter, denser indoor case. Zigbee forms a self-healing mesh where mains-powered devices relay for battery ones, giving reliable room-scale coverage - common in smart lighting, plugs and home and building sensor networks. The trade is range and topology: Zigbee blankets a floor with a mesh; LoRaWAN reaches across a site with a star. Both exist because Wi-Fi is too power-hungry for a coin-cell device meant to last years.

These low-power radios come with honest limits worth stating plainly. Their low data rates suit small, occasional messages, not video or fast control. Unlicensed bands are shared, so heavy use in a dense area can bring congestion. And range figures quoted by vendors assume open conditions - thick concrete, steel and basements cut them sharply, which is exactly why a proper site survey, not optimism, should decide gateway placement. Used within those limits, though, they are transformative for retrofits.

These protocols are not rivals so much as specialists for different distances and constraints, and real buildings layer them. A practical decision guide:

Use MQTT as the IP-level data plane whenever devices or gateways can reach an IP network and you want decoupled, event-driven streaming into a platform or twin - it is the connective tissue above the field. Use LoRaWAN for sparse, battery, long-range telemetry where messages are small and infrequent and no IP or mains is available. Use Zigbee/Thread/BLE for dense, room-scale, battery devices - lighting, indoor sensors, wearables - where a self-healing mesh suits. Keep BACnet/Modbus/KNX (last lesson) for the wired plant and controls they were built for.

A typical modern building runs several at once: KNX and BACnet on the wired plant, Zigbee meshes in fit-out zones, LoRaWAN for far-flung meters - all normalised at gateways and carried upward over MQTT into the platform and twin. The skill is not loyalty to one protocol but matching each to its niche, and recognising the gateways that translate low-power and legacy worlds into a single, clean IP stream. That stream is what the twin ultimately drinks from.

Picture retrofitting an occupied office with fresh sensing without rewiring it. You scatter battery CO2, temperature and occupancy sensors through the floors. Indoors, in dense zones, they join a Zigbee mesh to a floor gateway; the far basement plant room and the outdoor car-park meters, too remote for the mesh, use LoRaWAN to a rooftop gateway and its network server.

Both gateways translate their low-power worlds into MQTT, publishing to tidy topics - office/floor3/zoneB/co2, office/carpark/meter1/kwh. A single MQTT broker now holds the whole live stream. The BMS, an analytics service and the digital twin each subscribe to the topics they care about, entirely unaware of whether a given reading arrived by Zigbee or LoRaWAN. Add a new energy dashboard next month and it is just one more subscriber - no sensor is touched.

This is the modern pattern in miniature: low-power wireless at the edge, gateways translating, MQTT as the decoupled data plane, and the twin as one more subscriber. It is frugal, flexible and retrofit-friendly - everything the polled, wired protocols of the last lesson are not, and the reason both generations coexist in one building.