Line coupler filter-table review preview
The preview shows KNX source data beside generated Control4 devices so addresses, feedbacks and routing assumptions can be checked before export.
Filter tables decide what crosses KNX lines
ETS can calculate which group addresses should pass through a line coupler or router based on the devices and group objects used on each line. A group address existing in ETS is not enough; the telegram still has to be allowed across the coupler and toward the KNX/IP route used by Control4.
That distinction matters when the project has several KNX lines, areas or routers. The Control4 device can be generated correctly, but the telegram may never reach the driver path if the route is filtered.
Why Control4 can look wrong when ETS is right
Missing feedback, stale state, one-way devices and unreliable scenes are often diagnosed too late inside Composer. The source mapping may be fine while the routed visibility is not.
A reviewable workflow should expose the group address, DPT, command intent, feedback intent and route assumption together so the installer can separate mapping mistakes from line-coupler behavior.
- Feedback group addresses that must cross a line boundary.
- Command groups that work locally but not through the Control4 KNX/IP path.
- Multi-line projects where topology is more important than the device label.
Dummy devices and pass-through are ETS decisions
Dummy devices, manual filter-table additions and pass-through modes belong to ETS and KNX infrastructure work. CoduWorks does not configure couplers or filter tables automatically.
What the AI Assistant can do is keep the relevant topology and mapping context visible before export, so the installer knows which addresses and feedbacks need to be checked in ETS before the Composer build is trusted.
Composer should receive a reviewed route
The .codu package should not hide unresolved topology assumptions. When a build reaches Composer, the installer should already know whether the selected KNX/IP path is expected to see the required command and feedback traffic.
That keeps the Composer driver focused on creating the reviewed Control4 structure instead of becoming the first place where filter-table issues are discovered.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can CoduWorks configure KNX line coupler filter tables?
No. Filter tables, dummy devices and coupler behavior are ETS and infrastructure tasks. CoduWorks helps expose the context that should be reviewed before Control4 is built.
Why does feedback fail if the group address exists?
The address may exist in ETS but the telegram can still be blocked by a line coupler filter table, routed through the wrong path or missing from the KNX/IP route used by Control4.
Is this only relevant for large KNX projects?
It is most common in multi-line or segmented projects, but any project with missing feedback should review gateway path, topology and filter visibility before recreating devices in Composer.
Check filter-table context before the Control4 build
Import ETS, review the KNX line and feedback context, then export a .codu package only when the route assumptions are clear.