HVAC IoT Protocols Compared: MQTT vs BACnet vs Modbus

You’ve just commissioned a new chiller plant. The BACnet controller talks to the VFDs over MS/TP, but the client wants the data on a cloud dashboard. You stand there with a laptop, a USB-to-RS485 dongle, and a sinking feeling. This is the classic HVAC IoT headache: the building speaks BACnet, the industrial gear speaks Modbus, and the cloud only understands MQTT.

This article cuts through the protocol noise. You’ll get a direct comparison of MQTT, BACnet, and Modbus with real numbers for latency, payload size, and security overhead. You’ll also see how to bridge them without ripping out existing controllers. By the end, you’ll know which protocol to use where, and how to build a hybrid system that actually survives contact with a real job site.

If your remote sites have no cellular or Wi-Fi coverage at all, a satellite gateway like the APAL Hestia A1 IoT Dongle can carry Modbus RTU traffic over a 3GPP NTN satellite link. It acts as a Modbus slave device, so your existing PLC or RTU treats it like any other sensor node. Two-way communication means you can send setpoint changes back down the pipe, not just receive telemetry.

The HVAC IoT Protocol Landscape: Why This Comparison Matters

Most facilities run a mix of protocols because they were built in layers. The 1990s gave us Modbus for VFDs and meters. The 2000s brought BACnet for BAS controllers. The 2020s added MQTT for cloud dashboards and analytics. Each protocol solved a specific problem at a specific time, and now you have to make them talk to each other.

The cost of getting this wrong is real. A gateway that polls too slowly misses alarm conditions. A payload that’s too large eats satellite bandwidth. A security misconfiguration exposes your entire BAS to the internet. These aren’t theoretical risks; they’re daily operational headaches.

You need a decision framework, not just a feature list. That means understanding three things: how each protocol moves data, what it costs to run, and where it breaks down. Let’s start with the youngest of the three.

MQTT: The Publish/Subscribe Heavyweight for Cloud-Native HVAC

MQTT was designed for low-bandwidth, high-latency networks in the 1990s, but it found its real home in IoT. It uses a publish/subscribe model with a central broker. Devices publish to topics like building1/floor3/ahu2/temp, and subscribers get messages based on topic filters. The broker handles routing, so publishers don’t know or care who’s listening.

The protocol uses a fixed header of just 2 bytes, plus topic name and payload. A typical temperature reading with a JSON payload runs 80–150 bytes. With binary encoding, you can push it under 20 bytes. That’s lean enough for satellite links or cellular plans with tight data caps.

Quality of Service (QoS) levels matter here. QoS 0 sends a message once with no acknowledgment — fast but lossy. QoS 1 guarantees at-least-once delivery with an ACK. QoS 2 ensures exactly-once with a four-way handshake. For HVAC alarms, QoS 1 is the sweet spot. QoS 2 doubles the handshake overhead for no practical gain in a building context.

Strengths and Weaknesses of MQTT

Strengths: MQTT handles thousands of clients through one broker. It’s firewall-friendly since clients initiate outbound connections on port 8883 (TLS) or 1883 (plain). It supports retained messages, so a new subscriber instantly gets the latest state. And it’s async — no polling, no wasted bandwidth.

Weaknesses: MQTT has no native concept of points, units, or alarm priorities. You build that logic yourself in the topic hierarchy and payload schema. It also depends on a broker; if the broker goes down, all communication stops. Finally, MQTT is TCP-based, so it’s not ideal for real-time control loops that need deterministic latency under 50 ms.

One more thing: MQTT brokers need proper authentication. Too many projects ship with open brokers on port 1883. That’s how you get strangers controlling your AHUs. Use TLS, client certificates, and strong passwords from day one.

BACnet: The Building Automation Standard for Interoperability

BACnet (Building Automation and Control Networks) is the ISO 16484-5 standard. It defines objects (analog inputs, binary outputs), services (ReadProperty, WriteProperty), and network layers. Its big advantage is semantic richness. A BACnet object knows its units, its alarm limits, and its reliability status. You don’t guess whether a value is in Celsius or Fahrenheit; the object tells you.

