Search and KNX GA lookup preview
The preview shows search, replace and KNX Group Address lookup from the generated Control4 view, keeping source context visible before export.
Why search matters before Composer
Composer can search for drivers and includes Find and Replace for programming references, but a KNX import review has a different problem: the installer needs to connect a Control4 device candidate with its ETS source addresses, DPTs and ComObjects.
That search should happen before the build. Finding a wrong feedback address or a naming pattern after devices already exist in Composer turns a review issue into cleanup work inside the live project.
- Find a generated device by name, room, line, subtype or address pattern.
- Keep the KNX group address and ComObject context visible while reviewing it.
- Spot repeated naming or mapping patterns before the .codu package is exported.
What the lookup should find
A useful GA lookup is not just a text filter. It should help the installer understand why a Control4 light, blind or gateway candidate was created and which KNX objects are behind it.
The review should expose command addresses, feedback addresses, DPT hints, ComObject names, device names, room context and line context so the installer can confirm the structure before Composer receives the package.
- Group Address values and labels from the ETS source.
- ComObjects connected to the generated Control4 candidate.
- DPT and function hints used to separate command, status, level, stop and position.
- Rooms, lines and repeated naming conventions that may need cleanup.
Search and replace with a clear boundary
Search and replace is useful for repeated naming cleanup, room naming conventions or consistent labels. It should not be used to hide mapping uncertainty.
If a DPT is unclear, feedback is missing or a device family is outside the supported scope, that item should remain visible for technical review instead of being renamed into something that looks finished.
Not the same as Composer driver search
Control4 Composer search is useful for finding and adding device drivers. The CoduWorks search view is different: it searches the reviewable KNX-derived project before the Composer driver builds it.
This distinction lets the installer answer project questions earlier: which address drives this light, where is the feedback, which DPT was inferred, and why did the AI Assistant place the device in this room.
Review before .codu export
The final handoff should not be a loose list of addresses. It should be a reviewed build package where search results, replacements and mapping decisions have already been checked.
That gives Composer a cleaner create-only package and gives the installer a clearer pause before the driver creates devices.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can CoduWorks search KNX group addresses from the Control4 view?
Yes. The review view is designed to search generated Control4 devices while keeping KNX group addresses, ComObjects and DPT context visible.
Is this the same as Composer Search?
No. Composer Search helps find drivers and project items inside Composer. CoduWorks searches the KNX-derived review structure before .codu export.
Can search and replace fix mappings?
It can clean repeated naming or structure patterns, but mapping issues such as missing feedback, wrong DPT or unsupported scope still need technical review.
Why not use an ETS spreadsheet instead?
A spreadsheet can list addresses, but it does not keep the generated Control4 device candidate, room, ComObjects and review state together in one workflow.
Search the project before Composer
Import ETS, find GAs and ComObjects from the Control4 review view, then export .codu only after the mapping context is clear.