Topology and individual address review
The preview keeps KNX source context and Control4 candidates visible together so topology, Routing Gateway assumptions, command groups and feedback can be checked before export.
Individual address is part of the route
In KNX, physical or individual addresses are not just labels. They place devices in topology and can affect how routers, interfaces and tunneling servers relate to a line or area.
For Control4, this matters because a controller using a Routing Gateway path is not the same as an older interface-style connection. The route assumption should be reviewed before generated devices are built.
- KNX/IP router or interface physical address in ETS.
- Tunneling server addresses when the path uses interface behavior.
- Control4 Routing Gateway assumptions when the controller acts through routed KNX/IP traffic.
Router .0 and topology checks are not Composer edits
Many KNX/IP routers use the line or area .0 address pattern for routing or coupler behavior. If topology and router role are misunderstood, telegrams may appear in ETS from one access point while Control4 still misses them on its route.
CoduWorks should not rewrite physical addresses. The useful step is to surface topology, gateway and feedback context so the installer knows what must be checked in ETS and on the network.
- Router role and line placement.
- Whether ETS access and Control4 access observe the same traffic.
- Which feedback groups must cross routers or line couplers.
How address problems look inside Control4
Address and topology mistakes often look like mapping problems: command works without feedback, only one line fails, status reads hang, or a Routing Gateway seems connected but devices stay stale.
Before rebuilding devices in Composer, review the KNX route and topology evidence next to the generated Control4 structure.
- Compare the ETS topology view with the intended Control4 gateway path.
- Check whether the missing telegram is command, feedback, status read or a routed multicast issue.
- Confirm that filter tables and line couplers are part of the diagnosis before remapping devices.
What belongs in the .codu review
The .codu package should carry enough context to make the build report understandable: generated devices, gateway path assumptions, required command and feedback groups and unresolved topology warnings.
The Composer driver can then build from a reviewed package instead of forcing topology decisions inside Composer.
- Generated lights, blinds, thermostats and KNX/IP gateways.
- Gateway route and feedback assumptions that still need installer confirmation.
- Warnings that should be solved before the driver creates devices.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Does CoduWorks assign KNX individual addresses?
No. ETS and the KNX installer remain responsible for physical or individual address configuration. CoduWorks exposes topology context so the Control4 build is reviewed before Composer creates devices.
Why can ETS see telegrams but Control4 cannot?
ETS may be connected through a different access point or line than the Control4 controller. Filter tables, multicast visibility, tunneling addresses or Routing Gateway assumptions can change what each side sees.
Does Routing Gateway need a KNX individual address?
Routing Gateway style setups involve a KNX/IP routing assumption and controller placement in topology. The exact address model depends on project, hardware and Control4 configuration, so it should be checked in ETS and the vendor documentation.
Should topology be reviewed before .codu export?
Yes. The .codu file should be exported after the installer understands the route assumption, feedback path and any topology warnings that affect the Composer build.
Review KNX topology before Composer
Import ETS, keep individual address, router and feedback context visible, and export .codu only after the Control4 structure is reviewable.