What is the difference between BACnet, KNX, Modbus and MQTT?

They solve different problems, and in most buildings they sit side by side. BACnet is a data communication protocol designed specifically for building automation and control. KNX is a standard for home and building control, widely used for lighting, shading and room control. Modbus is a simple, long-established client/server protocol for reading and writing values in devices such as meters, drives and plant controllers. MQTT is a lightweight publish/subscribe messaging transport that moves data between devices, gateways and software platforms.

Asking which is best misses the point. Each has a natural place, and the real design work lies in deciding which interface each system should use and in specifying what the data means once it arrives.

The four at a glance

BACnet

BACnet, maintained by ASHRAE's committee SSPC 135, was designed for the communication needs of building automation and control: HVAC, lighting, access control, fire and life-safety interfaces, energy management and lift monitoring. It defines messages for analogue and binary values, schedules, alarms and events, trend logs and network configuration. The current edition is ANSI/ASHRAE 135-2024, published at the end of 2024 and incorporating addenda to the 2020 edition. The same protocol is published internationally as ISO 16484-5, whose eighth edition appeared in August 2026.

BACnet's strength is that it carries structure: an analogue input object has a present value, units, status flags and other standard properties. Its weakness in practice is that products implement different subsets, so two devices that both say "BACnet" may not support the same services. BTL certification by BACnet International shows that a product has been independently tested against the standard test package. That is useful evidence, but the project still has to confirm that the specific objects and services its use case needs are supported.

KNX

KNX is managed by the KNX Association and is published as an international standard (ISO/IEC 14543-3) and as European standards (EN 50090 and EN 13321). It supports several media, including twisted pair, powerline, radio and IP, and devices from many manufacturers are configured with a common engineering tool, ETS. KNX is particularly common in European lighting, shading and room-control installations, and its core functions run locally without dependence on a cloud service.

When it comes to integration, KNX systems are often connected to a BMS or platform through a gateway or KNX IP interface. ASHRAE added a normative annex mapping KNX to BACnet objects to Standard 135 in 2004, but the integrator still needs the project's group-address and datapoint documentation.

Modbus

Modbus is an application-layer client/server protocol, maintained by the Modbus Organization, and one of the simplest ways to read data from equipment. It runs over serial lines and over TCP/IP, where port 502 is reserved for it, and a newer Modbus Security protocol wraps it in TLS. A client reads or writes numbered registers and coils in a server device.

That simplicity is also its limitation. A register holds a number, and what the number means (energy in kWh or Wh, a scaling factor, which phase) is defined only in the manufacturer's register map. Every Modbus integration therefore depends on the correct map for the exact device model and firmware, and on testing against known values.

MQTT

MQTT is a lightweight publish/subscribe transport standardised by OASIS; version 5.0 was approved in 2019. Devices or gateways publish messages to topics on a broker, and applications subscribe to the topics they need. It is efficient over constrained links, decouples producers from consumers and is widely supported by IoT and cloud platforms. It offers three delivery levels: at most once, at least once and exactly once.

What MQTT does not carry is any building meaning of its own. Topic structure, payload format, units, timestamps, asset identifiers and quality flags all have to be designed and documented by the project. Two MQTT systems can exchange messages flawlessly and still not understand each other.

A working connection is not yet integration

Whatever the protocol, an application needs to know what each value is, where it comes from, its unit and scaling, when it was measured and whether it is trustworthy. Without that, an apparently successful connection can produce misleading results. A semantic model and a naming convention are what make multi-protocol data usable.

Commands need even more care. Reading a temperature and changing a setpoint are different acceptance cases, and the specification should say which commands may cross a system boundary, at what priority, how overrides work and what happens if communication is lost.

Gateways that translate between protocols are often necessary, but each one is another device to configure, secure, back up and support. Every gateway belongs in the interface schedule, with a named owner.

Writing the interface schedule

For each interface, the schedule should state the protocol and version, the devices and points involved, their meaning and units, update rates, permitted commands, the security mechanism, failure behaviour and the responsible party at each end. A representative exchange should then be demonstrated before full roll-out, as the meter fault above shows.