Use an ETS6 KNX project as the source for Control4

Why ETS6 should stay the source

ETS6 already contains project decisions that are easy to lose in a spreadsheet: room names, function labels, device context, group addresses, line connections and datapoint types.

Using that export as the source gives the Control4 workflow more context than a manual address list.

Use the real ETS6 project export

The file to upload should be a processable ETS project export, normally the .knxproj file created by exporting the project from the ETS6 Dashboard or Local Projects list. KNX documents ETS6 project export as the .knxproj format, with bus connections included as part of the project.

This is especially important when another tool fails to import a project. A failed import does not automatically mean the KNX project is unusable; it often means the receiving workflow expected a different export format or lost room, ComObject or DPT context.

• Use the ETS6 export workflow to create a shareable .knxproj file.
• Avoid ProjectStore copies as the normal handoff artifact for Control4 preparation unless KNX support specifically needs the source for repair.
• Keep CSV, OPC or ESF exports as references, not as the primary source.

Check ETS version and schema assumptions

ETS6 project files carry version-specific structure. KNX documents that an ETS6 .knxproj can be imported in ETS with the same or higher major/minor version, not an older minor version. A review-first workflow should preserve the source, expose parsed assumptions and let the installer check rooms, locations and DPTs before the .codu file reaches Composer.

That makes the ETS6 page different from a generic import promise: it is about turning a specific ETS export into a Control4 build plan that can be inspected before devices are created.

If an ETS6 import fails

When an ETS6 import fails, first treat the source as a project-readiness problem. If the original ETS source is available, export the project again. If only the .knxproj is available, keep the file and any project password information with the project owner or KNX support path.

For CoduWorks, the important decision is whether the .knxproj is processable enough to show topology, group addresses, ComObjects and DPTs. If not, do not continue toward Composer as if the file were clean.

• Re-export from ETS6 when the original source is available.
• Keep project password, ownership and KNX Secure context explicit.
• Do not replace a failed project import with a flat CSV unless the missing context is acceptable.

What to check after import

After import, the KNX view should be reviewed before processing. The goal is to confirm that the expected topology, group address families and device labels are visible.

This step prevents a bad source import from becoming a larger Composer cleanup job.

• Expected rooms and functions are present.
• DPTs and group address names look complete enough for mapping.
• Infrastructure such as KNX IP gateways is visible and not mixed with user devices.

AI parsing output

The AI Assistant groups the KNX source into a Control4 view that can be edited before export. That includes generated rooms, supported device types and mapping context.

The review step is important because ETS naming conventions vary between installers and projects.

Build in Composer after review

The Composer driver should receive the reviewed .codu file, show the run plan and then create the project structure when the installer is ready.

This keeps ETS6 as the KNX source, the AI Assistant as the review layer and Composer as the final build tool.

Related tools and documentation

• KNX-Control4 driver documentation
• KNX to Control4 mapping estimator
• KNX group address generator
• KNX-Control4 workflow videos
• KNX-Control4 technical blog

FAQ