KNX contact cross-check preview
The cross-check view keeps KNX contact objects and generated Control4 structure visible together so door contacts, window contacts and alarm signals can be reviewed before export.
Why contact signals matter in a Control4 project
A door or window contact is often not something the user controls directly. It is a state signal that can inform security, climate, lighting, notifications or automation rules. In Control4, that makes it useful, but only if the meaning is clear before programming starts.
The ETS project may show many similar 1-bit objects. Some are physical reed contacts, some are alarm states, some are HVAC window functions, and some are feedback objects. The review step should separate those meanings before the Composer driver builds the project.
- Door and window state for security scenes and alerts.
- Window-open context for HVAC or split unit logic.
- Alarm, leak, gate or garage status used as programming context.
Open, closed and alarm are not interchangeable
A 1-bit telegram is not enough by itself. A value of 1 may mean open in one KNX device, alarm in another, enabled in another and closed in a project-specific convention. That matters when the signal becomes a Control4 event or notification.
Before export, the installer should see the source device, group address name, ComObject label, DPT and any available status object. This avoids inverted states, false alerts and Composer logic that fires at the wrong time.
- Confirm whether 1 means open, closed, alarm, enabled or fault.
- Check whether the contact sends changes automatically or only answers reads.
- Review debounce/noise risk for contacts that may bounce between states.
How contacts should be handed to Composer
CoduWorks should surface contact candidates as review context next to the generated Control4 structure. The installer can then decide whether each signal should be a visible status, a hidden programming input, an HVAC condition or an item to keep out of the create-only build.
Composer remains the place for project-specific logic: security notifications, mock occupancy, HVAC lockout, lighting response, announcements or custom actions. The value of the AI Assistant is to make the KNX signal and its meaning visible before that programming work begins.
Door and window contacts do not move the core tier
The CoduWorks tier counts lights, blinds, thermostats and KNX/IP gateways. Door contacts, window contacts, reed sensors, alarm contacts and similar status inputs can remain visible as context without increasing the device tier by themselves.
That keeps projects with many windows, doors and technical sensors more affordable while still preserving the signals that matter for Control4 programming.
Preflight checklist before using a contact
Before a contact is used in Control4, check that the ETS name is understandable, the DPT matches the expected binary state, the transmit behavior is correct and the signal reaches the KNX/IP path that Composer will rely on.
If the signal is ambiguous, it should stay as a review note instead of being converted into a visible Control4 device or used silently in generated logic.
- Readable room and contact naming.
- DPT 1 semantics and group address direction.
- Transmit flag or equivalent event behavior.
- Gateway, router and line coupler visibility.
- Clear decision: visible status, programming input, HVAC condition or out of scope.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can a KNX door contact appear in Control4?
Yes, if the signal is mapped and represented correctly. It should be reviewed for DPT, open/closed semantics, transmit behavior and Composer use before export.
Do door and window contacts count as CoduWorks license devices?
No. Contacts, reed sensors and alarm inputs do not move the tier by themselves. The counted scope remains lights, blinds, thermostats and KNX/IP gateways.
Can window contacts affect HVAC in Control4?
They can be useful as HVAC context, but the behavior depends on the KNX project, DPT, gateway path and Composer programming. It should be reviewed before build.
Review KNX contacts before Control4 programming
Import ETS, inspect door and window contacts, confirm DPT and state semantics, then export a clean .codu package for Composer.