ETS preparation/Updated June 2026/7 min read

How to prepare an ETS .knxproj file before importing it into a Control4 workflow

The best KNX to Control4 workflow starts before the file is uploaded. If the ETS project is named consistently and contains usable DPT, object and room context, the review stage is faster and the final Composer build is easier to trust.

Key checks

Export the project archive after ETS names and topology are stable enough for review.
Make command and feedback relationships visible through naming and group address structure.
Keep unsupported or unclear devices identifiable instead of hiding them inside generic names.

Before exporting: stabilize the project enough for review

The ETS file does not need to be perfect, but it should be coherent. Room names, actuator labels, communication objects and group address names should be stable enough that another integrator can understand what the project intends to do.

Late changes are normal. The goal is not to freeze the KNX project forever, but to avoid uploading a file where the same function appears under five different naming styles.

Use consistent names for lights, dimmers, blinds, thermostats and gateways.
Avoid temporary labels such as test, spare, old or copy unless they are intentionally excluded.
Confirm that final rooms and areas are reflected somewhere in the ETS context.

Make group address families easy to understand

A Control4 device is easier to infer when related KNX addresses follow a recognizable pattern. Command, status, level, stop and position should be close enough in naming or structure to be reviewed as one function.

If the project uses several address conventions, document the rule before import. This prevents the review step from becoming a guessing exercise.

Check DPT and communication object context

DPTs and communication object names are strong signals for mapping. Missing or misleading DPT context forces more manual review later, especially for dimming and blind functions.

For lights and blinds, the integrator should confirm that object roles are clear enough to distinguish command from feedback. When the role is unclear, it is better to leave a visible review item than to create a misleading Control4 device.

Keep gateway, router and line context visible

Control4 does not only need end devices. It also needs to reach the KNX installation through the correct IP path. If a project has several lines, routers or interfaces, that context should remain visible in the imported file.

For pricing and device count, the CoduWorks workflow counts lights, blinds, thermostats and IP gateways as devices. Keypads, push buttons, sensors and similar inputs do not move the license tier by themselves.

Upload readiness checklist

Before uploading the .knxproj, check that the file opens correctly, represents the latest commissioned state, and includes the relevant rooms and group addresses. If the file is password protected or incomplete, resolve that before processing.

After upload, use the KNX view to confirm that topology, devices and addresses appear as expected. Do not wait until Composer to discover that the source file was not the right version.

External references

These references are included for context; the workflow guidance is based on CoduWorks implementation and integration review practice.

FAQ

Do I need a finished KNX project before importing?

The project should be coherent enough for review. It can still change later, but unstable names and missing context will create more manual cleanup.

Is an OPC export enough?

OPC exports can be useful for address lists, but a .knxproj archive usually gives richer topology, device and communication object context for Control4 preparation.

Which devices count for CoduWorks pricing?

Lights, blinds, thermostats and IP gateways count as devices. Keypads, push buttons, sensors and similar inputs are useful context but do not move the license tier by themselves.