Vista previa routing multicast KNX
La vista muestra fuente KNX y candidatos Control4 en paralelo para comprobar routing, feedback y supuestos gateway antes del export.
Multicast routing no es lo mismo que mapeo
El AI Assistant puede revisar objetos ETS, DPTs, nombres y dispositivos Control4 generados. No configura la red ni sustituye el commissioning del gateway.
Esa frontera importa porque una luz, dimmer o persiana puede estar bien mapeada mientras el telegrama de feedback queda filtrado, bloqueado por topologia o no llega al controlador Control4 por la ruta KNX/IP elegida.
Que revisar antes de culpar a Composer
Antes de reconstruir dispositivos, revisa la ruta KNX/IP. El instalador debe saber si el gateway es realmente un dispositivo routing, si el multicast es visible en la red, si los acopladores dejan pasar las direcciones necesarias y si los feedbacks vuelven por la misma ruta.
Esto es especialmente importante con varias lineas KNX, VLANs, routers IP o escenas grandes que generan rafagas de telegramas.
- Router KNX/IP o routing gateway, no solo una interface generica.
- Visibilidad multicast entre controlador, router y segmentos de red relevantes.
- Comportamiento de filter tables para direcciones de comando y feedback.
VLANs y routers pueden ocultar trafico KNX valido
El trafico multicast KNX puede depender mucho de la segmentacion de red. Un proyecto puede probar bien en una subnet y fallar cuando controlador Control4, router y dispositivo KNX/IP quedan separados por politicas VLAN o filtros multicast.
CoduWorks debe conservar contexto de gateway en la revision para que el instalador distinga un problema de ruta de red de un DPT ausente o una familia de direcciones equivocada.
El feedback prueba la ruta
Una ruta de comando en un solo sentido no basta. Control4 necesita estado fiable para mantener sincronizadas luces, dimmers y persianas. Si el comando funciona pero el feedback no, revisa direccion de feedback, DPT, read flags y filter table antes de cambiar el dispositivo generado.
Un build plan visible es mas util cuando incluye esos supuestos de ruta antes de que Composer cree la estructura final.
Que debe llevar el handoff .codu
El .codu no es un archivo de configuracion de red. Es el paquete Control4 revisado. Aun asi debe mantener suficiente contexto KNX visible para saber que comandos, feedbacks y supuestos de gateway deben funcionar en sitio.
Fuentes oficiales revisadas
Los claims tecnicos de esta pagina se mantienen cerca de documentacion oficial KNX, Control4 o del fabricante.
Herramientas y documentacion relacionadas
Preguntas frecuentes
CoduWorks configura multicast routing KNX?
No. ETS, el router KNX/IP y la red los configura el instalador. CoduWorks ayuda a revisar el contexto del proyecto antes del build Composer.
Por que un dispositivo KNX Control4 funciona solo en un sentido?
Puede pasar el comando pero no el feedback, o el feedback puede estar filtrado, ausente, con DPT incorrecto o bloqueado por la ruta KNX/IP.
Debo revisar multicast antes de exportar .codu?
El .codu puede prepararse desde ETS, pero el instalador debe revisar supuestos de routing y feedbacks requeridos antes de ejecutar el build Composer.
Los IP gateways cuentan en pricing?
Si. Los gateways IP KNX cuentan junto a luces, persianas y termostatos en los tiers. Keypads, pulsadores y sensores no suben el tier.
Comprueba la ruta KNX/IP antes de crear
Importa ETS, revisa comandos, feedback y contexto gateway, y exporta .codu cuando el build Control4 este preparado.