Control4 KNX driver list workflow
The preview shows KNX context being reviewed before a Control4 build. Driver categories are checked against rooms, devices and the Composer handoff package.
Start with the network layer
Before choosing device drivers, the project needs a reliable KNX connection layer. In Control4 discussions this usually means understanding whether the project uses a KNX Network style connection, a KNX Routing Gateway workflow or other gateway context.
That decision affects visibility, routing, multicast behavior and whether feedback can reach Composer reliably. It should be reviewed before device creation starts.
- Confirm KNX IP gateway or routing gateway context.
- Check line couplers, filter tables and dummy-device needs when the project has multiple lines.
- Do not treat the gateway as a room device, but keep it visible for build planning.
Driver families are not all equal
A driver list may include switch actuators, dimmers, blinds, thermostats, movement detectors, universal interfaces, DALI gateways, valve drives and other KNX categories. Those categories do not all map to the same automatic build behavior.
CoduWorks focuses the counted generated build on lights, dimmers, blinds, scoped thermostats and KNX/IP gateways. Other driver families remain visible as context or move into add-on review when they need project-specific decisions.
- Lights and dimmers need command and feedback review.
- Blinds need movement, stop, position and status context where available.
- Thermostats count when they are included in scope, but HVAC models, RGB, DALI and sensors need separate review before build promises are made.
Read the driver list against the ETS file
The driver category alone is not enough. ETS names, ComObjects, DPTs, group address structure and room context decide whether a Control4 device can be generated cleanly.
For example, a dimmer needs more than a label that says dimmer. The review should confirm command, level, level feedback and any unsupported relative dimming assumptions before export.
Turn the list into a Composer plan
The useful output is not a static list. It is a reviewed .codu package where the installer can see what will be created, what stays as context and what should be handled manually or as an add-on.
That keeps Composer as the build environment while the driver-list interpretation happens earlier, with KNX context still visible.
Avoid creating a driver for every KNX object
Many KNX projects contain keypads, contacts, sensors, gateways and service objects that should inform the build without becoming visible Control4 devices. Creating everything creates noise and makes the final UI harder to trust.
A better workflow uses the driver list to narrow decisions: generate supported devices, keep useful context visible and flag uncertain categories for review.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Where do I find the official Control4 KNX driver list?
Control4 references KNX driver documentation and dealer knowledgebase resources. The practical project step is to compare those categories with the ETS file before building devices in Composer.
Does CoduWorks recreate the full Control4 KNX driver list?
No. CoduWorks uses the ETS project to prepare a reviewable Control4 structure. The core automatic build focuses on lights, dimmers, blinds, scoped thermostats and KNX/IP gateways, with other categories handled as context or add-ons.
Should every KNX driver category become a Control4 device?
No. Some categories are infrastructure, context or programming signals. They should remain visible for review instead of being blindly generated as user-facing devices.
Use the driver list as a review checklist
Upload the ETS project, review which KNX categories can become Control4 devices and export a cleaner Composer package.