KNX dimmer actuator cross-check preview
The cross-check view keeps KNX source objects, DPTs and generated Control4 dimmer candidates visible together so command, level and feedback can be reviewed before export.
A dimmer actuator is an object family
A normal KNX dimmer channel can include several ComObjects. One object may switch the load, another may change brightness by relative dimming, another may set an absolute level and another may report the current value.
CoduWorks should use ETS context to group those objects into a single reviewed Control4 dimmer candidate. That avoids duplicate devices and makes the .codu package easier to trust before Composer creates anything.
- Switch command and optional switch status.
- Relative dimming, often used by keypad hold actions.
- Absolute brightness value, commonly DPT 5.001 scaling.
- Brightness feedback or status value.
- Locks, central functions, staircase logic, presets or scene objects as context.
DPT 5.001 and brightness scale need verification
DPT 5.001 is commonly used for a brightness value represented as a percentage scale. The review still matters because ETS names, gateway behavior and feedback objects decide which address is a command and which address is state.
If a project mixes level command and level feedback, Control4 can show the wrong value after a KNX keypad, sensor or scene changes the light outside the Control4 UI.
Relative dimming alone is not a stable user-facing dimmer
DPT3 relative dimming is useful for up/down or press-and-hold behavior, but it does not by itself give Control4 a reliable absolute brightness state.
The review should pair relative dimming with absolute value and feedback where the ETS project provides them. When it does not, the installer should see that limitation before the build plan is accepted.
Feedback decides whether Control4 stays in sync
A dimmer can be changed from KNX keypads, motion logic, scenes, central off objects or vendor-specific automation. Without brightness feedback, the Control4 interface can look correct only when Control4 was the last controller.
The AI Assistant should mark missing or ambiguous feedback so the installer can choose whether to proceed, fix ETS naming or keep the object out of the create-only build.
Composer should receive one clean dimmer
The .codu handoff should tell the Composer driver which Control4 dimmer to create and which KNX addresses belong to it. It should not ask the installer to solve object grouping inside Composer after the devices already exist.
This is especially important in large projects where dozens of dimmer channels repeat the same naming pattern, DPT assumptions and feedback conventions.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
What KNX objects does a Control4 dimmer usually need?
A reviewed dimmer normally needs switch command, brightness command and brightness feedback. Some projects also include switch feedback, relative dimming and extra context objects.
Is DPT 5.001 required for every KNX dimmer?
It is a common brightness scaling datapoint, but the real ETS object model must be checked. Relative dimming alone is not the same as a stable absolute level with feedback.
Do KNX dimmers count in the license tier?
Yes. Supported light and dimmer channels are counted devices, so they count in the light/blind/thermostat/gateway pricing tier.
Should lock or scene objects create extra Control4 devices?
Usually not. Locks, central functions, staircase logic and scenes should stay as review context unless the project scopes them separately.
Check KNX dimmers before the Composer build
Import ETS, review each dimmer actuator channel, verify DPTs and feedback, then export a clean .codu package for Composer.