Filter-table visibility/Updated May 2026

KNX dummy devices can make Control4-visible traffic explicit

Name: Dummy-device and filter-table review preview
Uploaded: 2026-05-20
Description: The preview shows KNX source context and generated Control4 candidates side by side so feedback visibility and gateway assumptions can be reviewed before export.

In multi-line KNX projects, a group address can exist and still not reach Control4. A dummy device or manual filter-table decision in ETS can be the difference between a clean Control4 handoff and a build where feedback appears missing.

Identify which command and feedback group addresses must be visible to the Control4 route.
Separate ETS dummy-device decisions from .codu generation and Composer device creation.
Review topology before treating missing feedback as a mapping problem.

Open AI Assistant View product

Dummy-device and filter-table review preview

The preview shows KNX source context and generated Control4 candidates side by side so feedback visibility and gateway assumptions can be reviewed before export.

Why dummy devices exist in KNX projects

ETS uses device and group-object relationships to calculate which group telegrams should cross couplers. When a visualization, gateway or external controller needs to see group addresses from another line, ETS may need an explicit representation of that requirement.

A dummy device is one common way to make those requirements visible to filter-table calculation. It is an ETS infrastructure decision, not a Control4 device that should be created in Composer.

Why this matters before a Control4 build

Control4 can only stay synchronized when command and feedback traffic reaches the KNX/IP path used by the driver. If feedback is filtered by topology, the generated Control4 device can look wrong even when the group address and DPT are correct.

That is why the review stage should expose routing assumptions before the .codu package is handed to Composer.

Feedback groups from lines outside the gateway segment.
Visualization-style traffic required by the Control4 KNX/IP route.
Multi-line projects where filter tables are more important than names.

What CoduWorks can and cannot do

CoduWorks does not add dummy devices to ETS or program couplers. The installer remains responsible for ETS topology, filter tables and gateway commissioning.

The platform helps by keeping KNX context, generated Control4 devices, feedback objects and route assumptions visible together, so the installer knows what to check before exporting .codu.

Composer should not discover this first

If dummy-device or filter-table assumptions are unresolved, Composer is the wrong place to find out. The build report can create devices, but it cannot prove that every routed telegram will be visible on site.

A good handoff keeps the Control4 structure reviewed and keeps infrastructure questions separate from device generation.

Official references checked

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

FAQ

Does CoduWorks create KNX dummy devices in ETS?

No. Dummy devices, manual filter-table entries and coupler programming remain ETS and installer work.

When might a dummy device matter for Control4?

It can matter when Control4 needs to see group addresses across line or area boundaries and ETS filter tables would otherwise not pass those telegrams.

Is a dummy device counted in CoduWorks pricing?

No. Pricing is based on lights, blinds, thermostats and KNX IP gateways in the counted scope. Dummy devices are ETS infrastructure context, not generated Control4 devices.