KNX scene object cross-check preview
The cross-check view keeps KNX scene objects, DPTs, keypads and generated Control4 structure visible together so scene context can be reviewed before Composer programming.
A KNX scene object is not a Composer scene
A KNX scene object can call or save a scene number on the KNX bus. A Control4 scene is a Composer programming construct with lights, loads, room behavior, tracking and often keypad bindings. The two concepts can be related, but they should not be collapsed into one automatic device.
CoduWorks should keep the KNX scene evidence visible so the installer can decide whether it becomes Composer programming context, a keypad intent note, or a manual scene reconstruction task.
DPT 17 and DPT 18 need explicit review
DPT 17 usually carries a scene number. DPT 18 can carry scene control with call/store semantics. Those details matter because a scene button may mean recall only, store/learn, or a project-specific value table.
The review should identify the DPT, source device, group address name and expected behavior before any Control4 programming is planned.
- DPT 17 scene number and payload range used by the project.
- DPT 18 call/save or learn behavior where present.
- Scene number label in ETS versus the payload sent on the KNX bus.
- Keypad, touch panel, logic module or actuator source object.
- Whether the scene object is command, status, trigger context or legacy logic.
Scene number offsets can create off-by-one mistakes
Some KNX tooling presents scene numbers as 1 to 64 while bus payloads may be represented as 0 to 63. If that convention is not checked, a Control4 action can trigger the wrong KNX scene or the wrong user-facing label.
A review-first workflow should flag scene number assumptions as decisions for the installer, not silently translate them into Composer programming.
Scene buttons are keypad context
A keypad scene key often tells the installer what the room is supposed to do: welcome, all off, night, relax, clean, away or another project label. That intent is valuable even when the keypad itself is not created as a core device.
The .codu package should preserve the source name, DPT and group address so Composer programming can be deliberate after the supported lights, blinds, thermostats and gateways are created.
Keep scene programming outside the automatic build
The core build should remain focused on supported devices. KNX scene objects, keypad scene keys and DPT 17/18 payloads belong in review context or project-specific programming scope.
That keeps the generated Composer project clean while still exposing the scene evidence that can speed up final programming.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can KNX scene objects become Control4 scenes automatically?
Not in the core workflow. They should be reviewed as scene context. Composer remains the place for final scene programming and keypad bindings.
Why do DPT 17 and DPT 18 matter?
DPT 17 usually represents a scene number, while DPT 18 can include call/store behavior. The difference affects whether a signal is a trigger, a save command or project context.
What is the 0-63 versus 1-64 issue?
KNX scene labels may be shown as 1 to 64 while bus payloads can be represented as 0 to 63. The installer should verify the convention before mapping behavior in Control4.
Do scene buttons count as licensed devices?
No. Scene buttons, keypads and trigger objects do not move the tier by themselves. The counted scope remains lights, blinds, thermostats and KNX/IP gateways.
Review KNX scene objects before Composer
Import ETS, inspect scene objects, DPTs and keypad intent, then export .codu with scene context preserved for programming.