Vista previa de gateway KNX y ruta Control4
La vista del proyecto muestra rooms Control4 generadas, dispositivos y contexto de infraestructura KNX. Gateway, routing y feedback se revisan antes de exportar el .codu.
Gateway, interface y router no son la misma decision
Una interface IP KNX suele asociarse a comportamiento tunneling. Un router IP KNX puede rutear telegramas entre IP y lineas KNX. Una ruta Control4 Routing Gateway depende de telegramas ruteados y visibilidad multicast.
Estos terminos se mezclan mucho en presupuestos y foros. En un proyecto real, topologia ETS, hardware gateway y driver Control4 deciden que telegramas seran visibles antes de que Composer cree dispositivos.
- Rutas tipo interface pueden servir en proyectos pequenos o legacy, pero pueden tener limites de conexion o throughput.
- Routing Gateway depende de routing KNX/IP, multicast visible y filter tables correctas.
- El AI Assistant muestra el supuesto; el instalador sigue configurando ETS y la red.
La eleccion del driver Control4 depende de la ruta
Las busquedas Control4 KNX suelen mencionar KNX Network, KNX Routing Gateway, IP gateway y router IP en el mismo hilo. Eso debe tratarse como preflight de ruta, no solo como pregunta de nombre de driver.
CoduWorks puede mantener el contexto gateway junto a la estructura Control4 generada para que el instalador vea que rooms, luces, persianas y feedbacks dependen de la ruta KNX/IP elegida.
- KNX Network: normalmente ligado a tunneling o comportamiento de interface.
- KNX Routing Gateway: normalmente ligado a multicast routing y routers KNX/IP.
- Build Composer: debe recibir un .codu revisado cuando la ruta ya este clara.
Filter tables y feedback deciden si el gateway sirve
Un gateway puede existir y aun asi no dejar pasar las direcciones que necesita Control4. Feedback ausente, niveles congelados o control en un solo sentido pueden venir de filter tables, limites de linea, visibilidad multicast o DPTs incorrectos.
La revision debe mostrar comandos, feedbacks, DPTs y contexto de linea antes de entregar el .codu a Composer.
- Direcciones de comando y feedback requeridas por los dispositivos Control4 generados.
- Rangos de main group y comportamiento de filtros en acopladores o routers.
- Supuestos de gateway o router que afectan status reads y retorno de feedback.
El contexto gateway pertenece al handoff revisable
El export .codu no debe ser una lista suelta de dispositivos. Debe llevar una estructura revisada y suficiente contexto KNX para que el driver Composer muestre un build report comprensible.
Por eso los gateways KNX/IP cuentan dentro del alcance core, mientras keypads, pulsadores y la mayoria de sensores quedan como contexto salvo que el proyecto defina un add-on o scope manual.
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
Un gateway IP KNX es lo mismo que un router IP KNX?
No siempre. En obra se mezclan los terminos, pero una interface tunneling, una ruta gateway y un router/routing IP tienen supuestos de comunicacion distintos.
Control4 debe usar KNX Network o Routing Gateway?
Depende de la topologia ETS, hardware y red reales. Routing Gateway suele ser preferible cuando hay routing KNX/IP y multicast disponible, pero la ruta debe revisarse antes del build Composer.
Por que ETS funciona pero Control4 no ve estado KNX?
ETS puede estar usando otra ruta o el feedback puede estar filtrado, no ruteado por multicast, mapeado con DPT incorrecto o bloqueado por una filter table.
CoduWorks configura el gateway?
No. La configuracion del gateway, topologia ETS y red siguen siendo responsabilidad del instalador. CoduWorks hace visible el contexto antes del export .codu y build Composer.
Valida la ruta KNX/IP antes de Composer
Importa ETS, revisa gateway, comandos y feedback, y exporta .codu solo cuando el plan de build Control4 este claro.