CoduWorks
Contact
KNX → Control4OverviewFor integratorsServicesFree ToolsBlogAboutContact
Preflight checklist/Updated May 2026

KNX to Control4 checklist before exporting to Composer

Before a KNX project becomes a Control4 build, the installer should know what is ready, what is unsupported and what needs review. This checklist keeps the .codu export focused on a reviewed structure instead of loose assumptions.

  • Check ETS source quality before processing.
  • Review supported devices, DPTs, feedback and gateway context.
  • Confirm pricing count and build report expectations before Composer.
Open AI AssistantView product

Preflight export checklist preview

The preview shows a reviewed KNX to Control4 project moving toward export, with build context checked before the Composer driver creates devices.

1. ETS source file

Start with a finished ETS project. The .knxproj should reflect the real topology, room structure, device naming and group address organization you want to use as the source of truth.

  • Use a processable .knxproj file, not a password-protected project.
  • Check that buildings, floors and rooms are named clearly.
  • Keep a backup of the ETS project before processing.

2. Supported device scope

Confirm which objects should become Control4 devices. The current automatic scope focuses on switch/dimmer lights, open-close or percentage blinds, and KNX IP gateways.

  • Lights and dimmers have command and feedback context.
  • Blinds have position/open-close, stop and feedback context where available.
  • Keypads, push buttons and sensors should not move the license tier.
  • Thermostats count when included, but they still need detailed HVAC review.

3. Group addresses, DPTs and feedback

Review command and feedback addresses together. A clean build needs more than a group address list; it needs datapoint and function context.

  • DPT-1 style values for switch, stop or open-close behavior.
  • DPT-5 style values for dimmer level, blind position or feedback percentage.
  • DPT3 relative dimming objects visible for review, not automatic generation.

4. Gateway and routing context

Check that the relevant telegrams can reach the Control4 path. If a gateway, router or filter table hides addresses, Composer can look wrong even when the generated mapping is logical.

5. Composer build readiness

Before running the Composer driver, review the build report. The numbers should match the reviewed rooms, supported devices and expected create-only behavior.

  • Review duplicate risk before creating devices.
  • Confirm license tier counts lights, blinds, thermostats and IP gateways.
  • Use the .codu as a closed package, not as a place to solve unresolved decisions inside Composer.

Official references checked

Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.

Next cluster reading

These pages connect ETS import, KNX mapping and the final Composer build.

Control4 KNX best practices before Composer creates devicesImport an ETS project into Control4 without rebuilding it by handControl4 KNX driver workflow with a reviewed ETS source

Related tools and documentation

FAQ

What should be checked before .codu export?

ETS source quality, supported devices, group addresses, DPTs, feedback, gateway context, duplicate risk and expected device count.

Do keypads and sensors count for pricing?

No. Pricing tiers count lights, blinds, thermostats and IP gateways. Keypads, push buttons and sensors do not move the tier.

Should unsupported devices be forced into the build?

No. Unsupported or unclear combinations should remain visible for review rather than being converted blindly into Control4 devices.

Next step

Run the checklist before exporting .codu

Use the AI Assistant to process ETS, review the generated Control4 structure and export only when the project is ready for Composer.

Open AI AssistantView product landing