KNX switch actuator cross-check preview
The cross-check view keeps KNX source objects, DPTs and generated Control4 switch-light candidates visible together so command, status and relay intent can be reviewed before export.
A switch actuator is not always a light
Many KNX switch actuator channels are normal lighting circuits. Others control extractors, pumps, gates, garage contacts, towel rails, technical outputs or central logic. From a raw DPT 1 command alone, those can look similar.
CoduWorks should use ETS names, rooms, device type, ComObjects and feedback to decide whether a channel is a supported Control4 switch light or a relay load that needs manual review.
- Light circuit that should become a Control4 switch light.
- Technical relay load that should not be treated as a normal light.
- Central on/off, staircase timer, lock or priority object that is only context.
- Feedback/status object that belongs to an existing channel.
DPT 1 command and feedback need pairing
A supported switch light usually needs an on/off command address and a reliable status or feedback address. The feedback matters when the light changes from KNX keypads, sensors, timers or central functions instead of Control4.
The review should not create separate devices for command and status. It should group them as one switch-light candidate and show missing or ambiguous feedback before export.
Names and rooms decide whether the build is useful
Switch actuator names imported from ETS often contain panel, channel, circuit or shorthand labels. Those labels are useful for tracing the source, but Control4 needs readable room and display names.
Bulk edit and search/replace are useful before .codu export because a naming pattern can repeat across dozens of actuator channels.
Central, lock and staircase objects are not extra lights
Switch actuators may expose central off, forced position, disable, lock, staircase timer, fault or diagnostic objects. These signals can explain behavior, but they should not inflate the device count or create extra visible lights.
The installer should see those objects as context and decide whether any of them belongs in Composer programming, troubleshooting or a separate manual scope.
Composer should receive one reviewed switch light
The .codu package should tell the Composer driver which switch light to create and which KNX addresses belong to it. It should not leave command/status grouping or relay intent as an unresolved Composer task.
This keeps the create-only build predictable and protects the live Control4 project from duplicate, mislabeled or unsafe relay devices.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Does every KNX switch actuator channel become a Control4 light?
No. Only reviewed lighting channels should become core switch lights. Technical relay loads, central functions and lock objects should stay as context or separate scope.
What addresses does a Control4 switch light usually need?
Usually an on/off command address and a feedback/status address. The status address keeps Control4 aligned when KNX changes the light outside the Control4 UI.
Do switch actuator channels count in the license tier?
Yes when they are reviewed as supported light channels. Auxiliary objects such as central off, lock or diagnostic signals should not create extra core devices.
How is this different from relay gate or pump loads?
A switch-light channel is a normal lighting device. Gates, pumps, garages and other technical relay loads need manual intent, safety and feedback review before they are scoped.
Check switch actuators before Composer
Import ETS, review DPT 1 command and status objects, separate real lights from relay context and export a clean .codu package.