Building Automation System Integration — KNX, BACnet, Modbus & Loxone

KNX

KNX is a building-control standard for lighting, shading, room control and some HVAC terminals. Devices share a twisted-pair bus, with addresses organised into lines and areas. Configuration is held in the devices through an engineering tool, and a gateway can expose group addresses to an IP network or another platform. KNX is strong where room functions need a stable, vendor-independent bus. Integration work focuses on group address naming, data point types and the behaviour when a gateway or bus segment goes offline. A KNX installation that is well documented is easier to extend; one without group address naming becomes a black box. The gateway should be tested with the real bus load, not only with a bench device. Bus power, termination and the number of devices per line also matter, because a marginal KNX line produces faults that look like device failures.

• Twisted-pair device bus
• Group addresses by line and area
• Gateway to IP or another platform
• Test offline behaviour

BACnet

BACnet is the common language of plant and building management systems. It defines objects, properties and services, so a chiller or AHU can expose its status, setpoints and alarms in a structured way. BACnet/IP runs over Ethernet; MS/TP runs over a serial bus. Integration requires the device instance, object identifiers, units and read/write permissions. Change-of-value subscriptions reduce polling, but not every device implements them well. The point map should record which objects are read-only, which are commandable and what happens when communication is lost. The object list should be exported and reviewed before graphics are built, not discovered during commissioning. Read-only status points and commandable setpoints should be separated in the graphics and the permissions. BACnet device instance numbers must be unique across the internetwork, and BBMD or router configuration must be documented when traffic crosses subnets.

• Objects, properties and services
• BACnet/IP over Ethernet
• MS/TP over serial bus
• Read/write rights and fallback

Modbus

Modbus is simple, widespread and unforgiving. It exposes registers and coils, and the integrator must know the register map, the data type, the scaling and the byte order. Modbus RTU runs over RS485; Modbus TCP runs over Ethernet. Meters, inverters, power supplies, sensors and many PLCs use it. Because Modbus has no standard object model, two devices from different vendors can use the same register number for different meanings. The register map and the engineering units belong in the integration document, not in someone's memory. A single wrong scaling factor can make an energy report plausible but false, which is worse than an obvious failure. Polling too aggressively can saturate a serial bus and cause timeouts that look like device faults. Serial segments also need correct termination, bias and isolation, and a device count that the bus can actually support.

• Registers, coils and function codes
• RTU over RS485, TCP over Ethernet
• Scaling and byte order
• Documented register map

DALI and the Loxone buses

DALI controls addressable luminaires, with individual addressing, groups, scenes and fault feedback. It is a lighting bus, not a general building bus, and it needs a gateway or controller to join the wider system. Loxone uses Tree for wired devices, Air for wireless devices and 1-Wire for simple sensors. Tree and Air carry both power and data for compatible devices; 1-Wire is a low-speed sensor bus. The choice between them follows the construction method, the device type and the need to keep the bus topology simple. DALI and Loxone buses should be kept within their intended segment sizes and power limits, with the design showing where each segment starts and ends. The choice should be recorded in the design, including the reason, so a later change does not casually mix bus types. A DALI emergency-lighting test schedule also needs to be documented, because it is a life-safety routine, not a scene.

• DALI addressing, groups and scenes
• Tree for wired Loxone devices
• Air for wireless devices
• 1-Wire for simple sensors

Gateways, point mapping and testing

Gateway selection is a design decision. The gateway must support the required protocol version, the number of points, the polling rate and the direction of data. Point mapping then assigns every data item a name, address, type, unit and permission. Naming should match the drawings and the operator graphics. Testing starts in the factory with a point-to-point check, continues on site with live devices, and ends with interlock and failure tests. The handover pack should include the address list, gateway configuration, test records and a clear statement of what is read-only. The integration document should be a living record: when a device is replaced, its address and point mapping are updated in the same place. Test records should name the device, firmware, point and expected value, not only pass or fail. A gateway that is not documented is a future outage with an unknown cause.

• Protocol version and point count
• Name, address, type and unit
• Factory and site testing
• Address list and test records

Network design, addressing and time synchronisation

Integration succeeds or fails at the network layer. Start with an addressing plan: IP ranges per system, VLANs for building services, and a rule for which devices are routed and which are isolated. BACnet/IP needs attention to broadcast domains, device instance numbers and BBMD configuration when traffic crosses subnets. Modbus TCP needs stable addressing and a polling plan; serial Modbus needs correct termination, bias and isolation, plus a limit on devices per segment. Gateways should sit close to the equipment they serve and be powered from a circuit that is not switched off for maintenance. Time synchronisation should come from one source, with all controllers and gateways using the same NTP service; otherwise trend timestamps and alarm sequences cannot be correlated. Network documentation should be part of the handover, not a diagram drawn after the first fault.

• IP and VLAN addressing plan
• Broadcast domains and BBMD
• Serial termination and isolation
• One NTP source for all devices

Testing, documentation and common failure modes

Testing should follow the integration matrix rather than the integrator's confidence. Factory testing checks gateway configuration, point names and read/write rights against a bench device. Site testing repeats the checks against live equipment and adds communication-failure tests: disconnect a gateway, remove a bus segment, corrupt a register, restart a controller. Alarms and interlocks are then tested end to end, including the operator acknowledgement and audit trail. Documentation should include the address list, point map, gateway settings, network diagram, test records and a statement of read-only points. Common failures are predictable: a duplicate BACnet device instance, wrong Modbus byte order, a gateway that polls faster than the device can answer, an unsupported BACnet service, a KNX group address with the wrong data point type, and a firmware mismatch between gateway and device. Each has a test that would have found it.

• Bench and site point checks
• Communication-failure tests
• End-to-end alarm and interlock tests
• Address list, point map and firmware record

Access control integration

Access control integration connects door events, reader decisions and alarm states to the building platform without becoming the access-control supplier. The access controller remains the authority for credential validation and door release; the platform subscribes to events, applies cross-system logic and presents a single timeline. Typical links are door-held, forced-open, valid-entry and duress events, plus video and lighting responses. The scope should state which system owns the door, which owns the event log, and what happens when either side is offline.