Integrating KNX with AV, security, and lighting: how the layers connect

On a complex building, KNX is the coordination layer. Lighting runs on DALI drivers, or KNX-native, or DMX. AV runs on HDMI over IP, Dante, and control protocols specific to the AV manufacturer. Security runs on the intrusion panel, the access control platform, and the CCTV system. HVAC runs on BMS BACnet or Modbus. Each has its own specialist. Each has its own protocol. The KNX integrator’s job is defining how they behave together.

This post covers what sits on the KNX bus directly, what integrates via gateways, and where design decisions between trades get made. It is written for M&E consultants and design team professionals coordinating a KNX-led automation scope.

What lives on the KNX bus

The KNX bus itself carries the automation backbone. Devices designed for direct KNX operation include:

• Switches, keypads, and control plates
• Presence and daylight sensors
• Dimmers, contactors, and universal actuators
• Thermostats and room controllers
• Some blind and shutter motors (KNX-direct or with KNX interface)
• Some HVAC valves, dampers, and fan controllers
• Bus couplers, power supplies, and IP interfaces

These are the components the integrator specifies and programmes directly.

Everything else in the building interfaces with KNX through gateways, IP interfaces, or protocol converters.

Lighting: KNX, DALI, and DMX

Lighting on a well-designed building rarely runs on one protocol. The KNX integrator coordinates across three:

DALI (Digital Addressable Lighting Interface) is the dominant protocol for architectural lighting drivers. LED drivers, fluorescent ballasts (still specified in some retrofits), and emergency lighting all commonly run on DALI. KNX-DALI gateways bridge KNX-level scene commands into DALI-level driver control. The lighting designer specifies DALI drivers; the KNX integrator specifies the gateway and the scene layer.

KNX-native lighting covers dimmers and contactors on the KNX bus, typically for high-current circuits (heating panels, exterior floods) or where a DALI infrastructure would be over-engineered.

DMX is used for feature and architectural show lighting, particularly RGBW cove and accent lighting. KNX-DMX gateways bridge the two protocols. On projects with significant DMX scope (some hospitality, some super-prime residential), the lighting designer may specify a dedicated lighting control platform (Pharos, ETC), with KNX carrying room-level scene calls into it.

The design decision at Stage 3 is which protocol carries which circuit. The integration matrix documents the boundary.

AV integration

Audio-visual runs on its own protocol stack. Signal distribution uses HDMI over IP, SDI, or AVB. Audio distribution uses Dante or Q-SYS. Control uses Crestron, Extron, or the AV specialist’s chosen platform.

KNX does not carry AV signal. It carries room-level control decisions:

• Which source is playing in which room
• What volume level applies to which zone
• Which lighting scene should be set for which AV state
• Which blinds should close when a cinema mode is called

The KNX integrator specifies the interface between KNX and the AV control system, typically an IP or serial link where the AV control platform exposes an API. The AV specialist owns the AV design, the racks, the wiring, and the programming of the AV control platform. The KNX integrator owns the room-level control decisions and the coordination with lighting and blinds.

For projects where AV is the largest scope (corporate boardrooms, high-end cinemas, broadcast), the AV control platform sits as an equal peer to KNX. That decision is made at the design team stage.

Security integration

Security is three layers: intrusion, access control, and CCTV.

Intrusion panels expose arming, disarming, and zone-status data through IP or dry-contact interfaces. KNX integrates via a gateway, so that arming an alarm can also switch off lighting, close blinds, and set climate to away mode. Disarming reverses the response.

Access control systems (Paxton, HID, Salto, Genea) expose door state and user credentials through the manufacturer’s API or standard protocols. KNX integrates via gateway or IP interface, so that a valid credential at the door can release the door, log the entry, cue lighting for the resident’s path, and adjust climate in the apartment being entered.

CCTV runs on the video management system (Milestone, Genetec, and others). Video stays on the VMS. KNX can trigger CCTV events (start recording, jump to a preset) via the VMS API.

Security policy is set by the security consultant. The KNX integrator implements the automation response that the policy calls for.

HVAC and BMS

Most complex buildings run a BMS on BACnet, and increasingly Modbus for smaller plant. KNX interfaces with the BMS via a BACnet or Modbus gateway, sharing:

• Setpoint changes from KNX room controllers to the BMS
• Occupancy state from KNX presence detection to the BMS
• Plant status from the BMS back to KNX for user-facing displays
• Energy data in both directions

Where the building has no BMS (many later living schemes, most residential), KNX takes on the HVAC control directly, with the M&E consultant’s zoning and control strategy documented in the KNX programming.

The design decision at Stage 3 is where the boundary sits between KNX and the BMS. On a well-scoped project, that boundary is documented in the integration matrix and agreed by both the KNX integrator and the BMS specialist.

Telecare, booking, and specialist systems

Some sectors have specialist systems that KNX integrates with:

• Telecare and nurse call in later living and care schemes. KNX integrates with platforms like Tunstall, Chubb, or Legrand to trigger lighting, door, and access responses to alarms.
• Court booking in padel and other operator-led sports. KNX integrates with Playtomic, Matchi, or the operator’s platform to drive lighting, climate, and access sequences.
• Specialist plant including pool, spa, wine, and cellar systems. Most expose Modbus, BACnet, or a simple contact interface for KNX.

Each integration is defined at design stage, documented in the integration matrix, and programmed once at implementation.

Where design decisions get made

The integration matrix is the design team document that captures every interface between KNX and every other system on the project. For each interface, it records:

• The two systems being connected
• The direction of data flow (one-way, two-way)
• The protocol and gateway used
• The owning discipline for each side
• The commissioning responsibility

The matrix is issued through the M&E consultant at Stage 3 and updated through Stage 4 as the design firms up. It is the primary reference at commissioning.

Without it, integrations happen ad-hoc on site, in the last two weeks of the programme, at costs that were not budgeted.

The integrator’s role in the joins between trades

Every integration boundary in the list above is a potential source of trade-interface disputes on site: whose responsibility, whose cost, whose warranty. On a project with a KNX integrator inside the design team, those disputes are resolved on paper at Stage 3 and Stage 4, before they reach site.

The coordination between trades is the core deliverable of an integrator-led engagement.

Specifying KNX integration at design stage

For an M&E consultant coordinating the automation scope, the practical points:

• KNX integrator appointed at RIBA Stage 2, in the design team
• Integration matrix issued at Stage 3, updated at Stage 4
• Boundary decisions documented for each interface (lighting, AV, security, HVAC, telecare, specialist plant)
• Commissioning responsibility agreed by discipline, in writing, at Stage 4
• Aftercare responsibility for each integrated interface named in the maintenance package

A project scoped this way delivers a KNX system that carries the coordination the M&E consultant needs, with each specialist trade delivering their scope inside a documented framework.