TL;DR:

  • KNX and BACnet are the two dominant open standards for building automation — KNX is strongest in European lighting and building control, BACnet is the dominant protocol for large HVAC and mechanical systems, particularly in North America.
  • Both protocols now have well-established integration paths to modern IoT stacks via gateways that bridge to MQTT, OPC UA, or cloud APIs — you don’t need to replace existing infrastructure to connect it.
  • For new builds, the choice between them usually comes down to geography and system scope; for retrofits, the existing protocol on the installed equipment is typically the deciding factor.

Why These Two Protocols Dominate

Building automation has always been fragmented. For decades, individual vendors — Siemens, Honeywell, Johnson Controls, ABB — ran proprietary control systems that couldn’t talk to each other. The two open standards that emerged to fix this took different routes and ended up dominating different market segments.

KNX grew out of the European EIBA standard in the 1990s, absorbing the competing EIB, BatiBUS, and EHS standards to become the single European open standard for home and building control. It’s maintained by the KNX Association and is ratified as ISO/IEC 14543. BACnet — Building Automation and Control Networks — was developed by ASHRAE (the American Society of Heating, Refrigerating and Air-Conditioning Engineers) and published as ASHRAE 135, later becoming ISO 16484-5. It was designed explicitly for HVAC control at scale: the kind of chiller plant, air handling units, and variable air volume boxes found in large commercial buildings.

Understanding the origins helps explain the architecture of each. KNX was built for electricians installing distributed control in buildings — lighting, blinds, HVAC terminals, occupancy sensing — at a relatively granular level. BACnet was built for mechanical engineers and building management system (BMS) integrators working with large plant equipment that already had its own controllers.

How KNX Works

KNX uses a twisted-pair bus (TP) as its primary physical medium, though IP, powerline, and RF variants exist. Devices on the bus — sensors, actuators, controllers — communicate by sending telegrams addressed to group addresses rather than individual device addresses. A motion sensor, a light switch, and a DALI gateway can all share the same group address so that a single occupancy event triggers lighting, adjusts heating setpoints, and logs to a BMS simultaneously.

The programming tool is ETS (Engineering Tool Software), now at ETS 6. Everything on a KNX installation is configured through ETS: group address assignment, device parameterisation, commissioning, and diagnostics. There’s no getting around it — KNX without ETS is like configuring a Cisco network without IOS access. ETS 6 has improved significantly over earlier versions, with better import/export, cleaner product database integration, and improved diagnostics, but it still has a learning curve for engineers coming from IP networking backgrounds.

KNX installations are common across European commercial buildings for: lighting control (on/off, dimming, scene recall), blind and shutter control, room temperature control at the thermostat/actuator level, energy metering, and access control interfaces. It’s less common as the protocol for large mechanical plant — you won’t typically find a chiller or an air handling unit unit controller running native KNX.

How BACnet Works

BACnet’s architecture is object-oriented. Every piece of data — a temperature sensor reading, a fan speed command, an alarm state — is represented as a named object with defined properties. An Analog Input object has properties like Present_Value, Units, and Description. Controllers expose these objects over the network, and other controllers or supervisory systems can read or write them using standardised services.

BACnet runs over two main physical layers in practice:

  • BACnet/IP — BACnet datagrams carried over standard Ethernet/IP networks. This is how most modern BACnet devices communicate at the supervisory level and increasingly at the field level too. It supports broadcast-based device discovery (Who-Is / I-Am) and can traverse routers with a BACnet Broadcast Management Device (BBMD).
  • BACnet MS/TP — Master-Slave/Token-Passing, running over RS-485 serial links. This is still widely used at the field level for HVAC equipment: zone controllers, VAV boxes, fan coil units. MS/TP is cheap, robust, and tolerates the noisy electrical environment near mechanical plant. It’s also limited in speed (typically 76.8 kbps) and requires careful bus termination and careful attention to the master-slave addressing.

Most large commercial HVAC installations use a mix: MS/TP at the field device level, with IP-connected supervisory controllers aggregating data upward. Wireshark handles BACnet/IP packet inspection natively, which makes debugging supervisory-layer issues straightforward. MS/TP debugging requires a physical tap or a serial analyser.

Key Differences in Practice

The clearest practical distinction is scope and geography. KNX is the default choice for building control (lighting, blinds, room-level HVAC terminals) in Europe; BACnet is the default choice for large mechanical plant (chillers, AHUs, boilers, lift groups) everywhere, but especially in the US and in large commercial projects globally. Many buildings have both — KNX handling room-level control and BACnet connecting the plant room to the BMS.

