ETS export source review
The import preview shows ETS project context being reviewed before AI processing. Partial exports can support the review, but the full project source gives better context before Control4 export.
What partial ETS exports usually contain
An OPC or ESF export is useful when another tool needs group address names and address structure. CSV or XML group address exports can also help installers audit naming, share lists or check address families outside ETS.
That makes these files practical for diagnostics and references. The problem is that a Control4 workflow needs more than a list: it needs to understand which addresses belong together as one light, dimmer, blind or gateway context.
- Group address names and address levels.
- Some datapoint information depending on export type and ETS version.
- Useful reference data for checks, handover notes or troubleshooting.
What can be lost compared with .knxproj
A partial export can lose topology, devices, communication objects, manufacturer application context and some datapoint detail. That may be acceptable for a quick lookup, but it is risky as the only source for automatic Control4 structure generation.
The AI Assistant can reason better when it sees the project source. Names, devices, ComObjects, rooms and DPT hints help decide whether several group addresses form one user-facing device or just supporting context.
- Room and topology context may be incomplete.
- ComObject names and source device relationships may be missing.
- Old OPC-style exports may not represent every modern DPT cleanly.
When OPC, ESF or CSV is still useful
Partial exports are useful when a password-protected .knxproj cannot be processed yet, when the installer wants to compare group address names, or when a support team needs a quick list before the full ETS source is available.
Use them as supporting evidence, then return to the .knxproj workflow when the goal is to generate a reviewable Control4 structure and a .codu package for Composer.
Why Composer should not receive a blind address list
Composer needs a build plan: rooms, devices, supported types, command addresses, feedback addresses, gateway context and duplicate checks. A flat export can hide the assumptions behind that plan.
Before export, review which address families become core devices, which stay as context and which need manual Composer programming. That prevents address lists from becoming duplicated or incomplete 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 I build Control4 from an ETS OPC or ESF export?
Use it only as reference material. For the CoduWorks workflow, .knxproj is preferred because it can carry richer topology, device and ComObject context.
Is CSV enough for group address mapping?
It can help audit names and addresses, but it may not show how addresses, DPTs, feedback and source devices belong together.
When should I use OPC, ESF or CSV?
Use them for lookup, troubleshooting or comparison. Use a processable .knxproj when preparing a reviewable .codu package for Composer.
What if my .knxproj is password protected?
Resolve the ETS access or KNX Secure scope first. A partial export can help discussion, but it should not silently replace the project source.
Use partial exports as checks, not the final source
Import the .knxproj when possible, compare OPC/ESF/CSV references where useful, and export .codu only after Control4 structure review.