Protected ETS import preflight
The import preview shows the ETS project being uploaded and reviewed before AI processing. Password-protected files should be resolved before this step so the KNX source remains readable.
Why a password-protected .knxproj blocks the workflow
CoduWorks needs a processable ETS project to read topology, devices, group addresses, ComObjects, DPT hints and names. If the archive cannot be opened, the AI Assistant cannot safely infer lights, blinds, thermostats, gateways or review context.
That is different from a weak naming problem or a missing room. A protected project should be fixed before upload because later review tools cannot recover context that was never readable.
- Do not treat the password prompt as a Composer issue.
- Do not replace the project with a partial list unless the lost context is acceptable.
- Keep the ETS owner involved when the protected file came from another integrator.
Separate a normal project password from KNX Secure
Some projects are protected simply because the ETS file has a password. Other projects require a password because KNX Secure is active and security keys must remain controlled.
If the project is not using KNX Secure, the practical fix is usually to have the ETS owner open the project, remove the password or create a processable export, then upload that export. If KNX Secure is involved, decide the security handling first instead of stripping protection just to satisfy an import tool.
- Confirm whether KNX IP Secure or KNX Data Secure is used.
- Keep project passwords and key ownership inside the installer security process.
- Never treat password recovery tools as part of the CoduWorks workflow.
What to check before uploading again
Before retrying the import, make sure the file opens in ETS, represents the final commissioned project and contains the room, line, device and group address context needed for review.
A CSV, OPC or XML export can help as a reference, but it often loses topology, device and ComObject context. For the CoduWorks workflow, a clean .knxproj export remains the preferred source when available.
- Final ETS version, not an old archive.
- Readable building, room and device naming.
- Group addresses with DPT, command and feedback context.
- Gateway and KNX Secure notes visible to the installer.
Composer should receive a reviewed package, not a password problem
Composer is the place where the driver builds the reviewed structure. It should not be the first place where the team discovers that the ETS source was inaccessible.
Once the source is processable, the AI Assistant can prepare rooms, supported devices and warnings. The .codu export should happen only after the protected-file issue is resolved and the installer can review what will be created.
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 import a password-protected .knxproj?
No. The current workflow expects a processable ETS project file. Resolve the password or export issue before upload.
Can CoduWorks recover an ETS project password?
No. Password recovery is not part of the workflow. Ask the ETS project owner or commissioning team for a valid export.
What if the project uses KNX Secure?
Treat it as security scope. Confirm key ownership, gateway path and export handling before using any automation or Composer build workflow.
Is a CSV or OPC export enough instead?
It can help as reference, but it usually carries less context than .knxproj. Use it only when the missing topology and ComObject data are acceptable.
Fix the ETS access issue before Composer
Prepare a processable .knxproj, then import it into the AI Assistant, review the KNX context and export .codu only after the source is clear.