If you've been involved in a BMS installation or upgrade, you've probably heard the terms BACnet and Modbus. Both are communication protocols — standardised ways for building automation devices to talk to each other. Choosing the right protocol for a project, or understanding why a building uses both, requires knowing what each protocol does well and where it falls short.
Modbus is the older of the two protocols, developed in 1979 by Modicon for industrial programmable logic controllers. It is simple, robust, and widely supported. Almost every piece of mechanical plant — chillers, boilers, variable speed drives, UPS systems, generators — supports Modbus RTU (over RS-485) or Modbus TCP (over Ethernet).
Modbus works on a master/slave model: one master device (typically a BMS controller) polls one or more slave devices (plant) in sequence, reading and writing register values. It has no built-in device discovery, no native alarm management, and no standard object model — the engineer must know which register holds which value for every device. Modbus is defined in BS EN 61158 as part of the fieldbus family of industrial communication standards; its simplicity — a master-slave architecture with no built-in discovery or object model — is both its strength in simple applications and its limitation in complex BMS networks.
The primary advantage of Modbus is universality. Almost every piece of mechanical plant you are likely to integrate — chillers, boilers, variable speed drives, UPS systems, generators, energy meters — supports it. It is straightforward to implement, easy to debug in the field, requires no specialist hardware, and is reliable over long RS-485 cable runs. Where the register map is documented and the integration scope is simple, Modbus is often the lowest-friction option available.
The limitations show at system level. There is no standard object model — each manufacturer assigns register addresses differently, so integrating unfamiliar plant means obtaining and working from its specific register map, and the same physical parameter may be at a completely different address on a different manufacturer's chiller. There is no native alarm management; the master must continuously poll to detect that a fault bit has changed. The master/slave topology does not scale naturally beyond a single trunk. And there is no built-in security of any kind — any device on the RS-485 bus can read and write to any other, with no authentication whatsoever.
BACnet (Building Automation and Control Networks) was developed specifically for building automation. BACnet is formally defined in ASHRAE 135 — the standard developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers and adopted as BS EN ISO 16484-5 in Europe; it defines over 50 object types and multiple physical layer options including BACnet/IP, MS/TP, and BACnet over Ethernet. Published in 1995 and adopted as an ISO standard in 2003, it was designed to solve exactly the problems that make Modbus awkward for building control: interoperability between devices from different manufacturers, native alarm management, and a standardised object model. For a deeper dive into the BACnet standard and what open protocol really means in practice, see our article on what BACnet is and why open protocol matters for BMS.
BACnet devices expose data as objects with standard properties. A temperature sensor is an Analog Input object with a Present_Value property. A chiller's fault status is a Binary Input. Any BACnet-compliant supervisory platform can discover and read these objects without needing a custom register map.
BACnet operates in several variants suited to different parts of the system hierarchy. BACnet/IP runs over standard Ethernet networks and is used for controller-to-supervisor and controller-to-controller communications — the backbone of any modern BMS installation. BACnet MS/TP runs over RS-485 twisted pair and handles field-level connections to sensors, actuators, and smaller outstations where Ethernet infrastructure isn't practical. More recently, BACnet SC (Secure Connect) — defined in ASHRAE Addendum bj to Standard 135 — adds WebSocket transport with TLS encryption, providing the authentication and confidentiality that traditional BACnet/IP lacks; it is increasingly being specified on projects where cybersecurity is a formal requirement of the brief.
The advantage of BACnet for system-level communications is substantial. A BACnet supervisor can discover devices automatically, read standard objects without a bespoke register map, and receive alarms and events natively rather than having to poll for fault states. A building running controllers from different manufacturers — Trend IQ4s alongside Distech ECBs and a third-party metering gateway — can appear on the same supervisory platform if all are BACnet-compliant, without custom protocol translation between them. The standard is actively maintained: BACnet SC directly addresses the security concerns that have made traditional BACnet/IP a liability on networks with any internet exposure.
The trade-off is complexity. BACnet requires a properly configured IP network — sensible VLANs, correct subnetting, a network that has been designed rather than grown organically over years of adds and changes. Engineers new to BACnet face a steeper learning curve than Modbus. And at the field device level, Modbus remains more universal — virtually any variable speed drive, chiller, or meter supports Modbus RTU; BACnet support at that level is more variable and not universal.
In practice, most modern BMS installations use both — BACnet for the main controller network and supervisor communications, and Modbus to integrate third-party plant that doesn't support BACnet.
| Use Case | Recommended Protocol |
|---|---|
| Controller-to-supervisor communications | BACnet/IP |
| Controller-to-field device (sensors, small outstations) | BACnet MS/TP |
| Integrating chillers, boilers, VRF systems | Modbus RTU or TCP (check manufacturer data) |
| Variable speed drives | Modbus RTU (universal support) |
| Energy meters | Modbus TCP or BACnet/IP (both widely supported) |
| Multi-site estate monitoring | BACnet/IP over VPN |
| Legacy system integration | Modbus or protocol gateway to BACnet |
Older buildings may have LON (LonWorks) or proprietary protocols from Johnson Controls, Honeywell, or Satchwell. These are generally harder to integrate with modern BMS platforms and often require protocol gateway hardware to bridge them onto BACnet or Modbus. The gateway approach works well but adds cost and a potential single point of failure — which is why legacy system migrations to open protocol platforms are increasingly common.
BACnet MS/TP is the most common source of field-level BMS problems. Key installation requirements that are often missed:
Alpha Controls tests all MS/TP trunks for impedance and topology before commissioning and documents end-of-line resistor positions on as-built drawings. See our BMS networking service for full detail.
BACnet/IP networks should be on a dedicated VLAN segregated from general IT traffic. Legacy BACnet has no built-in authentication — any device on the network can read and write to any BACnet device. BACnet SC (Secure Connect) resolves this for new installations, but most buildings are running standard BACnet/IP and rely on network segmentation as their primary security control. For a comprehensive look at BMS network vulnerabilities and how to address them, see our article on BMS cybersecurity.
Need help designing or troubleshooting your BMS network? Contact Alpha Controls — we design and install BACnet/IP and MS/TP networks across London and the South East.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
