Keypad context/Updated May 2026

KNX keypads and push buttons should inform the Control4 build

Name: KNX keypad context cross-check preview
Uploaded: 2026-05-20
Description: The cross-check view keeps KNX source data visible next to the generated Control4 structure so keypads, push buttons, devices and feedback can be reviewed before export.

KNX keypads, push buttons and binary inputs often explain how a room is actually used. They may trigger scenes, music, lighting logic or status changes, but they should not be blindly counted as generated Control4 devices in the core lights and blinds workflow.

Keep keypads and push buttons visible as ETS context during review.
Separate trigger intent from generated lights, blinds, thermostats and gateways.
Do not move the CoduWorks license tier because a project has many keypads.

Open AI Assistant View product

KNX keypad context cross-check preview

The cross-check view keeps KNX source data visible next to the generated Control4 structure so keypads, push buttons, devices and feedback can be reviewed before export.

Why keypads matter even when they are not core devices

A KNX keypad can reveal room intent, naming patterns, scene behavior and the relationship between physical interaction and Control4 automation. That context is useful when reviewing the generated Control4 structure.

The important decision is not whether every keypad becomes a Control4 device. The important decision is whether its addresses and labels explain something the installer needs to check before Composer creates the final project.

Use keypad labels and ComObjects to understand room behavior.
Keep button events separate from lighting and blind device creation.
Review binary input and push button addresses before export when they affect automation.

Trigger intent needs review before programming

Some KNX button presses may be used to trigger Control4 behavior, but that depends on driver support, DPT, transmit flags, status objects and the Composer programming model.

A review-first workflow should mark those signals clearly instead of hiding them inside the main bulk build. This prevents the installer from confusing a physical input with a generated light, blind or gateway device.

Keypads and push buttons do not move the license tier

For CoduWorks pricing, the counted device scope is lights, blinds, thermostats and KNX/IP gateways. A project can contain hundreds of keypads, push buttons, sensors or binary inputs without moving the license tier by itself.

That pricing rule keeps KNX projects more accessible while still allowing these objects to remain visible as context for review, troubleshooting and project-specific add-ons.

Composer should receive clean device creation plus context

The .codu handoff should create supported structure in Composer and preserve enough context for the installer to program scenes or custom behavior deliberately.

If a keypad behavior needs project-specific programming, it should be treated as a clear review item, not mixed into automatic device creation where it can produce noise or duplicate controls.

Official references checked

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

FAQ

Do KNX keypads count as CoduWorks license devices?

No. The license tier counts lights, blinds, thermostats and KNX/IP gateways. Keypads, push buttons and binary inputs can remain visible as context without raising the tier.

Can a KNX push button trigger Control4 programming?

It can be possible depending on the driver path, DPT, transmit flags and how the signal is represented in Composer. It should be reviewed as trigger intent, not assumed blindly.

Should keypads be generated automatically as Control4 devices?

Not in the core workflow. They are usually better handled as context or project-specific programming items while the core build creates lights, blinds, thermostats and gateways.