KNX naming cleanup preview
The preview shows search, review and cleanup tools used before exporting a KNX project to a Control4 Composer-ready package.
Why names matter before Composer
Composer needs a user-facing device tree. ETS often contains technical labels, abbreviated group names, mixed languages or inconsistent room references. If those names are copied forward without review, the Control4 project becomes harder to trust.
The AI Assistant can infer patterns, but the installer still needs a clear review step to confirm when a group address family represents a light, dimmer, blind, gateway reference or only programming context.
Naming patterns that help the review
There is no single universal KNX group address structure. Function-based, room-based and device-based structures can all work when they are consistent and self-explanatory.
For Control4 handoff, the most useful pattern is one that makes the real device, room and signal role visible without opening every actuator channel manually.
- Room or area label that matches the intended Control4 room.
- Function label such as light, dimmer, blind, shade, status, scene or gateway.
- Signal role such as command, feedback, value, stop, position or slat.
What makes automatic grouping harder
Mixed naming conventions make it harder to know whether a point is a user-facing device or only a helper signal. For example, a dimmer may have switch, relative dimming, absolute level and feedback objects with different naming styles.
Ambiguous names do not mean the project cannot be processed. They mean the installer should review the generated Control4 view, bulk edit repeated names and keep uncertain objects out of the automatic build until confirmed.
- Same room written several ways across ETS.
- Command and feedback objects named as unrelated devices.
- Scene, central, lock or diagnostic objects named like normal lights.
Clean up before the .codu export
CoduWorks gives the installer a place to correct generated names, translate labels, search repeated patterns and bulk edit device structure before the Composer driver creates anything.
That is the practical difference between a review-first workflow and a direct import. The names can be improved while the KNX source remains visible, not after the Control4 tree is already built.
What Composer should receive
Composer should receive a reviewed .codu package with readable rooms, devices, subtypes and mapping context. The goal is not to force ETS into one naming standard; it is to make the generated Control4 structure understandable before creation.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Do I need to rename my ETS project before using CoduWorks?
Not necessarily. Clear ETS naming helps, but the AI Assistant is designed to review and clean the generated Control4 structure before export.
Which KNX group address structure is best for Control4?
The best structure is consistent and self-explanatory. Room-based, function-based and device-based layouts can work if command, feedback and device intent are clear.
Can bulk edit fix repeated naming problems?
Yes. Repeated labels, room names, language cleanup and subtypes can be corrected before the .codu package is exported to Composer.
Can bad naming create wrong Control4 devices?
It can create ambiguity. That is why mappings, names, DPTs and feedback should be reviewed before automatic device creation.
Review naming before the Composer build
Import ETS, inspect generated names and mappings, clean repeated patterns and export a reviewed .codu package.