Taking over a KNX installation without documentation is one of the more demanding situations a system integrator can face. No ETS project file, no wiring diagrams, no record of which group addresses control what: just a live system that someone expects to work. It happens more often than it should, particularly when a previous installer has moved on or a building has changed hands. Knowing how to approach a KNX installation audit in these circumstances is a skill that separates experienced integrators from those who get stuck at the first hurdle.
This guide walks through the practical steps for auditing an inherited KNX system with missing documentation: from establishing what hardware is physically present, to recovering group address structures, to rebuilding a reliable record that makes future integrations straightforward.
Starting points when no ETS project file exists
When there is no ETS project file to work from, the first priority is to establish what you actually have. Before touching any configuration, take a full set of photographs of every distribution board, bus coupler cabinet, and panel; these images become the foundation of your new documentation set.
Next, check whether the devices themselves hold recoverable data. Many KNX devices store their individual application programs locally, which means ETS can read device information directly from the bus using the “read from device” function. This will not give you the full project structure, but it does reveal device types, manufacturer references, and sometimes application parameters. Cross-reference these with manufacturer datasheets to understand what each device is capable of, and you already have a partial picture of the installation.
How to map the physical topology of an unknown installation
Mapping the physical topology of an unknown KNX installation means tracing every line segment back to its line coupler or area coupler, and confirming the bus addressing structure. Start at the KNX power supply units; there is typically one per line. Follow the bus cable from there.
Use ETS to scan each line for active devices. The bus scan function will detect all devices that respond on a given line address range and display their physical addresses. Record these systematically: area number, line number, device number. Once you have a complete list of physical addresses, you can begin assigning them to locations in the building by systematically triggering each device (switching a light, activating a shutter) and noting which physical space responds. This process is time-consuming but essential for creating an accurate topology map.
Recovering group addresses and datapoint assignments
Recovering KNX group addresses from an undocumented system requires patience and a structured approach. The most reliable method is to use ETS to read the group object table from each individual device. This reveals which group addresses are assigned to that device and in what role, whether it sends, receives, or both.
Work through each device methodically, building a spreadsheet that lists every group address discovered, the devices linked to it, and the observed function. Testing group addresses by sending telegrams via the ETS Group Monitor, while watching which actuators respond, helps confirm the datapoint type and function. Pay particular attention to:
- Lighting circuits and their dimming channels
- Blind and shutter actuators with separate move and stop addresses
- HVAC setpoint and mode group addresses
- Status feedback addresses that may not have obvious physical outputs
This recovered address list, however incomplete it may feel initially, becomes the skeleton of a new ETS project file.
Common risks and failure points in inherited KNX systems
Inherited installations often carry problems that were never resolved or were papered over by the previous integrator. Recognising these failure points early prevents them from becoming your problem after handover.
Bus voltage instability is one of the most common issues. If the power supply is undersized for the number of devices on a line, or if a device has developed a fault that draws excessive current, the entire line can become unreliable. Measure bus voltage at the power supply and at the far end of each line; a significant voltage drop indicates a wiring or load problem. Other risks worth checking include:
- Duplicate physical addresses caused by improper device replacement
- Corrupted device applications from incomplete programming sessions
- Incorrect line coupler filter tables that block necessary telegrams
- Devices running outdated firmware that may conflict with newer components
Document every anomaly you find during the audit, even if it is not causing an obvious problem today. An inherited system with missing KNX documentation often has issues that were tolerated rather than fixed.
Rebuilding documentation and preparing for future integrations
Once the audit is complete, the goal is to produce documentation that makes the installation maintainable and extensible, something the previous integrator failed to leave behind. A minimum viable documentation set includes a topology diagram, a complete group address list with functional descriptions, a device inventory with physical locations and firmware versions, and annotated photographs of all distribution boards.
Save the recovered ETS project file with a clear version history from the start. Even if the recovered project is imperfect, it is far more useful than nothing, and it gives any future integrator a genuine starting point. Preparing the system for future integrations, whether that means connecting it to a KNX IP interface for remote configuration, enabling app-based control, or bridging to voice platforms, becomes significantly easier once this foundation is in place. A well-documented KNX system is also far simpler to expand with smart energy management capabilities, where accurate group address mapping is essential for controlling loads intelligently.
How xxter supports professionals taking over undocumented installations
xxter understands that auditing an inherited system is only the beginning. Once the documentation is rebuilt and the installation is stable, integrators need reliable tools to deliver the full smart home experience their clients expect, without adding complexity.
The xxter controller connects directly to a KNX installation and enables full control through the free xxter app on smartphones, tablets, and computers. For professionals working with recovered group address structures, xxter makes it straightforward to map those addresses into a polished control interface. The platform also supports:
- Voice control via Apple HomeKit, Amazon Alexa, and Google Assistant through the Pairot bridge for voice platform integration
- Smart energy management with the xxter Smart Energy Manager, which actively controls KNX-connected loads based on solar production, dynamic pricing, and consumption patterns
- No subscription fees or license costs for the integrator or the end client
If you are working through a KNX system audit and want to understand how xxter can help you deliver a complete, future-proof installation on top of that recovered infrastructure, explore the full xxter product range or get in touch with the xxter team directly.
Veelgestelde vragen
How long does a full KNX installation audit typically take when there is no existing documentation?
The time required depends heavily on the size and complexity of the installation. A small residential system with one or two lines and fewer than 50 devices might take one to two days to audit thoroughly, while a larger commercial installation with multiple areas, dozens of lines, and hundreds of devices can take a week or more. Building in extra time for unexpected issues — such as duplicate physical addresses or corrupted device applications — is always wise, and rushing the process risks producing incomplete documentation that creates problems down the line.
What if ETS cannot read a device during the bus scan — does that mean the device is faulty?
Not necessarily. A device that does not respond to a bus scan could be powered off, have a corrupted application that prevents communication, or be sitting on a line segment with a wiring fault or insufficient bus voltage. Before assuming a device is faulty, verify that bus voltage is within the 21–30V DC range at that point on the line, check for physical damage to the bus cable, and try resetting the device to factory defaults using its programming button. If the device still does not respond after these steps, then hardware failure becomes the more likely explanation.
Is it safe to send test telegrams via the ETS Group Monitor on a live system with occupants present?
This requires careful coordination. Sending telegrams to unknown group addresses on a live system can trigger unexpected behaviour — shutters moving, lights switching off, or HVAC modes changing — which is disruptive and potentially unsafe if the building is occupied. Before using the Group Monitor for testing, notify building occupants or facility managers, carry out testing during low-occupancy periods where possible, and avoid sending telegrams to group addresses linked to safety-critical systems such as emergency lighting or access control until their function is fully confirmed.
How do I handle duplicate physical addresses discovered during the audit?
Duplicate physical addresses are one of the most disruptive issues an inherited installation can contain, because two devices sharing the same address will both respond to programming commands, making it impossible to configure either one reliably. The fix is to put one of the conflicting devices into programming mode (press its programming button until the red LED lights) and then use ETS to assign it a new, unique physical address. Do this one device at a time and confirm the change before moving on. Once all duplicates are resolved, re-scan the affected lines to verify that every address is now unique.
What is the best way to document group addresses when rebuilding an ETS project from scratch?
A structured spreadsheet running in parallel with ETS is the most practical approach during the recovery phase. For each group address discovered, record the address itself, the datapoint type (DPT), all devices linked to it, the function observed during testing, and any notes about unusual behaviour. Once you have a reasonably complete picture, transfer this structure into ETS using a logical naming convention — for example, area, room, function, and object type — so that any integrator picking up the project in the future can navigate it intuitively. Consistency in naming from the outset saves significant time during any future expansion work.
Can I connect a KNX IP interface to an inherited installation before the audit is fully complete?
Technically yes, but it is not recommended until at least the physical topology is mapped and bus stability is confirmed. Connecting an IP interface to an unstable line — one with voltage issues or corrupted devices generating excessive telegram traffic — can make remote diagnostics harder and may introduce additional variables when troubleshooting. Complete the core audit steps first, resolve any identified bus faults, and then add the IP interface as part of the documentation and integration phase, where it becomes a useful tool for ongoing monitoring and remote configuration.
What should I do if the previous installer's ETS project file exists but is clearly out of date or incomplete?
Treat an outdated ETS project file as a useful starting reference rather than a reliable source of truth. Import it into ETS and use it to cross-reference physical addresses and group address ranges, but verify every entry against the actual live system before relying on it. Pay particular attention to devices that appear in the project file but do not respond on the bus, and to group addresses that exist in the file but produce no observable response when tested — both are strong indicators that the installation has been modified since the file was last updated. Annotate discrepancies as you find them and update the project file to reflect the actual current state of the system.