KNX binary input cross-check preview
The cross-check view keeps KNX input objects and generated Control4 structure visible together so contact closures, feedback and programming candidates can be reviewed before export.
What binary inputs mean in a KNX to Control4 project
A binary input usually represents an event or state rather than a device the user expects to control directly. It may report a door contact, pump alarm, panic input, window contact, push button, leak sensor relay or other dry contact wired into KNX.
That makes it valuable context for Control4, but it also makes it easy to misuse. The signal may deserve Composer programming, a notification, a scene condition or a hidden state object instead of a visible device in every room.
- Door, window, alarm and technical contacts are usually status or trigger context.
- Push button contacts may overlap with keypad and scene programming intent.
- Dry contact signals should be reviewed before they appear in a build plan.
DPT and transmit behavior are the first checks
The group address alone is not enough. A binary input should be checked for DPT, value semantics, transmit behavior, feedback availability and whether the value is sent when the physical contact changes.
If the input is only readable on request or does not cross the KNX line/router path, Composer programming may never see the event reliably. The review needs to happen before the .codu export.
- DPT 1 style binary values for open/closed, on/off, alarm or enable signals.
- Transmit flags or equivalent project behavior that sends changes on the bus.
- Feedback/status group address and gateway visibility across line couplers.
- Clear naming that explains what the physical contact actually represents.
Binary inputs are context, not core licensed devices
CoduWorks keeps the license count focused on lights, blinds, thermostats and KNX/IP gateways. A project may have many binary inputs, sensors or contact closures without moving the tier by itself.
That matters because large KNX sites often have many technical signals. Counting every input as a full generated device would make pricing less fair and would create noise in the Control4 structure.
How the signal should reach Composer
The AI Assistant should surface binary input candidates with their ETS source, DPT, room, group address and naming context. The installer can then decide whether the signal should be used as Composer programming context, a hidden status reference or a project-specific add-on.
The Composer driver should still receive a clean create-only package for supported devices. Binary inputs become clear review items rather than accidental lights, fake devices or duplicate controls.
Typical examples to review
A sewage pump alarm, fire contact, window contact or leak relay can be important for automation and notifications. The project should preserve those signals and make them easy to inspect, but it should not assume the correct Control4 behavior without installer review.
For each input, the practical question is simple: should this create a visible Control4 device, feed programming, remain as diagnostic context, or stay out of the Composer build?
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Do KNX binary inputs count as CoduWorks devices?
No. Binary inputs, dry contacts, sensors and similar trigger signals do not move the license tier by themselves. The counted scope is lights, blinds, thermostats and KNX/IP gateways.
Can a KNX contact closure trigger Control4?
It can be possible when the DPT, transmit behavior, gateway path and Composer representation are correct. The signal should be reviewed before it is used in programming.
Should every binary input become a Control4 device?
No. Many binary inputs are better treated as programming context, hidden status or project-specific review items instead of visible devices.
Review KNX input signals before Composer
Import ETS, find binary inputs and contact closures, review DPT and transmit behavior, then export a clean .codu package for Composer.