KNX
KNX exchanges building control information through devices and group addresses. Document what each address means and which components may send or act on it.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Public KNX material was reviewed; complete quarterly specifications, ETS project data, device profiles, and certified product records are needed for implementation.
On this page
Overview#
KNX is a distributed building control system standardised through KNX specifications and international/regional standards. Two publication views must be kept distinct: the association's public V3 specification set was published in February 2025, while KNX Standard 3.0.4 was released on 22 August 2025 for member access and became the certification reference at the end of that month.12 Implementation and certification work must use the exact member document, amendment, certification date, and product record rather than treating the public V3 download as a complete quarterly baseline. Media include twisted pair, power line, RF, KNXnet/IP, and the KNX IoT family; supported media and profiles are product specific.
Addressing and meaning#
An individual address locates a device in the KNX topology. A group address identifies a shared communication function to which multiple communication objects may be linked. Neither address alone defines value encoding. The datapoint type (DPT) defines encoding and semantics such as boolean switching, percentage, temperature, scene, or time.
For each integration point preserve:
- individual and group addresses exactly as exported from the approved ETS project;
- main/sub DPT and any product specific interpretation;
- direction, transmit/read/write/update flags, feedback group, and response behaviour;
- unit, valid range, default/unknown rules, and expected update interval;
- whether it is protected by KNX Secure, including the keyring version;
- ownership and authorisation for commands.
Don't infer a DPT from payload length. Several meanings share the same encoded width, and wrong scaling can create plausible but unsafe values. A write telegram being accepted doesn't prove actuator motion or final state; use an authoritative feedback object and explicit timeout.
KNXnet/IP boundaries#
KNXnet/IP supports routing and tunnelling roles. Confirm device discovery, tunnelling slot capacity, individual address allocation, multicast/routing configuration, filter tables, line/backbone coupling, NAT limitations, and reconnect behaviour. Avoid fleet wide auto discovery or unconstrained group monitoring on production networks.
Classic KNXnet/IP must not be treated as secure merely because it is on an IP VLAN or inside a generic tunnel. Use the applicable KNX Secure profile end to end where supported, and protect legacy TP/RF/PL segments and IP routers as trust boundaries.
Commissioning and change control#
ETS project exports, keyrings, device certificates/FDSKs, and product databases are sensitive configuration artefacts. Version, encrypt, access control, and back up them according to site policy. Reconcile running devices with the approved project before changing addresses or application programs. Never learn group meanings by exploratory writes.
KNX can control doors, blinds, lifts, lighting, HVAC, and occupancy dependent workflows. Use a bench or owner approved commissioning window, retain manual recovery, and keep certified fire/life safety functions outside an ordinary KNX integration unless the complete approved system design explicitly includes them.