Generic KNX project import preview
The preview shows a KNX project imported from ETS, reviewed in the KNX view and processed into a Control4 structure before export to Composer.
Why a wizard may show no rooms or devices
Some import paths are designed around known Control4 KNX device data or very specific project assumptions. In a generic ETS project, the useful information may live in names, group addresses, ComObjects, DPTs and topology rather than in Control4-specific device records.
That is why a wizard can appear to find the file but still show no floors, no rooms or no devices. The symptom is often a mismatch between what the wizard expects and how the real KNX project was commissioned.
When that happens, a one-step import can produce an empty or incomplete result even though the ETS project contains the information needed to build a useful Control4 structure.
The project may not contain Control4-specific ETS devices
A normal KNX installation can be full of usable lights, blinds, actuators, sensors, keypads and gateway context without containing Control4-branded devices inside ETS.
CoduWorks treats that as a project-parsing problem rather than a dead end. The AI Assistant reads the broader KNX context and prepares a Control4 structure that can be reviewed before Composer receives a .codu package.
What CoduWorks extracts from a standard ETS project
The AI Assistant treats the .knxproj as the source of KNX context. It reviews rooms, lines, devices, group addresses, ComObjects, DPTs and naming patterns to propose Control4 rooms and supported devices.
The goal is not to pretend every KNX object is a finished Control4 device. The goal is to create a structure that an installer can review before Composer builds anything.
- Lights, dimmers, blinds and KNX/IP gateway context for the core build.
- Command and feedback group addresses tied to generated devices.
- Unsupported or ambiguous objects kept visible for review instead of hidden.
Review comes before Composer creation
A generic ETS project can contain inconsistent naming, missing feedback, DPT mismatches and topology assumptions. These should be reviewed before a Composer driver creates rooms and devices.
CoduWorks exports a .codu package only after the generated structure has been reviewed, so the Composer driver receives a closed build plan instead of loose notes.
This is not ETS commissioning
CoduWorks does not commission KNX devices, configure ETS flags or change coupler filter tables. ETS remains the source and infrastructure tool.
The platform focuses on the missing bridge between a finished KNX project and a clean Control4 build: parsing, review, mapping context and Composer handoff.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can I import a KNX project with no Control4 devices in ETS?
Yes. The workflow starts from the .knxproj source and builds a reviewable Control4 structure from KNX context, not from Control4-specific ETS devices only.
Why does the Control4 ETS import wizard show no rooms or devices?
Often because the ETS project uses standard KNX devices and naming rather than the Control4-specific records or assumptions the import path expects.
Will every KNX device become a Control4 device?
No. The core automatic build focuses on lights, dimmers, blinds, scoped thermostats and KNX/IP gateway context. Keypads, sensors and unsupported objects remain context or review items.
Does this replace the official Control4 ETS tools?
No. It is a separate review-first workflow for preparing a .codu package for the CoduWorks Composer driver. Use official tools where they fit your project.
Import the real KNX project, then review the Control4 build
Upload the .knxproj, let the AI Assistant prepare the Control4 structure, review mappings and export a .codu package for Composer.