The scenario comes up more often than you'd think. A building owner inherits a site where the HVAC is Siemens, the energy meters are from a third-party manufacturer, and the front-end BMS is a Trend system that was installed five years ago. None of them can see each other without proprietary gateways — each one costing £800 to £2,000 and introducing another layer of maintenance complexity. The FM team is flying blind, managing energy through gut feel rather than real data, and every time they want to add a new piece of kit the conversation starts with "can your system talk to ours?"
This is the problem BACnet was designed to solve. And if you're specifying, commissioning, or managing commercial building controls in 2025, understanding how it works — and where it goes wrong — is as important as knowing your plant.
BACnet — Building Automation and Control Network — is an open communication protocol that defines how building services devices exchange data. It was developed by ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) and ratified as an international standard under ISO 16484-5. It's the dominant open protocol in commercial building controls globally, supported by every major manufacturer including Trend, Siemens, Distech, Automated Logic, and Johnson Controls.
The key word is open. Unlike proprietary protocols that lock you into a single vendor's ecosystem, BACnet allows any compliant device — regardless of who made it — to communicate with any other compliant device on the same network. A Trend IQ controller can read temperature data from a Siemens sensor, push setpoints to a third-party VAV actuator, and report alarms to a front-end from any manufacturer. No bespoke drivers, no vendor middleware, no integration surcharges every time you want to extend the system.
BACnet doesn't control plant directly — it's a communications layer. What it does is define the data model (how a temperature reading or fan status is represented), the addressing scheme (how devices find each other on the network), and the transport mechanism (how messages physically travel between devices). The controls logic lives in the controllers. BACnet makes sure they can all have the same conversation.
In practice, most commercial buildings use BACnet across two different physical layers, and understanding the distinction is important for both design and fault-finding.
BACnet/IP runs over standard Ethernet and Cat5e/Cat6 cabling — the same infrastructure as the building's IT network. It's the default choice for new-build commercial projects and larger retrofits where IP infrastructure already exists. There's no inherent distance limit beyond the network design itself, and it scales comfortably from a single floor to a multi-building campus. The main consideration is IT coordination: BACnet/IP devices need to sit on a dedicated VLAN, separate from corporate systems, and firewall rules need to be agreed before commissioning starts. Getting IT involved late is one of the most common causes of programme slippage on BMS projects.
BACnet MS/TP (Master-Slave/Token Passing) runs over RS-485 twisted pair cable — the traditional comms wiring that's been used in BMS field networks for decades. It's slower than IP (typically 76,800 baud on a Trend network), has a practical limit of around 1,200 metres per trunk, and supports up to 127 devices per segment. But it's reliable, it's cheap to install, and it works excellently for FCU networks, plant room trunks, and retrofit projects where running Cat6 to every controller isn't feasible. Most real buildings use both: BACnet/IP for the backbone and front-end communications, MS/TP for the field device network.
The commercial case for BACnet is largely about flexibility over the building's lifecycle. A building fitted with open-protocol controls in 2015 can, in 2025, add a new energy metering system, integrate a heat pump, connect an occupancy platform like LightFi, or swap its front-end BEMS — without replacing the entire controls network. The alternative — proprietary systems — tends to age badly. Once the original vendor raises gateway costs, withdraws support, or gets acquired, the building owner is stuck paying integration tax indefinitely or facing a full rip-and-replace.
From an energy and compliance perspective, BACnet also enables the sub-metering granularity that ESOS Phase 3 and MEES obligations are increasingly demanding. If your meters can't communicate with your BMS, you're manually reading figures and losing the ability to correlate energy consumption with occupancy, plant operation, or weather data. Open-protocol integration is what makes that correlation possible, and it's what gives the data meaning.
BACnet is mature and well-tested, but poor implementation causes real problems on site. The most common fault we encounter is duplicate Device Instance IDs — every device on a BACnet network needs a unique identifier, and when two controllers are commissioned with the same ID (usually because someone copied a configuration file without updating it), you get sporadic comms losses that are extremely difficult to diagnose without the right tools. We've traced this fault on sites where it had been logged as an "intermittent network fault" for over a year.
On MS/TP networks, wiring quality is the most frequent source of trouble. RS-485 is sensitive to cable impedance, termination, and shielding. A trunk without proper end-of-line resistors, or one where the shield hasn't been earthed correctly at a single point, will produce bus collisions and token-passing failures — devices dropping off the network for seconds at a time, alarms that can't be cleared, and setpoints that don't write reliably. The fault often doesn't show up during testing with a small device count but emerges once the trunk is fully populated. The spec is straightforward: 120Ω termination resistors at each end of the trunk, screen earthed at one end only, solid-core comms cable, no star topologies.
On BACnet/IP networks, the equivalent issue is VLAN routing and subnet configuration. BACnet uses UDP broadcasts for device discovery, and broadcasts don't cross router boundaries without a BACnet Broadcast Management Device (BBMD) or BACnet/IP Foreign Device Registration configured on each subnet. This is often overlooked during design, discovered during commissioning, and then rushed through in a way that either doesn't work properly or leaves the BMS network without adequate IT security boundaries.
BACnet is formally defined under ASHRAE Standard 135, which is revised periodically to add new data types, transport options, and security capabilities. The current version is also adopted as ISO 16484-5, making it a mandatory reference in many European public-sector and healthcare building specifications. When a contract document calls for "BACnet compliance," it should specify the profile level — BACnet defines conformance classes and application-specific profiles (B-AAC, B-SA, B-BC) that determine which features a device must support. A device claiming BACnet compatibility without a stated profile may not support the features you actually need.
Security is an area where the standard has evolved significantly. Traditional BACnet/IP has no authentication or encryption — any device on the network segment can read and write to any other device. This was acceptable when BMS networks were completely air-gapped, but as buildings connect to cloud platforms, remote access VPNs, and corporate IT networks, it's a meaningful risk. BACnet/SC (Secure Connect), introduced in ASHRAE Addendum bj to Standard 135, adds TLS encryption and certificate-based authentication to BACnet/IP. It's increasingly being specified on new commercial projects, particularly where the BMS shares infrastructure with IT systems or connects to cloud BEMS platforms. For existing networks, the practical security baseline is a dedicated VLAN with firewall rules preventing direct internet access, VPN for remote connections, and role-based access control on the front-end software.
On projects like Pinsent Masons — where we carried out a full 16-floor FCU upgrade using Trend controllers integrated with the existing BMS infrastructure — BACnet/IP provided the backbone that made the integration clean and commissioning straightforward. Each floor's Trend IQ controllers were addressed with unique device IDs before going on the network, labelled consistently, and commissioned against a point schedule that matched the front-end naming conventions. That discipline — which takes time upfront but eliminates the call-out cycle later — is what separates a network that runs quietly for ten years from one that generates fault calls every few weeks.
On retrofit projects in older buildings, MS/TP trunks are often the right answer for the field network even when BACnet/IP is used at the supervisory level. It's cheaper to cable, more tolerant of plant room conditions, and — when wired correctly — completely reliable for the device counts typically involved in an FCU or VAV rollout. Trunk design, baud rate, termination, and device addressing are all specified before cable goes in the tray, not figured out during commissioning.
If you're specifying a new BMS or planning a retrofit, BACnet/IP should be the default unless there's a specific reason otherwise. The total cost of proprietary integration — gateways, driver licences, consultant time, and the long-term cost of vendor dependency — consistently exceeds the marginal cost of proper open-protocol design from the start. On large estates and multi-tenanted commercial buildings, where the controls infrastructure will outlast any single contractor relationship, this matters even more.
If you're managing an existing building and finding that your systems can't talk to each other, it's worth getting a controls contractor to audit what protocols your devices actually support before assuming gateways are the only answer. Many devices that appear proprietary have BACnet or Modbus capability that simply hasn't been configured. We've integrated plant on sites where the building owner had been paying for proprietary middleware for years, when the underlying devices were perfectly capable of speaking BACnet natively.
BACnet has been the dominant open protocol in commercial building controls for a good reason — it solves a real problem that affects every building owner who has ever had to integrate equipment from different manufacturers. Done properly, it gives you a controls network that scales cleanly, supports future upgrades without vendor lock-in, and provides the data visibility that energy compliance increasingly demands. Done poorly, it produces intermittent faults and commissioning headaches that take experienced engineers to untangle.
If you're specifying, designing, or troubleshooting a BACnet network and want a second opinion, get in touch with the Alpha Controls team. We design and commission BACnet/IP and MS/TP networks across London and the South East, and we're happy to review existing network documentation or talk through a new project before you commit to a design.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