BACnet’s object model makes it easier to represent complex mechanical systems with multiple sensors, setpoints, and control loops in a standardised way. A KNX group address model is simpler and more appropriate for the kind of event-driven logic (press switch, trigger lighting scene) that dominates room-level control. Neither is inherently better — they’re genuinely well-suited to different layers of the building automation stack.

Vendor support also differs. European lighting control and room automation vendors (Gira, MDT, Theben, Elsner) produce KNX devices as a matter of course. HVAC equipment manufacturers (Daikin, Carrier, Trane, Belimo) typically implement BACnet on their controllers. Specifying the right protocol means specifying it at the equipment selection stage, not as an afterthought.

IoT Integration: Getting Data Out

Both protocols predate modern IoT architecture. Neither has native MQTT support, neither publishes to a message broker, and neither integrates with cloud time-series databases without an intermediary. That intermediary is typically a gateway — a piece of hardware or software that speaks the building automation protocol on one side and a modern IoT protocol on the other.

For KNX, the standard integration path is a KNX IP router or KNX IoT gateway. The KNX IoT initiative (KNX Association’s standardised extension, based on CoAP and the KNX data model) provides native IP integration for new installations. For existing TP installations, products like the Weinzierl KNX IP Interface or the MDT IP Router bridge to Ethernet, and software like knxd (the open-source KNX daemon for Linux) can then expose KNX group addresses to application code on an edge server. From there, a Node-RED flow or a small Python script can publish KNX state changes to an MQTT broker within seconds of setup.

For BACnet, the integration landscape is more mature, partly because BACnet/IP already runs over Ethernet. A BACnet/IP device is directly addressable from an edge server running a BACnet stack. Open-source libraries — bacpypes for Python, the node-bacnet library for Node.js — allow direct polling or COV (Change of Value) subscription from application code. The Node-RED BACnet node provides a low-code integration path suitable for facilities teams who need data flows without deep programming. For MS/TP field devices, a BACnet MS/TP to IP router is the first step; these are commodity hardware items from vendors like Contemporary Controls (the BASRT-B is widely used).

Edge Integration Patterns

Beyond simple MQTT bridging, there are several established patterns for integrating KNX and BACnet into edge computing architectures.

OPC UA wrapping BACnet is common in industrial IoT contexts where the data consumer expects OPC UA rather than BACnet objects. Software like Ignition (Inductive Automation) or dedicated BACnet-to-OPC UA servers can expose BACnet objects as OPC UA nodes, making building data consumable by SCADA systems and industrial analytics platforms without any BACnet-specific client code.

Niagara Framework (Tridium) is the dominant middleware platform in commercial building integration. Niagara controllers (Jace or Supervisor) speak both KNX (via drivers) and BACnet natively, normalise device data into the Niagara object model, and expose it upstream via REST, MQTT, or OPC UA. It’s proprietary and requires Tridium-certified integrators, but it’s the most widely deployed integration platform in commercial buildings and has extensive driver libraries for both protocols. If the building already has Niagara infrastructure, it’s almost always the path of least resistance.

SkySpark from SkyFoundry is a popular analytics layer that sits above BMS middleware. It ingests data from Niagara, BACnet, and other sources, applies rule-based analytics (written in the Axon functional language), and generates fault detection and energy analysis reports. It doesn’t replace the integration layer but is worth mentioning as the most widely used purpose-built analytics platform for commercial building data.

Open-source edge stacks — typically a Linux edge server running knxd or a BACnet stack, publishing to Mosquitto (MQTT broker), ingested by InfluxDB, and visualised in Grafana — are increasingly viable for organisations with in-house engineering capability. This pattern avoids vendor lock-in and works well for monitoring use cases. For control (writing setpoints, commanding actuators) the open-source path requires more careful design around safety, authorisation, and failover.

Choosing Between Them: New Builds vs Retrofit

For new builds, the decision should be driven by the dominant system type and geography. European projects with significant lighting control and room-level automation should default to KNX for those layers; any large HVAC plant should specify BACnet on the controller. Specify KNX IP or BACnet/IP wherever possible to simplify future integration.

For retrofits, the protocol question is usually already answered by the installed equipment. The practical challenge is getting data out of a system that was never designed for external integration. Start by auditing what’s installed, what protocol it speaks, and whether IP connectivity exists. MS/TP-only BACnet installations and older KNX TP-only installations with no IP router both require additional hardware before software integration is possible — budget for that hardware and the physical access to install it.

In either case, define the integration requirements — what data points, at what polling frequency, going where — before selecting gateway hardware. The building automation world has a long history of integrations that were architected around the available hardware rather than the actual data requirement, and it shows in the results.