Control4 KNX build report preview
The preview shows a reviewed .codu package moving into Composer. The driver presents a build plan so the installer can inspect rooms, devices, duplicate warnings and create-only actions before the project is built.
The build report is the last pause before creation
A useful Control4 KNX build report is not a decoration after import. It is the installer pause between a reviewed package and real Composer changes.
The report should make the planned structure visible: locations, supported devices, matched names, skipped entries and any warnings that could create cleanup work later.
Create-only plan, not another editor
The Composer step should run from a closed .codu package. Major naming, room, line, DPT or mapping fixes should already be handled in the AI Assistant before export.
That separation keeps the driver focused on building and keeps the review work in the place where KNX context is still visible.
What the action summary should confirm
Before running the build, the installer should compare the report with the expected project scope. The important question is not only whether the file imports, but whether the create-only plan matches the reviewed KNX project.
- Expected buildings, floors and rooms.
- Counted lights, blinds, thermostats and KNX IP gateways.
- Matched, skipped or potentially duplicated devices.
- Warnings for unsupported or incomplete KNX mappings.
When not to run the build
If the report shows unexpected rooms, missing lights, wrong blind counts, duplicate warnings or unsupported device candidates, do not run creation yet.
Fix the structure in the review layer, export a fresh .codu package and read the report again before letting Composer create anything.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
What is the Control4 KNX build report?
It is the Composer driver summary that should show what the reviewed .codu package is about to create, skip or flag before the build runs.
Is the build report the same as project documentation?
No. Project documentation explains the KNX to Control4 map for review. The build report is the final Composer checkpoint before creation.
Does the report prevent duplicates by itself?
It helps by making duplicate risks visible before the run. The installer still needs to stop and correct the package if the report does not match expectations.
What should I do if the action summary looks wrong?
Do not create devices. Go back to the AI Assistant, fix naming, rooms or mappings, export a new .codu file and review the build report again.
Use the report as the final Composer checkpoint
Process the ETS project with AI, review the Control4 structure, export .codu and read the build report before running the Composer driver.