BACnet supports multiple data link layers. The two you’ll see most are BACnet/IP over Ethernet and BACnet MS/TP over RS-485. There’s also BACnet/SC (Secure Connect) which runs over TLS and WebSockets, but adoption is still early.

For HVAC, BACnet’s alarm and event services are the standout feature. You can configure COV (Change of Value) subscriptions, so a controller only sends data when something changes. That cuts bandwidth dramatically compared to polling.

BACnet/IP vs. MS/TP: When to Use Which

BACnet/IP runs over standard Ethernet. It’s fast, supports hundreds of devices, and integrates easily with IT networks. Use it for supervisory controllers, head-end workstations, and anything that needs high bandwidth. The downside is that BACnet/IP broadcasts (Who-Is, I-Am) can flood a network if you have many devices. Segment your VLANs and set proper broadcast limits.

BACnet MS/TP runs over RS-485 at 9.6 to 76.8 kbps. It’s slow, but it’s robust and cheap. You can run 100+ devices on a single twisted pair. Use it for field-level controllers, VAV boxes, and sensors where 100 ms response time is fine. The catch: MS/TP requires careful termination and biasing. A bad ground or a missing terminator causes intermittent comms that are a nightmare to diagnose.

My honest take: don’t put real-time control on MS/TP. Use it for monitoring and setpoint updates. If you need sub-100 ms response, wire those points to a local controller and let MS/TP handle supervisory traffic.

Modbus: The Industrial Veteran for Point-to-Point Simplicity

Modbus has been around since 1979. It’s the lingua franca of industrial equipment — VFDs, power meters, and sensors. The protocol is dead simple: a master polls slaves, and each slave responds with register values. No subscriptions, no discovery, no semantics. You map registers to meanings in a spreadsheet or a gateway config file.

Modbus RTU runs over RS-485 or RS-232. A typical request frame is 8 bytes: address, function code, register address, data, and CRC. Response times depend on baud rate and slave count. At 9600 baud, a 100-register read takes roughly 100 ms. At 115200 baud, it drops to about 10 ms.

Modbus TCP runs over Ethernet, using the same register model but with a 7-byte MBAP header. It’s faster and easier to route, but it lacks the broadcast isolation that MS/TP gives you. You’ll often see Modbus TCP used inside a plant room while Modbus RTU connects remote field devices.

Modbus RTU vs. TCP: Speed vs. Compatibility

Modbus RTU is the workhorse for legacy and remote installations. It’s what you’ll find on most VFDs and solar inverters. It’s also what the APAL Hestia A1 speaks natively as a slave device. The trade-off is speed and cable length — RS-485 caps at 1200 meters without repeaters, and polling multiple slaves adds latency.

Modbus TCP is faster and supports more concurrent connections. It also lets multiple masters poll the same slave, which RTU doesn’t. But TCP introduces a subtle issue: it’s easy to leave a socket open and exhaust the slave’s connection limit. Set a proper timeout and close idle connections.

Here’s the thing about Modbus: it has no security layer. No authentication, no encryption, no authorization. Anyone who can reach the IP port can read and write registers. Never expose Modbus TCP directly to the internet. Put it behind a firewall or a VPN, or front it with an MQTT gateway.

Head-to-Head: MQTT vs. BACnet vs. Modbus (Latency, Payload, Security)

Let’s put the numbers side by side. These are typical values from real deployments, tested under identical conditions on a 100 Mbps LAN with no congestion.

Metric	MQTT (QoS 1)	BACnet/IP	Modbus TCP
Typical latency (1 point)	5–20 ms	2–10 ms	1–5 ms
Typical latency (100 points)	50–150 ms (batch publish)	20–60 ms (COV or read-multiple)	100–300 ms (serial polling)
Minimum payload (1 point)	~20 bytes (binary)	~30 bytes (object + value)	8 bytes (register read)
Typical payload (JSON)	80–150 bytes	N/A (proprietary encoding)	N/A
Native security	TLS, client certs	BACnet/SC (TLS), otherwise none	None
Data model semantics	User-defined topics	Standard objects & units	Register map only
Bandwidth efficiency	High (async, no polling)	High (COV subscriptions)	Low (polling overhead)
Ideal for	Cloud dashboards, analytics	BAS interoperability	Field devices, legacy gear

