Routing gateway review preview
The preview shows KNX source context and Control4 device candidates side by side so gateway path, command groups and feedback assumptions can be checked before export.
Routing Gateway and KNX Network are different decisions
A Control4 project can behave very differently depending on whether the KNX path is built around a routing gateway, a network driver, tunneling behavior or another KNX/IP device. The driver name is only part of the answer; the ETS topology and gateway settings decide which telegrams are visible.
For a reviewable build, the installer needs to see the KNX/IP assumption before Composer creates devices. Otherwise a mapping can look wrong when the real issue is the gateway path.
Why KNX Network driver searches still matter
Older Control4 KNX projects and forum threads often mention the KNX Network driver, tunneling paths or generic KNX/IP interfaces. Newer recommendations often point installers toward KNX Routing Gateway where multicast routing is available, but the right conclusion still depends on the real ETS topology and hardware.
CoduWorks should not guess this from the driver name alone. The ETS review should expose gateway context, line boundaries and the group addresses that must pass before the Composer driver creates devices.
- Tunneling or interface-style paths can be more sensitive to connection limits and request bursts.
- Routing gateway paths still depend on multicast visibility and correct filter-table behavior.
- The .codu export should happen after the route assumption is reviewed, not before.
Filter tables can make valid addresses invisible
A group address can exist in ETS and still fail to arrive at Control4 if the router or line coupler filter table does not pass the telegram. This shows up as missing feedback, stale state, devices that only work one way or scenes that overload the bus.
The safe workflow is to review required command and feedback groups before export, then confirm that the infrastructure will pass those telegrams through the chosen KNX/IP route.
- Command group addresses needed by generated Control4 devices.
- Feedback group addresses needed for reliable state in Control4.
- Main group ranges and line boundaries that may be filtered by ETS topology.
Request status delay is not a mapping fix
Changing delay values may reduce traffic pressure in some projects, but it does not fix a missing status object, a blocked feedback address or the wrong DPT. Treat timing changes as a later tuning step, not the first diagnostic move.
Before touching delays, confirm that each generated device has the expected command, feedback and DPT context visible from the ETS project.
Review the route before the build plan
The .codu workflow should carry more than room names and device labels. It should preserve enough gateway and mapping context for the installer to understand why Composer is about to create a specific Control4 device.
That is especially important in larger KNX projects where many keypads, sensors, couplers and gateways exist but only lights, blinds, thermostats and KNX/IP gateways count toward the device scope.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Should I use KNX Routing Gateway or KNX Network in Control4?
Routing Gateway is commonly preferred where the installation supports multicast routing, while older KNX Network paths may appear in existing projects. Review the actual gateway, topology and filter tables before the Composer build.
Is the KNX Network driver the same as the Routing Gateway driver?
No. They represent different KNX/IP assumptions. A KNX Network style setup is usually associated with tunneling or interface behavior, while Routing Gateway depends on routed telegrams and multicast visibility.
Why does Control4 miss KNX feedback even when the address exists?
The feedback may be blocked by filter tables, mapped to the wrong DPT, absent from the device object set or not routed back through the KNX/IP path used by Control4.
Can the AI Assistant configure KNX multicast or filter tables?
No. It is a review and build-preparation layer. ETS and the KNX network must still be configured correctly by the installer.
Review the KNX routing path before Composer
Import the ETS project, keep gateway and feedback context visible, and export a .codu file only after the Control4 structure is reviewable.