Relay load review/Updated May 2026

Review KNX relay loads before creating Control4 devices

Name: KNX relay load cross-check preview
Uploaded: 2026-05-20
Description: The cross-check view keeps KNX relay channels, contact feedback and generated Control4 structure visible together so special loads can be reviewed before export.

Relay outputs in a KNX project can look like simple switch points, but gates, garage doors, pumps, extractors and similar loads usually need a different review than lighting. CoduWorks keeps them visible as KNX context and manual scope items instead of auto-generating them as normal lights.

Separate simple switch lighting from relay loads that move hardware or affect pumps.
Check command, feedback/contact status, timing and safety interlocks before Composer.
Keep relay loads out of the automatic core build until the installer confirms the scope.

Open AI Assistant View product

KNX relay load cross-check preview

The cross-check view keeps KNX relay channels, contact feedback and generated Control4 structure visible together so special loads can be reviewed before export.

Why relay loads are not just lights

A KNX relay may expose a 1-bit command that resembles a switch light. The user intent can still be completely different: a pulsed garage input, a gate opener, a pump enable, an extractor fan, a leak alarm relay or another technical load.

Treating every relay as a Control4 light creates the wrong UI and can hide safety assumptions. The workflow should identify the relay, keep its ETS source visible and ask whether it belongs in Composer as a device, a programmed action, a hidden status or an excluded item.

Momentary pulse versus maintained on/off behavior.
Command group address versus contact/status feedback.
Safety, lockout and manual override requirements outside a normal lighting build.

What the AI Assistant should surface

The useful output is not an automatic device every time. The AI Assistant should surface the KNX command, feedback object, source actuator, DPT, room or area naming and any nearby binary input/contact that explains the real function.

That gives the installer enough context to decide whether the load should be manually added, handled by a specific Control4 driver, left as programming context or kept out of the .codu create-only build.

Command GA, feedback/status GA and DPT 1 semantics.
Actuator/channel name from ETS and whether it describes gate, pump, garage or fan intent.
Related contact closure or sensor used to prove open, closed, fault or running state.
Whether the relay should be pulsed, latched, protected or manually scoped.

Gate, garage and pump examples

A garage door or gate normally needs more than a relay command. The Control4 side often needs a contact or status signal so the UI can know whether the door is open, closed or moving, and programming should respect safety and installer-confirmed behavior.

Pump, extractor and similar technical loads can also appear as relay channels or binary input alarms in ETS. They are useful context for alerts and logic, but they should not be silently generated as regular user-facing devices.

Scope and pricing boundary

The counted CoduWorks build is intentionally focused on lights, blinds, thermostats and KNX/IP gateways. Relay loads such as pumps, gates, garage doors and extractors are not part of the automatic generation unless a future add-on or manual project scope confirms how they must behave.

That boundary keeps pricing fair and keeps the Composer package clean. A project may contain many relays, keypads and contacts, but the tier is still driven by counted lights, blinds, thermostats and KNX/IP gateways.

Composer handoff

Before export, relay loads should appear as clear review items with their KNX evidence. The .codu should not create a generic light or fake device unless the installer has confirmed that this is the intended Control4 representation.

Composer receives a cleaner plan: supported devices can be built automatically, while relay loads stay as explicit decisions for programming, manual driver selection or add-on review.

Official references checked

Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.

FAQ

Does CoduWorks auto-generate KNX relay loads?

No, not by default. Relay loads such as gates, garage doors, pumps and extractors remain context or manual/add-on scope unless the installer confirms the required behavior.

Can a KNX relay control a garage door or gate in Control4?

It can be part of the solution, but the project normally also needs contact/status feedback, safety review and clear Composer programming or a suitable driver.

Do pumps, gates and fans count in the core license tier?

No. The counted CoduWorks scope remains lights, blinds, thermostats and KNX/IP gateways. Relay loads are reviewed separately unless a project-specific add-on changes the scope.

Why not treat every KNX relay as a switch light?

Because the same 1-bit relay command can represent very different behavior. A light, pump, gate pulse and alarm relay have different UI, status and safety expectations.