PDF documentation and review preview
The preview shows project documentation tools around PDF export, AI translation and rollback before the Control4 export package is created.
Why export a PDF before Composer
Composer can produce native project reports, but those reports describe the Composer project after it exists. In a KNX import workflow, many important decisions should be reviewed earlier, before the build package creates devices.
A pre-Composer PDF gives the installer and project team a static view of what the AI Assistant prepared. It is easier to review naming, room placement, supported devices and mapping assumptions before those choices become part of the Composer project.
- Review generated rooms and devices before the .codu export.
- Share a readable snapshot with the installer or project lead.
- Keep the review conversation out of the live Composer project until the build is ready.
What the documentation should include
The useful document is not just a screenshot. It should describe the generated Control4 structure and preserve enough KNX context to explain why each item exists.
For supported scope, that means lights, dimmers, blinds, scoped thermostats and KNX/IP gateways, plus related command and feedback addresses, DPT hints, rooms, lines and warnings for unsupported or ambiguous items.
- Generated Control4 rooms, devices and supported subtypes.
- KNX group addresses, ComObjects and DPT context used for review.
- Feedback, gateway and warning notes that should be checked before build.
- Naming, translation or bulk edit decisions that affect the .codu package.
Not a replacement for Composer reports
This is not intended to replace official Composer reports, project code exports or dealer documentation. Composer remains the final build and validation environment.
The CoduWorks PDF is a review artifact from the platform stage. It helps decide whether the generated package is ready to become a Composer project, not whether the finished Composer project has been fully commissioned.
Documentation with translation and rollback
PDF export pairs well with AI translation, search and bulk edit. If the team changes naming conventions, translates room names or reorganizes generated devices, the documentation should reflect the reviewed state.
Rollback matters because a document should not freeze the wrong version. The safest workflow is to review changes, export documentation, then generate the .codu only when the structure is accepted.
Cleaner handoff to the Composer driver
The PDF is for people; the .codu is for the driver. Keeping both aligned reduces confusion: the team reviews the PDF, then Composer receives the closed build package that matches the reviewed structure.
That makes the build report easier to inspect because the installer already knows what the package is supposed to create.
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 export a Control4 KNX project to PDF?
It can export the pre-Composer review map and KNX-derived structure as documentation before the .codu package is generated.
Is this the same as a Composer project report?
No. Composer reports describe the Composer project. This PDF documents the review state before Composer creates devices.
What should be checked in the PDF?
Rooms, device names, supported scope, command and feedback addresses, DPT hints, gateway context, warnings and naming changes should be reviewed.
Should the PDF be created before or after .codu?
Use it before the final .codu handoff when possible, so the team can review the structure before the Composer driver builds it.
Document the project before Composer
Import ETS, review the generated Control4 map, export documentation and create the .codu only after the structure is accepted.