KNX DALI gateway cross-check preview
The cross-check view keeps KNX source data visible next to the generated Control4 structure. The installer can review DALI groups, DPTs, feedback, faults and gateway context before exporting the build package.
C4-KNX-DALI reaches Control4 as KNX lighting context
The official C4-KNX-DALI gateway is programmed from ETS 5.6.6+ with KNXPROD DG/S1.64.1.41, while DALI readdressing and group assignment are handled in the Control4 KNX Tool. The AI Assistant stays on the KNX project side: it reads the .knxproj and makes the DALI-related group objects easier to review before export.
That distinction matters in large projects. One gateway output can represent up to 64 DALI devices and 16 DALI groups, plus broadcast, individual control, scenes, feedback and fault objects. Only the parts that form a supported Control4 light or dimmer should move into the build plan.
- Use ETS as the source for C4-KNX-DALI group objects, names and DPTs.
- Keep ctrl4.co/knx-dali and ctrl4.co/knx-tool as commissioning references, not as Composer build steps.
- Confirm which objects are switching, brightness, dimming, feedback, faults or diagnostics.
Individual, group and broadcast objects cannot be flattened blindly
DALI lighting groups can be useful Control4 light candidates when the ETS names, DPTs and feedback addresses make the intent clear. But the gateway documentation also warns that DALI group assignment cannot overlap, and a device controlled individually is not also controlled through DALI groups.
Before Composer creates anything, review whether each object belongs to a switch, dimmer, broadcast function, individual ballast, DALI group or context-only signal. This avoids creating duplicate Control4 lights from the same physical DALI channel.
Faults and emergency lighting need a different review path
A C4-KNX-DALI project can expose status signaling, lamp faults, ballast faults, partial failures, battery charge, emergency lighting tests and other diagnostic objects through KNX. Those signals are useful for review, but they should not automatically become normal user-facing Control4 lights.
The gateway can connect KNX to emergency lighting information, but it is not the regulatory logging system. CoduWorks keeps that distinction visible so the .codu export prioritizes clean command and feedback mapping for supported lights while leaving diagnostics as context or separate scope.
Composer should receive a closed lighting plan
The .codu package should tell the Composer driver which lights to create, which KNX group addresses they use and which gateway objects were kept as context. It should not force the installer to decide inside Composer which C4-KNX-DALI objects are real user-facing devices.
A review-first workflow is especially useful when one gateway represents many DALI channels, because a single naming, DPT or feedback assumption can repeat across the whole project.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Does the AI Assistant commission the C4-KNX-DALI gateway?
No. DALI addressing and group assignment stay in ETS and the Control4 KNX Tool. The AI Assistant reviews the .knxproj context and prepares supported Control4 lighting devices from readable KNX-side data.
How many DALI devices and groups should be reviewed?
The gateway documentation describes up to 64 DALI devices on the output and up to 16 lighting groups. CoduWorks uses the ETS objects to decide what should become Control4 lights, dimmers or review-only context.
Should fault and emergency objects become Control4 lights?
Usually not. Lamp faults, ballast faults, emergency tests and battery/test results are diagnostic context unless the project explicitly scopes them as separate status or add-on work.
Check DALI gateway lighting before export
Import the ETS project, review C4-KNX-DALI objects, separate lights from diagnostics and export a controlled .codu package for Composer.