BACnet, KNX or Modbus: choosing a protocol you won’t regret in ten years

This question arrives on almost every project, usually phrased as a choice between three options. It is the wrong shape. Nearly every non-trivial building ends up running at least two of these, and the design decision that actually matters is where the boundaries between them sit and who owns the translation.

Still, you cannot make that decision without knowing what each protocol is genuinely good at.

The three, briefly and honestly

BACnet

An open building automation protocol, standardised as ASHRAE 135 and internationally as ISO 16484-5. Its distinguishing feature is that it is object-oriented and semantic: a point is not just a number at an address, it is an object with a type, units, a present value, priority arrays, alarm and trend properties. Two devices from different manufacturers can therefore have a meaningful conversation about what a value means.

It runs over IP (BACnet/IP) and over RS-485 (BACnet MS/TP). It is the natural fit at plant and supervisory level: air handling units, chillers, boilers, and the head-end that watches them. It is comparatively heavyweight for switching a light.

KNX

A decentralised field-level bus, standardised as EN 50090 and ISO/IEC 14543-3, with very strong penetration in European room automation. Its distinguishing feature is certified interworking: devices are tested against a common model, configured in a single tool, and there is no central controller that has to survive for the room to keep working.

That decentralisation is the real argument for it. Lighting, shading and room terminal control keep functioning when the supervisory layer is down or being replaced. It is excellent at the room, and not what you want to run a chiller sequence on.

Modbus

Not really a peer of the other two, and it is clearer to stop treating it as one. Modbus is a simple, ancient, register-based protocol — RTU over serial, TCP over Ethernet — with no semantic layer at all. You read a number from an address. What that number means lives in a PDF from the manufacturer, and possibly in a scaling factor buried in a footnote.

That sounds like a criticism. It is not, quite. Modbus is how the world's meters, variable-speed drives, inverters, chillers and packaged plant will talk to you, whether or not you chose it. It is the universal solvent of building integration, and its simplicity is why it is still everywhere.

The architecture that usually falls out

For a typical mid-to-large commercial building, the shape that most often survives contact with reality is:

• KNX at room level — lighting, shading, presence, room terminal units, local setpoint adjustment.
• BACnet at plant and supervisory level — AHUs, generation, distribution, the head-end, trending and alarms.
• Modbus at device level — meters, drives, packaged equipment, anything that came with an integration document rather than a profile.
• Defined gateways at each boundary, with an explicit, documented list of what crosses.

That last bullet is where projects are won or lost.

The gateway problem

Every gateway is three liabilities at once: a translation that can be wrong, a device that can fail, and a commercial dependency that can be licensed, discontinued or held hostage at renewal. A building that accumulated its gateways one integration at a time, with no governing architecture, ends up with a control system nobody can fully describe — which means nobody can safely change it.

Two rules keep this manageable:

1. Specify what crosses the boundary, not just that a boundary exists. A points list stating exactly which values pass between KNX and BACnet, in which direction, at what update rate, with what failure behaviour. If it is not on the list, it does not cross.
2. Keep the count deliberate. Each additional gateway needs a reason that survives being said out loud. "The subcontractor's kit only speaks their own protocol" is not a reason; it is a procurement decision being made by default.

The criteria that actually decide it

Protocol comparison tables tend to focus on technical capability, which is rarely the binding constraint. In practice the decisions that matter over a building's life are commercial and organisational:

• Can you re-tender the maintenance? If exactly one integrator can access the configuration, you have bought a subscription, not a system. This is the single most expensive mistake in this field.
• Who holds the configuration files, and are they in the handover? Name them in the specification. Take delivery of them. Test that they open.
• What is the local integrator market? A protocol with three capable firms within an hour's drive beats a technically superior one with none.
• What happens when the supervisory layer is off? Decide deliberately which functions must survive, and push those down to a layer that keeps running.
• Can the points be read by something you write yourself? If you ever want analytics, fault detection or your own dashboard, open read access is what makes it possible.

So what do we specify?

Open protocols at every layer, boundaries drawn on purpose, a documented points list across each boundary, and configuration files named as a contract deliverable. Then we let more than one integrator bid it.

The goal is not protocol purity. It is that in ten years, when the head-end is replaced and the original integrator has been acquired, someone can still open the system, understand what it does, and change it — without a rescue project.