For the BMS backbone — controller-to-controller and controller-to-supervisor communication — use BACnet, which was designed specifically for building automation and enables native interoperability between manufacturers. Use Modbus to integrate third-party field equipment like meters and drives. Most modern BMS installations use both protocols together.
BACnet — Building Automation and Control Networks — is an open communication protocol designed from the ground up for building automation. It was developed by ASHRAE (the American Society of Heating, Refrigerating and Air-Conditioning Engineers) starting in 1987, published as ASHRAE Standard 135 in 1995, and adopted as an international standard under BS EN ISO 16484-5. The current edition is BS EN ISO 16484-5:2022, which defines the data model, the communication services, and the network technology options that make up the BACnet ecosystem.
What makes BACnet different from other protocols is that it was designed around the specific needs of building systems. The data model is object-oriented: a BACnet device contains objects that represent real things — an Analog Input object for a temperature sensor, a Binary Output object for a pump relay, a Schedule object for a time programme, a Trend Log object for historical data. Each object has properties — present value, status flags, alarm limits, engineering units — that any BACnet client can read, write, or subscribe to. This means that a BACnet supervisor from one manufacturer can discover, read, and control devices from a completely different manufacturer without any custom driver, protocol converter, or integration middleware. The protocol handles the discovery, the data typing, and the semantics natively.
BACnet supports multiple network technologies. BACnet/IP runs over standard Ethernet and IP infrastructure, which is the dominant choice for new installations because it uses the building's existing network cabling and switches. BACnet MS/TP (Master-Slave/Token-Passing) runs over RS-485 serial wiring and is commonly used for field-level connections — linking a BACnet controller to its local I/O modules or to BACnet-native field devices like room sensors and VAV controllers. BACnet/SC (Secure Connect) is the newest addition, providing encrypted communication over standard IT network infrastructure with certificate-based authentication — a direct response to cybersecurity concerns about BMS networks running unencrypted on shared IP infrastructure.
Modbus is an industrial communication protocol developed by Modicon (now Schneider Electric) in 1979 for use with programmable logic controllers. It was not designed for buildings — it was designed for factories, process plants, and industrial automation. But its simplicity, its reliability, and the fact that it has been licence-free since its creation have made it one of the most widely implemented communication protocols in the world, including in building services.
Modbus operates on a simple register-based data model. Every piece of data is stored in a numbered register — a memory location that holds a 16-bit integer value. There are four types of registers: coils (single-bit outputs), discrete inputs (single-bit inputs), holding registers (16-bit read/write values), and input registers (16-bit read-only values). To read a temperature from a Modbus device, you need to know which register number contains the temperature value, what scaling factor to apply, and what data type the value represents — because Modbus itself carries no semantic information. Register 40001 might contain a supply air temperature in tenths of a degree Celsius, or it might contain a fan speed percentage, or it might contain an error code. The register map — a document published by the device manufacturer — is the only way to know what each register means.
Modbus comes in two physical variants. Modbus RTU runs over RS-485 serial wiring, using a master-slave architecture where one master device polls up to 247 slave devices on a shared bus. Modbus RTU is extremely reliable, simple to wire, and tolerant of electrically noisy environments — which is why it has survived for over forty years in industrial and building applications. Modbus TCP runs over Ethernet and IP, wrapping the same register-based data model in TCP/IP packets. Modbus TCP is faster than RTU, supports more simultaneous connections, and uses standard network infrastructure — but it adds the complexity and vulnerability of IP networking to what was originally a simple serial protocol.
The Modbus protocol is administered by the Modbus Organization, and the specification — BS EN 61158 covers fieldbus standards including Modbus — is freely available. Any manufacturer can implement Modbus without licence fees or certification requirements, which is why it appears in everything from energy meters to variable speed drives to heat pump controllers.
The protocol choice affects three things that building owners and FM teams care about: integration flexibility, long-term maintainability, and the cost of change.
On integration flexibility, BACnet wins decisively for BMS-to-BMS communication. If you have Trend controllers on the office floors and Distech controllers on the retail unit, BACnet allows them to share data natively — the Trend controller can read the Distech controller's room temperature and use it in its own control logic without any gateway or protocol conversion. On Modbus, this kind of cross-manufacturer data sharing is technically possible but practically cumbersome: you need to know the exact register map of each device, configure the polling manually, and handle the data type conversion in the receiving controller. BACnet does all of this automatically through its object model and discovery services.
On long-term maintainability, BACnet's self-describing data model means that a new maintenance contractor can connect to the network, discover all the devices, and read all the data points without any documentation from the previous contractor. Each BACnet object has a name, a description, engineering units, and alarm limits embedded in the device — the protocol is its own documentation. With Modbus, the maintenance contractor needs the register map for every device on the network. If the previous contractor did not leave the register maps — and in our experience, they often do not — the new contractor is reverse-engineering the system from scratch.
On cost of change, Modbus devices are generally cheaper than their BACnet equivalents. A Modbus energy meter costs less than a BACnet energy meter. A Modbus room sensor costs less than a BACnet room sensor. For simple point-to-point integrations — reading a meter value, monitoring a VSD status, pulling data from a heat pump controller — Modbus is perfectly adequate and the cost saving is real. But for the BMS backbone — the controller-to-controller and controller-to-supervisor communication — the false economy of Modbus becomes apparent over time, because every system modification, every contractor change, and every integration project is harder, slower, and more expensive without BACnet's native interoperability.
We'll assess your controls and provide a detailed quotation.
The most common mistake Alpha Controls encounters is a BMS specification that says 'open protocol' without specifying which protocol at which network level. The contractor installs BACnet-compliant controllers that support BACnet on the field bus, but runs a proprietary protocol on the trunk — and technically meets the specification because the field devices are open, even though the core of the system is locked. The specification needs to state BACnet/IP on the trunk, BACnet MS/TP or BACnet/IP on the field bus, and a supervisor that connects via native BACnet — not via a proprietary wrapper with a BACnet gateway on the side.
The second mistake is using Modbus for everything because it is simpler and cheaper. A BMS where the controllers, the supervisor, and all the integrated devices communicate via Modbus RTU will work — but it will be slow (polling-based, sequential, limited by the RS-485 bus speed), it will be fragile (a single device with a communication fault can stall the entire bus), and it will be undocumented (register maps get lost, scaling factors get forgotten, nobody remembers which register holds which value). For a small single-building system with ten or twenty devices, this is manageable. For a multi-building campus or a complex commercial building, it becomes an operational burden that grows with every system extension.
The third mistake is failing to specify the Modbus register map as a deliverable. When a Modbus device is integrated into a BMS, the register map — the complete list of register numbers, data types, scaling factors, and descriptions — must be documented and handed over as part of the O&M documentation. Without it, the next contractor cannot maintain the integration, and the building owner is dependent on the original integrator for any modification. Alpha Controls includes the register map in every project handover, but we routinely find that previous contractors have not — which means we spend engineering time reverse-engineering register maps that should have been documented at commissioning.
Two standards define the protocol landscape for UK building automation.
BS EN ISO 16484-5:2022 (also ASHRAE Standard 135) defines the BACnet protocol in its entirety: the object model, the services (Read Property, Write Property, Subscribe COV, Who-Is/I-Am discovery), the network technologies (IP, MS/TP, Ethernet, Secure Connect), and the conformance requirements. Devices that claim BACnet compliance should carry the BTL (BACnet Testing Laboratories) mark, which verifies that the implementation conforms to the standard and interoperates correctly with other BTL-listed devices. The BTL listing is administered by BACnet International and is the closest thing the industry has to a guarantee of interoperability.
BS EN 61158 covers fieldbus communication standards and includes Modbus within its scope. However, the practical Modbus specification is the one published by the Modbus Organization — it is freely available, widely implemented, and does not require any certification for compliance. This is both a strength (low barrier to implementation, universal availability) and a weakness (no independent verification of compliance, no guarantee of interoperability between implementations). Two 'Modbus' devices from different manufacturers may use different register structures, different data types, different byte ordering, and different exception handling — all of which are compliant with the specification but incompatible with each other without custom configuration.
For UK BMS specifications, CIBSE Guide H recommends BACnet as the primary communication protocol for building control systems and provides guidance on specifying BACnet compliance at each network level. Guide H explicitly addresses the risk of partial BACnet compliance — where a manufacturer offers BACnet at the field level but uses a proprietary protocol on the trunk — and recommends that the specification require BACnet at all network levels, verified by BTL listing.
BACnet is the right choice for the BMS backbone: controller-to-controller communication, controller-to-supervisor communication, and any integration where long-term interoperability matters. Specifically, use BACnet/IP for the trunk network connecting BMS controllers across floors or buildings, BACnet MS/TP for the field bus connecting controllers to their local I/O modules and BACnet-native field devices, and BACnet for the supervisor connection so that the supervisory platform can discover and interact with devices natively.
For new BMS installations in the UK, BACnet/IP should be the default unless there is a specific reason to use something else. The infrastructure requirement is minimal — standard Ethernet cabling and switches, which most buildings already have — and the interoperability benefit is immediate and permanent. For more detail on what a full BMS installation involves, our post on BMS installation costs in the UK covers the scope from design through to commissioning.
Modbus is the right choice for integrating third-party equipment that does not support BACnet — and there is a lot of it. Energy meters, variable speed drives, heat pump controllers, generator controllers, UPS systems, lighting control panels, and standalone plant controllers frequently offer Modbus RTU or Modbus TCP as their only integration interface. In these cases, Modbus is not a compromise — it is the only option, and it works well for the purpose.
The integration architecture should use the BMS controller as the Modbus master, polling the third-party device for its data and making that data available to the rest of the BMS network via BACnet. This way, the Modbus integration is local to the controller that needs it, and the rest of the system benefits from BACnet's native interoperability. The BMS controller acts as a protocol bridge: Modbus on the field side, BACnet on the network side.
For heat pump integrations in particular — where the manufacturer's controller typically offers Modbus RTU and sometimes Modbus TCP — this pattern is standard practice. Our post on heat pump BMS integration covers the specific challenges and the controls approach in detail.
A well-specified BMS protocol architecture uses both BACnet and Modbus, each where it is strongest.
The BMS backbone — controller-to-controller and controller-to-supervisor — runs BACnet/IP over the building's Ethernet infrastructure. All BMS controllers are BTL-listed. The supervisor connects via native BACnet, not via a proprietary wrapper.
Third-party equipment — meters, VSDs, standalone plant controllers — is integrated via Modbus RTU or Modbus TCP at the field level. The Modbus register maps are documented, included in the O&M manual, and held by the building owner.
The BMS controllers act as protocol bridges, converting Modbus field data into BACnet objects that the rest of the network can access natively. A temperature reading from a Modbus heat pump controller appears on the BACnet network as a standard Analog Input object — readable by any BACnet client, trend-logged by the supervisor, available for alarm monitoring, indistinguishable from a native BACnet data point.
The specification requires BACnet at all network levels, references BS EN ISO 16484-5 for protocol compliance, and requires BTL listing on all BMS controllers. The specification also requires that all Modbus register maps are documented and handed over as part of the project deliverables. This is the approach Alpha Controls takes on every project — and it is the approach we recommend to every consultant writing a BMS specification for a UK commercial building.
If you are writing a BMS specification for a new building or a major refurbishment, specify BACnet/IP at all network levels now. Do not leave the protocol decision to the contractor — state it in the specification, reference the standard, and require BTL listing. This one paragraph in the spec will save the building owner thousands of pounds over the system lifetime.
If you have an existing BMS running entirely on Modbus and you are planning an upgrade, consider migrating the backbone to BACnet while retaining Modbus at the field level for third-party integrations. This is the migration path described in our post on BMS retrofit costs in the UK — a phased approach that improves interoperability without a full rip-and-replace.
If you are not sure what protocol your current BMS is using — and this is more common than you might think — Alpha Controls can carry out a network survey and provide a clear report on the protocol architecture, the interoperability status, and the recommended upgrade path. Get in touch or request a quote and we will assess your system.
BACnet and Modbus are not competitors — they are complementary tools that serve different purposes in a BMS architecture. BACnet is the backbone: the open, self-describing, interoperable protocol that connects BMS controllers and supervisors and gives building owners the freedom to choose any competent contractor. Modbus is the utility player: the simple, universal protocol that connects the third-party equipment that BACnet does not reach. Use both, use them in the right places, and specify them properly — and the building will have a controls network that is flexible, maintainable, and future-proof for the life of the installation.
Alpha Controls designs and installs BMS systems using BACnet/IP as the backbone protocol, with Modbus integration for third-party equipment where required. We also migrate existing Modbus-only and proprietary systems to open BACnet architectures. Contact us or request a quote to discuss your project.
For the BMS backbone — controller-to-controller and controller-to-supervisor communication — yes. BACnet was designed specifically for building automation, with a self-describing data model that enables native interoperability between manufacturers. Modbus is better suited for integrating third-party equipment at the field level. Most modern BMS installations use both.
Yes. The BMS controller acts as a protocol bridge: it communicates with Modbus devices on the field side and presents that data as BACnet objects on the network side. A Modbus energy meter reading appears on the BACnet network as a standard Analog Input object, readable by any BACnet client.
BTL (BACnet Testing Laboratories) listing verifies that a BACnet device conforms to BS EN ISO 16484-5 and interoperates correctly with other BTL-listed devices. It is the closest thing to a guarantee of interoperability. Always specify BTL-listed controllers in a BMS specification.
Commercial lock-in. A proprietary protocol means only the original manufacturer or their authorised partners can maintain, modify, or extend the system. This creates a captive market with no competitive alternative. Open protocols like BACnet eliminate this dependency.
Modbus devices are typically cheaper per unit — a Modbus energy meter costs less than a BACnet equivalent. But the total cost of ownership over the building lifecycle is higher for an all-Modbus system, because every integration, every contractor change, and every system modification is more complex without BACnet interoperability.
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
