Protocol integration
KNX Integration
How KNX group addresses, gateways and datapoint types are mapped into a building platform, tested and handed over without losing local control.
What KNX is and where it is used
KNX is an open building-control standard built around a twisted-pair bus, with extensions for IP, radio and powerline. It is common in Europe and widely used for lighting, shading, room control, HVAC actuators and presence detection. Devices are commissioned individually: each has an application programme, parameters and group addresses. The bus is decentralised, so a push-button can trigger a dimmer without a central controller. That local resilience is one reason KNX survives long after the original installer has left. It is a fieldbus first, not an IP system. The integration project should respect that: the bus keeps its local behaviour, and the platform adds supervision rather than dependence. Protocol reference: a line supports up to 64 bus devices and an area up to 15 lines, and the bus is powered separately from the devices' own supplies. Those limits decide where couplers, repeaters and spare capacity belong. A bus that is healthy at the field level can still be poorly documented, and documentation is what the next project inherits.
- Lighting, dimming and scene control
- Shading and façade automation
- Room control, HVAC actuators and presence
- Europe and projects with multi-vendor specifications
- Bus limits planned before integration
Integration routes and gateway selection
There are three common routes. A KNX interface or gateway connects the bus to the platform over IP and exposes group addresses as readable and writable points. A KNX IP router does the same at the network layer and can span lines. A native KNX port is possible where the controller supports it. The route decides capacity, latency and diagnostics. Ask how many group addresses the gateway can expose, whether it supports tunnelling or routing, how many concurrent connections it allows, and what happens when the bus or the IP network fails. For a large installation, segment the bus and place routers deliberately rather than extending one line. A gateway is infrastructure: give it a spare, a fixed address and a documented replacement procedure. Tunnelling is convenient for a single supervisor; routing is better when several clients need the bus at once. Record which lines sit behind which coupler; a fault on one line should not require opening the whole panel.
- KNX gateway or interface over IP
- KNX IP router for larger or segmented installations
- Native KNX port where available
- Capacity, latency and failover confirmed before design
From group address to platform point
A KNX point is not just an address. The mapping record should include the group address, the datapoint type, the unit, the scale, the read/write direction, the owning device and the function it serves. A one-bit object may be a status, a command or a scene trigger; the record must say which. Datapoint types carry the scaling: a one-byte value may be a percentage, a two-byte value may be a temperature in tenths of a degree. Read and write flags are not interchangeable, and a status address should be separate from a command address. Naming should follow a building standard rather than the installer's initials. The point schedule is the contract between the KNX programmer and the platform engineer. Test a sample of each datapoint type rather than assuming that one working example covers the rest. Where a group address is written by two systems, the project needs an arbitration rule and a single owner. A group address used for both command and status is a common cause of oscillation.
- Group address and datapoint type
- Read/write direction and ownership
- Unit, scaling and engineering range
- Naming convention and arbitration rule
Point naming and the mapping register
Point naming should be readable at 03:00. Use a fixed structure: building, floor, room or system, device, function and signal type. Keep the KNX group address in the record, not necessarily in the visible name; the operator needs the function, the engineer needs the address. The mapping register should be exportable, because it will be compared with the ETS project, the gateway export and the platform database. Every point should show its datapoint type, unit, scale, direction, alarm limit and owner. Where a point is calculated or combined, record the inputs. A naming convention is only useful if it is enforced; add a review step before the point schedule is frozen. Avoid names that encode a temporary condition, such as a floor that will be renamed or a tenant that will move. Avoid abbreviations that only one installer understands. The register should also note the ETS device address, so that a bus trace can be matched to a device.
- Fixed structure readable without the drawing
- Group address in the record, function in the name
- Exportable mapping register
- Review before the point schedule is frozen
Testing and commissioning
Test the bus first, then the gateway, then the platform. On the bus, confirm device power, line couplers, group-address communication and scene recall. On the gateway, confirm discovery, address export, read and write behaviour, and reconnection after a network interruption. On the platform, confirm that each mapped point shows the right value, unit and state, and that a command reaches the field device. Test the failure path: disconnect the gateway and check that local KNX functions continue. Record the result against the point schedule, not in a separate notebook. A point that appears in a browse tree is not commissioned until it has been read, written and observed. Include a bus-load check: heavy polling can make a healthy installation look unreliable. Include a gateway restart and a platform restart; recovery behaviour is part of the function. Test the bus with the platform disconnected, then with it connected; both states matter.
- Bus health, couplers and group-address traffic
- Gateway discovery, read/write and reconnect
- Platform value, unit and state per point
- Local operation with the gateway offline
- Restart and recovery tests
Limitations, handover and responsibilities
KNX is robust at the field level, but it has limits. Bus bandwidth is shared, so heavy polling is a poor design. Group-address chaos is common in older installations and must be cleaned before integration. Some devices expose only limited objects, and some manufacturers use their own extensions. KNX Secure requires key management that the platform must support. The practical rule is simple: keep field control in the field, keep cross-system logic in the platform, and document the boundary. Integration should make the bus more legible, not hide it. The handover pack should include the ETS project or an address export, the mapping register, the gateway configuration and the test records. Responsibility for the bus stays with the KNX installer; responsibility for the mapping sits with the integrator. Write that split into the contract, especially for changes after handover. A future fit-out will add devices; leave address ranges and gateway capacity for it. A small spare stock of couplers, power supplies and bus terminals saves a return visit.
- Avoid polling where event-driven communication works
- Clean and document legacy group addresses
- Confirm secure KNX support before design
- Keep local control independent of the platform
- Leave address and gateway headroom
KNX integration planning
14 rows| Item | What to confirm | Why it matters |
|---|---|---|
| Bus media | Twisted pair, IP, radio or mixed | Determines gateway and topology |
| Line and area structure | Couplers, power supplies, spare capacity | Prevents overload and simplifies diagnosis |
| Device limits | Protocol reference: 64 devices per line, 15 lines per area | Sets where couplers and repeaters belong |
| Group address scheme | Naming, ranges, ownership | Makes mapping and future changes possible |
| Datapoint types | Type, unit, scaling | Prevents wrong values and commands |
| Read/write flags | Command and status separation | Avoids feedback loops and conflicting writes |
| Gateway capacity | Address count, tunnelling or routing, clients | Sets the integration limit |
| Read/write rights | Who may write each address | Avoids conflicting commands |
| Scenes and schedules | Where they live and who owns them | Prevents duplicate logic |
| Secure KNX | Key management and device support | Affects commissioning and platform choice |
| Diagnostics | Bus monitor, gateway logs, platform events | Shortens fault finding |
| Bus load | Polling rate and event traffic | Keeps response predictable |
| Test records | Address, datapoint type and observed result | Proves each mapped point |
| Handover | ETS project, address export, point schedule | Keeps the system maintainable |
Project images
3 images
Frequently asked
01Can you integrate an existing KNX installation?
Usually yes, if the bus is healthy and the group addresses can be read. The audit should confirm device power, couplers, ETS project availability and whether the addresses are documented.
02Do we need the original ETS project?
It helps. Without it, device parameters and group addresses may still be readable, but changes become risky. A missing ETS project is a finding to resolve before integration, not a detail to discover at commissioning.
03Can Loxone and KNX share control?
Yes. The project defines which system owns each group address and how conflicts are resolved. A common split is KNX for field devices, Loxone for cross-system logic and operator views.
04Does KNX integration require a gateway?
It requires an interface between the KNX bus and the platform. That may be a gateway, an IP router or a native KNX port, depending on the controller and the installation.
05How many group addresses can be integrated?
It depends on the gateway and the controller, not on a fixed platform limit. The design should confirm the address count, the update rate and the diagnostics before the point schedule is frozen.
06Can we keep KNX scenes?
Yes. Scenes can stay in the KNX devices or move to the platform, but not both without a clear owner. Duplicate scene logic is a common source of inconsistent behaviour.
07What happens if the platform goes offline?
KNX devices should continue their local functions: push-buttons, dimmers, shutter actuators and room controls. Cross-system logic stops until the platform returns. That failure mode should be tested and explained to the operator.
08Is KNX suitable for hotels?
KNX is common in hotel room specifications, especially in Europe. It works well for lighting, shading and room control; PMS and energy logic usually sit above it.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.