Supported device workflow preview
The preview shows the reviewable workflow from ETS to Control4. Supported device families are prepared for export while other KNX context remains visible for review.
Counted generated device scope
The first production scope focuses on device families that can be reviewed predictably from ETS: switch lights, dimmers, open-close blinds, percentage blinds, scoped thermostats and KNX/IP gateways. Those are the objects the installer can prepare, review and export into the Composer driver build.
This narrower scope is deliberate. It keeps the build package easier to audit and avoids turning every KNX object into a Control4 device just because it exists in the ETS project.
- Switch lights and dimmers with command and feedback review.
- Blinds with open-close, stop, percentage and position feedback where available.
- KNX/IP gateway context used for routing, visibility and license count.
What counts for the license tier
For pricing and tiering, CoduWorks counts lights, blinds, thermostats and KNX/IP gateways. Keypads, push buttons, sensors and similar records can be important context, but they do not move the license tier by themselves.
This keeps large KNX projects more accessible when they contain many physical inputs but only a smaller number of user-facing Control4 devices to generate.
Context that should remain visible
A keypad, push button, binary input or sensor may explain why a room is named a certain way or why a group address exists. The workflow should not discard that context; it should keep it visible during review.
Visible context helps the installer make better decisions without forcing unsupported object families into the create-only Composer build.
Add-ons and non-core systems
HVAC beyond scoped thermostats, RGB, tunable white, DALI and custom logic need more project-specific review. They can involve fan coils, split units, colour channels, gateway behaviour or vendor-specific DPT choices.
Those systems should be scoped separately instead of being hidden inside the bulk build. If they are reviewed as add-ons, the installer can confirm the required signals before Composer receives the package.
Why not generate every KNX object automatically?
Automatic creation is only valuable when the generated device is understandable and reviewable. Creating every KNX object blindly would produce noise, duplicate controls and devices with unclear user value.
A better workflow keeps the KNX source visible, creates supported Control4 structure from known patterns and leaves uncertain object families as review items.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Which KNX devices are supported in the core workflow?
The counted workflow focuses on switch lights, dimmers, blinds, scoped thermostats and KNX/IP gateways. These are reviewed before export and then built through the Composer driver.
Do keypads or push buttons count as devices?
No. They can be useful KNX context, but they do not move the license tier unless the project scope explicitly adds a separate workflow for them.
Are thermostats and HVAC supported?
Yes. Thermostats count when they are included in the prepared Control4 build, and they still need careful review because setpoints, modes, fan speed, demand state and feedback vary heavily between KNX projects.
Review supported devices before export
Use the AI Assistant to turn ETS into a focused Control4 build package: lights, blinds, thermostats, gateways and clear review items for everything else.