KNX colour lighting cross-check preview
The cross-check view keeps KNX source data visible next to generated Control4 candidates, so colour channels, DPT 232.600, DPT 251.600, CCT objects, feedback and gateway context can be reviewed before export.
Start with the DPT model, not the colour wheel
A standard KNX dimmer usually needs command, level and feedback objects. RGB and tunable white can use DPT 1 on/off, DPT 3 relative dimming, DPT 5.001 channel/brightness values, gateway-defined colour-temperature objects, DPT 232.600 RGB, DPT 242.600 xyY, DPT 251.600 RGBW or vendor-specific gateway behavior.
If those objects are imported blindly, Control4 can end up with separate red, green and blue dimmers instead of one user-facing colour light, or with a colour wheel that writes a format the KNX gateway does not expect.
- Separate normal dimmer objects from colour-channel and colour-temperature objects.
- Check whether RGB/RGBW is combined or split into individual red, green, blue and white group addresses.
- Confirm feedback for every visible Control4 control: on/off, brightness, colour, warmth and scenes.
Review the colour model before choosing the driver path
Control4 projects can use dedicated coloured-lighting drivers or colour wheel interfaces, including third-party KNX Coloured Lighting workflows. Those drivers still depend on the ETS reality: channel order, DPTs, scale, gateway mode and feedback decide whether the UI will behave correctly.
CoduWorks prepares a reviewable colour-lighting candidate instead of silently merging every RGB object into the create-only core build. The installer can then decide whether the project needs an add-on, a dedicated driver, manual Composer configuration or a simpler dimmer-only output.
Tunable white and CCT are separate from RGB
Tunable white is usually about brightness plus warmth or colour temperature, not red, green and blue colour mixing. Some projects use relative warmth on DPT 5.001, others use an absolute colour-temperature object defined by the gateway or manufacturer.
The .codu export should keep CCT and RGB decisions visible instead of flattening both into one generic light. That makes it clear which objects can become a Control4 dimmer, which need a colour driver and which remain gateway context.
DALI, DMX and gateway context can change the answer
Many KNX colour lighting projects are actually KNX-to-DALI, KNX-to-DMX or vendor-specific gateway designs. ETS may expose useful group objects while the real colour commissioning remains in the lighting gateway.
DPT 251.600 also deserves special care because KNX Association notes historic market implementations with different RGBW encoding. The review should use the actual ETS/gateway data, not just a friendly object name.
Treat RGB and tunable white as separate scope
The CoduWorks core build focuses on switch lights, dimmers, blinds, scoped thermostats and KNX/IP gateways. RGB, RGBW and tunable white are reviewed separately because the mapping effort depends on DPT design, channel grouping, driver choice, UI expectations and feedback.
Keeping colour lighting outside the base tier avoids making ordinary light/blind projects more expensive while still giving complex colour projects a proper review path.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Does CoduWorks automatically create KNX RGB lights in Control4?
Not as part of the core automatic build. RGB, RGBW and tunable white are reviewed as separate scope because channel mapping, DPTs, gateway behavior and Control4 UI support vary by project.
Which KNX DPTs matter for Control4 colour lighting?
Common candidates include DPT 1 for on/off, DPT 3 for relative dimming, DPT 5.001 for channel or brightness values, gateway-defined colour-temperature objects, DPT 232.600 for RGB, DPT 242.600 for xyY and DPT 251.600 for RGBW.
Why not count every RGB channel as a normal device?
Counting each channel as a normal light can inflate pricing and still produce a poor user experience. The better approach is to review the colour model and scope it separately.
Do dedicated Control4 colour drivers remove the need for review?
No. A colour driver can provide the UI, but it still needs correct KNX group addresses, DPTs, feedback and gateway mode. CoduWorks prepares that evidence before the Composer configuration step.
Review colour lighting before the Composer build
Import ETS, inspect RGB/RGBW, DPT 232.600, DPT 251.600 and tunable white object families, then decide the correct Control4 handoff before exporting .codu.