One pattern stands out: Modbus is fastest for a single point but scales poorly. BACnet is efficient for building-wide data because of COV. MQTT is the only one designed for lossy, high-latency networks like satellite or cellular.

Security is the biggest differentiator. MQTT with TLS gives you encryption and mutual authentication out of the box. BACnet and Modbus need a gateway or a VPN to be safe. If you’re sending data to the cloud, MQTT over TLS 1.3 on port 8883 is the only reasonable choice.

The Hybrid Approach: Combining MQTT with BACnet/Modbus for Best Results

You don’t have to pick one. The winning architecture for most modern HVAC IoT projects is a bridge: Modbus and BACnet at the field level, MQTT as the supervisory data highway to the cloud.

Here’s how it works in practice. Your VFDs talk Modbus RTU to a plant controller. That controller also speaks BACnet/IP to the building BAS. A protocol gateway (or an edge computer running a gateway service) subscribes to BACnet COV updates and republishes them as MQTT topics to a cloud broker. The cloud dashboard never sees BACnet or Modbus; it only sees clean MQTT topics.

This gives you the best of all worlds. Field devices keep their native protocols for control. The BAS keeps its interoperability. The cloud gets a consistent, lightweight data stream. And you can add edge computing at the gateway to do local alarming or data filtering before anything hits the network.

For satellite-connected sites, the bridge becomes even more important. You don’t want to poll Modbus registers over a satellite link — that’s a waste of bandwidth. Instead, the gateway buffers data, publishes only changes, and uses MQTT QoS 1 to ensure delivery. The APAL Hestia A1 fits here as the satellite modem that carries MQTT or Modbus data from remote pumps or weather stations back to your cloud broker.

Migration Strategy: Upgrading Legacy Systems Without Downtime

Retrofitting a 20-year-old Modbus plant with MQTT doesn’t mean replacing controllers. It means adding a translation layer. The trick is to do it in stages so you never lose visibility or control.

Start with a read-only pilot. Install a gateway that polls the existing Modbus RTU network and publishes data to MQTT. Run it in parallel with your existing SCADA for two weeks. Verify the data matches. This costs nothing in downtime and proves the bridge works.

Next, add write capability for non-critical points. Use MQTT topics to send setpoint changes to the gateway, which converts them to Modbus writes. Test on a single VFD or a lighting panel before touching anything safety-critical. Keep the original BAS as the fallback control path.

Finally, migrate alarms and events. Map Modbus register changes to MQTT topics with proper QoS. Configure the cloud platform to send alerts via email or SMS. Once you trust the new path, you can decommission the old polling system.

A few practical warnings. Watch out for register mapping errors — a wrong offset causes you to write to the wrong point. Always add a sanity check in the gateway that rejects writes outside a valid range. And document every point mapping in a spreadsheet; you’ll thank yourself in six months when someone asks why a value looks wrong.

For deeper insight into how edge computing fits into this architecture, check out this edge computing guide for HVAC IoT.

Decision Matrix: Choosing the Right Protocol for Your HVAC Project

Use this as a practical checklist. Answer these questions honestly, and the protocol choice becomes obvious.

• Is the data going to the cloud? If yes, MQTT is your transport layer. Period. BACnet and Modbus don’t have native cloud integrations that scale.
• Do you need interoperability between multiple vendors’ BAS equipment? BACnet is the only real answer. It’s the ISO standard for a reason.
• Are you connecting field devices like VFDs, meters, or sensors? Modbus RTU or TCP is almost always the native option. Use it at the edge, then bridge to MQTT.
• Is the site remote with no internet? You need a satellite or cellular gateway. Look for one that supports Modbus slave mode and MQTT publish, like the Hestia A1.
• What’s your acceptable latency? For control loops under 50 ms, stay on BACnet/IP or Modbus TCP locally. For monitoring and alarms, MQTT is fine.
• What’s your security posture? If you expose anything to the internet, it must be MQTT over TLS or behind a VPN. Never expose raw BACnet or Modbus ports.

