Control4 driver editor preview
The preview shows Control4 devices being reviewed and edited with KNX context before the build package is exported to Composer.
DriverEditor versus project editor
The official Control4 DriverEditor and DriverWorks tools are for creating or modifying drivers. A KNX to Control4 project editor has a narrower job: clean the generated rooms, devices, naming and mapping context before the existing Composer driver runs.
That distinction matters for SEO and for installers. You should not need to write Lua, build an IR driver or modify a Control4 driver just to review hundreds of KNX-derived lights and blinds before creation.
- DriverEditor intent: develop or modify drivers.
- DriverWorks intent: Lua, proxy behavior, XML and driver packaging.
- CoduWorks intent: review KNX-derived Control4 project structure.
- Composer intent: run the final build from the exported .codu package.
When the official DriverEditor is the right answer
Use Control4 DriverEditor, Driver Wizard or the DriverWorks SDK when the job is to create a new device driver, edit driver XML, write Lua behavior, package a .c4z/.c4i driver or work against the official Control4 driver database.
That is different from a KNX import workflow. If the driver already exists and the problem is rooms, naming, supported lights, blinds, thermostats, gateways, group addresses or DPT context, the work belongs in the project review layer before .codu export.
- Official driver path: DriverEditor, DriverWorks SDK, Lua, XML, proxies and .c4z/.c4i files.
- CoduWorks path: .knxproj import, AI processing, review, bulk edits, .codu export and Composer build report.
- Installer decision: do not start a driver-development workflow just to clean a KNX-derived project tree.
What the editor is for
The editor is not a replacement for Composer. It prepares the structure that the Composer driver will build, using KNX context from the ETS project.
This is useful when hundreds of imported objects need naming cleanup, room placement or subtype adjustments before they become Control4 devices.
Why not do every edit in Composer
Composer is powerful, but repetitive naming and mapping work becomes slow when each change must be made after device creation.
Editing before export reduces cleanup, makes bulk review easier and keeps the KNX source visible while decisions are made.
Review state before export
A good driver editor workflow tracks what has been reviewed, what still needs attention and what is ready for export.
That prevents the .codu package from becoming a collection of unresolved assumptions.
- Supported devices marked clearly.
- Ambiguous mappings visible before build.
- Bulk edits reviewable before export.
Build with the Composer driver
Once the structure is reviewed, the Composer driver receives the .codu file and shows the build plan before creation.
This keeps the editor focused on preparation and the driver focused on reliable project creation.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Is this the same as Control4 DriverEditor or DriverWorks?
No. Control4 DriverEditor and DriverWorks are for driver development, Lua behavior, XML/proxy work and packaging drivers such as .c4z or .c4i. This workflow edits the KNX-derived Control4 project structure before the Composer driver creates devices.
Should I use Driver Wizard or DriverEditor for KNX import cleanup?
No, not if the driver already exists. Driver Wizard and DriverEditor are for creating or maintaining drivers. KNX import cleanup is about ETS context, rooms, devices, mappings and review before .codu export.
Is this a Control4 Composer replacement?
No. Composer remains the final Control4 environment. The editor prepares and reviews the project before the Composer driver builds it.
What can be edited before export?
Rooms, device names, supported subtypes, mapping context and bulk changes can be reviewed before the .codu export.
Why keep KNX context visible?
Because the installer can verify that each Control4 device still matches the original KNX source, group addresses and datapoints.
Prepare the Control4 driver build with review
Use the editor to clean the generated structure, then export a .codu file that the Composer driver can build.