Flujo de lista de drivers Control4 KNX
La vista muestra contexto KNX revisado antes del build Control4. Las categorias de drivers se cruzan con estancias, dispositivos y el paquete para Composer.
Empieza por la capa de red
Antes de elegir drivers de dispositivo, el proyecto necesita una capa de conexion KNX fiable. En Control4 esto suele significar entender si se usa KNX Network, KNX Routing Gateway u otro contexto de gateway.
Esa decision afecta a visibilidad, routing, multicast y feedback hacia Composer. Conviene revisarla antes de crear dispositivos.
- Confirma contexto de gateway IP KNX o routing gateway.
- Revisa acopladores, filter tables y posibles dummy devices si hay varias lineas.
- No trates el gateway como dispositivo de estancia, pero mantenlo visible en el plan de build.
Las familias de drivers no son iguales
Una lista de drivers puede incluir actuadores switch, dimmers, persianas, termostatos, detectores de movimiento, interfaces universales, gateways DALI, valvulas y otras categorias KNX. No todas esas categorias tienen el mismo comportamiento de build automatico.
CoduWorks centra el build core en luces, dimmers, persianas, termostatos acotados y gateways KNX/IP. El resto queda visible como contexto o pasa a revision add-on cuando requiere decisiones concretas por proyecto.
- Luces y dimmers necesitan revision de comando y feedback.
- Persianas necesitan movimiento, stop, posicion y estado cuando exista.
- Termostatos, HVAC, RGB, DALI y sensores requieren revision separada antes de prometer build.
Lee la lista contra el archivo ETS
La categoria de driver no basta. Nombres ETS, ComObjects, DPTs, estructura de direcciones y contexto de estancia deciden si un dispositivo Control4 puede generarse limpio.
Por ejemplo, un dimmer necesita mas que una etiqueta que diga dimmer. La revision debe confirmar comando, nivel, feedback de nivel y cualquier supuesto de dimming relativo antes del export.
Convierte la lista en un plan para Composer
La salida util no es una lista estatica. Es un paquete .codu revisado donde el instalador ve que se creara, que queda como contexto y que debe tratarse manualmente o como add-on.
Asi Composer queda como entorno de build mientras la interpretacion de la lista de drivers ocurre antes, con contexto KNX visible.
Evita crear un driver por cada objeto KNX
Muchos proyectos KNX contienen keypads, contactos, sensores, gateways y objetos de servicio que deben informar el build sin convertirse en dispositivos visibles Control4. Crearlo todo genera ruido y hace menos confiable la UI final.
Un mejor flujo usa la lista de drivers para acotar decisiones: generar dispositivos soportados, mantener contexto util visible y marcar categorias inciertas para revision.
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
Donde esta la lista oficial de drivers Control4 KNX?
Control4 referencia documentacion KNX y recursos de knowledgebase para dealers. El paso practico es comparar esas categorias con el archivo ETS antes de crear dispositivos en Composer.
CoduWorks replica toda la lista de drivers Control4 KNX?
No. CoduWorks usa el proyecto ETS para preparar una estructura Control4 revisable. El build automatico core se centra en luces, dimmers, persianas, termostatos acotados y gateways KNX/IP; otras categorias quedan como contexto o add-ons.
Cada categoria KNX debe convertirse en un dispositivo Control4?
No. Algunas categorias son infraestructura, contexto o senales de programacion. Deben seguir visibles para revision en vez de generarse a ciegas como dispositivos de usuario.
Usa la lista de drivers como checklist de revision
Sube el proyecto ETS, revisa que categorias KNX pueden convertirse en dispositivos Control4 y exporta un paquete Composer mas limpio.