KNX motion sensor cross-check preview
The cross-check view keeps KNX sensor objects and generated Control4 structure visible together so motion, presence, brightness and trigger candidates can be reviewed before export.
Why KNX sensors need a review layer
A motion or presence detector often exposes several KNX objects: movement, presence, brightness, enable, lockout, slave mode, timeout, status or scene-related values. A single group address rarely tells the whole story.
If the signal is imported blindly, Control4 can end up with the wrong trigger, inverted occupancy, missed timeout logic or a sensor represented as a visible user device when it should be programming context.
- Movement and presence are not always the same object.
- Brightness and threshold objects may affect lighting logic.
- Enable, disable and lockout addresses can change when the detector sends events.
Where the AI Assistant should stop and Composer should start
CoduWorks can surface motion and presence candidates with ETS source, room, DPT, ComObject label, group address and related sensor objects. That gives the installer enough context to decide how the signal should be used.
Composer remains the place for custom programming: occupancy timers, night-light scenes, manual override behavior, security alerts, music triggers or HVAC conditions. The automatic build should stay focused on supported devices and keep sensors as review context unless a project-specific scope says otherwise.
Motion lighting needs manual override decisions
Motion-controlled lighting often needs rules around manual keypad use. If a user turns a light on manually, the motion timeout may need to behave differently than when the sensor turned it on automatically.
That logic is specific to each project. The review step should show the sensor, light, keypad and feedback context together before the installer programs behavior in Composer.
- Which sensor turns which light or scene on.
- Whether absence turns lights off automatically.
- How manual keypad commands should override sensor timing.
DPT, timing and feedback checks
Presence sensors may use binary values, status objects, brightness values, HVAC presence objects or enable signals. The installer should know whether the detector sends an event, reports state, needs read requests or depends on an enable address.
The KNX/IP route also matters. If the signal does not pass through routers, line couplers or filter tables, Composer may never see the event even though the sensor works locally in ETS.
Sensors stay outside the core device count
The CoduWorks tier counts lights, blinds, thermostats and KNX/IP gateways. Motion sensors, presence detectors, brightness sensors and similar records can remain visible as context without increasing the tier by themselves.
This keeps larger KNX projects fair: a building can have many detectors, but the create-only build should still focus on the visible Control4 devices that are actually generated.
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 motion sensors trigger Control4 programming?
They can when the signal is represented correctly and reaches Composer reliably. DPT, event behavior, gateway path and programming intent should be reviewed before export.
Do KNX sensors count as CoduWorks license devices?
No. Motion sensors, presence detectors and brightness sensors do not move the tier by themselves. The counted scope remains lights, blinds, thermostats and KNX/IP gateways.
Should motion sensors become visible Control4 devices?
Usually they are better as programming context or hidden status unless the project has a specific sensor device scope. They should not be mixed into the core build blindly.
Review KNX sensor context before Composer
Import ETS, inspect motion and presence objects, check DPT and timing assumptions, then export a clean .codu package for Composer.