Existing KNX to Control4 retrofit preview
The preview shows an existing KNX project being processed into a reviewed Control4 structure before the .codu handoff to Composer.
Keep KNX as the field layer
In a retrofit, KNX should usually remain the field layer for lighting, blinds, HVAC signals and infrastructure. Control4 adds interface, AV, scenes, client control and project structure on top of that source.
That means the workflow should respect the commissioned KNX project. CoduWorks does not rewrite a working ETS project blindly. It reads the ETS context, prepares Control4 candidates and leaves review decisions visible before export.
- Existing wiring and KNX devices stay in place.
- ETS remains the source for group addresses, topology and DPT context.
- Control4 receives a reviewed structure rather than loose manual notes.
What to collect before adding Control4
The most important asset is the ETS .knxproj file. Without it, the installer may only have partial exports, spreadsheets or addresses copied from a live project, which makes room structure, feedback and device intent harder to verify.
A retrofit review should also identify the KNX/IP gateway or router, line boundaries, filter-table assumptions, supported devices and any existing Composer structure that must not be duplicated.
- ETS .knxproj file, project password status and export readiness.
- KNX/IP gateway, routing or tunneling path and feedback visibility.
- Existing Control4 rooms or devices if this is an upgrade, not a first build.
Review scope before Composer
Not every KNX object should become a Control4 device. Lights, blinds, scoped thermostats and KNX IP gateways are core for the counted build. Keypads, sensors, weather signals, binary inputs and wider HVAC may be context, triggers or add-on scope depending on the project.
A review-first retrofit separates those categories before Composer creates anything. That keeps the project readable and protects existing work from duplicate or wrongly named devices.
Build from a closed handoff package
After review, the AI Assistant exports a .codu package. The Composer driver uses that package to show what it is about to create, check duplicates and build the approved structure.
This is the useful retrofit path: keep KNX working, make the mapping transparent and let Composer create from a reviewed plan instead of reconstructing the project by hand.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can Control4 be added to an existing KNX installation?
Yes, if the KNX project, gateway route and supported device scope can be reviewed. The safest workflow starts from the ETS .knxproj file and exports a reviewed .codu for the Composer driver.
Does this replace the KNX installation?
No. KNX remains the field layer. Control4 adds interface, Composer structure and client-facing control on top of the reviewed KNX context.
What if the original ETS file is missing?
Partial exports may help as references, but a missing .knxproj makes review weaker. The page and toolchain are designed around a processable ETS project whenever possible.
Will it touch existing Control4 devices?
The preferred retrofit path is a visible create-only plan with duplicate checks. Existing Composer work should be reviewed before running the build.
Prepare the existing KNX project for Control4
Import the ETS file, review gateway, feedback and supported devices, then export a .codu package for Composer.