Here’s a simple rule of thumb: use Modbus for the last meter to the device, BACnet for the building backbone, and MQTT for everything beyond the building perimeter. That covers 90% of projects.

For a deeper look at the cost side of IoT upgrades, read this analysis of IoT cost implications in HVAC systems.

Future-Proofing Your HVAC IoT Architecture

The protocol landscape isn’t static. BACnet/SC is gaining traction for secure building networks. MQTT 5.0 adds features like message expiry and topic aliases that help with constrained networks. And edge computing is moving logic closer to the devices, reducing the need for round-trips to the cloud.

What hasn’t changed is the need for a clean data path. The protocols you choose today should be replaceable at the gateway layer, not baked into every controller. That’s the real lesson. Build your architecture so the field devices speak whatever they speak, and let the gateway translate to MQTT for the cloud. When the next protocol comes along, you swap the gateway, not the plant.

Also consider the human factor. Your maintenance team needs to troubleshoot these systems. A Modbus register map is easier to debug than a poorly documented MQTT topic tree. Keep your topic hierarchy simple and consistent. Use a naming convention like site/building/equipment/point and stick to it.

Finally, think about data retention. MQTT brokers don’t store history by default. You need a time-series database or a cloud platform that does. Budget for that storage and decide how long you keep raw data versus downsampled data. This is where most projects underestimate costs.

Frequently Asked Questions

Can MQTT replace BACnet entirely in a building?

Not yet. BACnet carries semantic meaning about points, alarm states, and scheduling that MQTT doesn’t have. You can replicate that logic in MQTT topics and payloads, but you’d be rebuilding the BACnet object model from scratch. It’s more practical to keep BACnet for BAS interoperability and use MQTT as the cloud-facing layer.

What’s the fastest way to get Modbus data into MQTT?

Use a protocol gateway or an edge computer with a Modbus master library and an MQTT client library. Poll the Modbus registers on a fixed interval (e.g., every 5 seconds), then publish changes to MQTT. Start with QoS 1 and a retained message for each point so new subscribers get the current state immediately.

Is BACnet MS/TP too slow for modern HVAC IoT?

It’s slow compared to Ethernet, but it’s not obsolete. MS/TP at 76.8 kbps handles hundreds of points if you use COV subscriptions instead of polling. Use it for field-level control and monitoring. Don’t use it for high-frequency data logging or video. Bridge it to BACnet/IP or MQTT at the supervisory level.

How do I secure MQTT for HVAC applications?

Use TLS 1.2 or 1.3 on port 8883. Require client certificates or strong username/password credentials. Disable anonymous access on the broker. Use separate topics for read and write permissions, and restrict write topics to authorized clients. Set a reasonable message size limit to prevent DoS attacks. And never expose the broker on the public internet without a VPN or a reverse proxy.

What’s the real cost difference between these protocols?

Hardware cost is similar — a gateway that handles all three costs roughly the same as one that handles only two. The bigger cost is commissioning time. Modbus requires manual register mapping. BACnet has auto-discovery but needs proper object configuration. MQTT requires designing the topic tree and payload schema. Budget 2-3 days of engineering time for a typical 100-point retrofit, mostly for point mapping and testing.

What to Do Next

• Audit your existing field devices. List which ones speak Modbus, which speak BACnet, and which are proprietary.
• Pick a gateway that supports all three protocols natively. Test it on a bench before touching the live plant.
• Design your MQTT topic hierarchy on paper first. Include site, building, system, equipment, and point in each topic.
• Set up TLS and authentication on your broker before you connect any device. Don’t skip this step.
• Start with a read-only pilot for two weeks. Verify data accuracy against your existing BAS.
• Plan for edge computing at the gateway to filter noise and reduce cloud bandwidth.
• Document every point mapping and topic name in a shared spreadsheet. Future you will be grateful.

The bridge architecture — Modbus and BACnet at the edge, MQTT to the cloud — is the most practical path forward for existing buildings and new projects alike. It respects the installed base while giving you modern IoT connectivity. Start small, verify everything, and scale from there.