Vista previa del flujo Control4 X4 KNX
La vista muestra contexto KNX y una estructura Control4 generada revisandose antes de entregar el paquete .codu al driver Composer con un plan de build visible.
Que cambia X4 y que no cambia
X4 puede afectar a la experiencia visible de Control4, la planificacion de upgrade y los requisitos de controlador/software que debe confirmar el instalador. Esas decisiones pertenecen a la documentacion oficial Control4 y al dealer.
Lo que no desaparece es el problema de mapping KNX. Luces, dimmers, persianas, rutas de gateway, feedback y excepciones no soportadas siguen necesitando interpretacion desde ETS antes de crear dispositivos en Composer.
- La planificacion X4 debe apoyarse en requisitos oficiales Control4 y criterio del dealer.
- El mapping KNX debe apoyarse en ETS: topologia, group addresses, ComObjects y DPTs.
- Composer debe recibir un paquete revisado, no una estimacion cruda desde una hoja.
Preflight ETS antes de un proyecto Control4 X4
Antes de que el driver Composer cree nada, el proyecto ETS debe revisarse por familias: luces, persianas, dimmers, termostatos acotados y gateways IP KNX. La revision tambien debe mostrar keypads, pulsadores, sensores y contexto HVAC mas amplio sin asumir que cada senal forma parte del build core automatico.
Esto importa durante un upgrade o refresh X4, donde el instalador puede tocar Control4 mientras el bus KNX ya existe y no debe reconstruirse a ciegas.
- Confirmar acceso al .knxproj y si el export esta actualizado.
- Comprobar gateway/routing y contexto de lineas.
- Revisar feedback antes de confiar en la experiencia visible X4.
- Identificar dispositivos Composer existentes antes de un run create-only.
Plan de build Composer para proyectos en era X4
El flujo CoduWorks separa la conversacion X4 de la mecanica de build KNX. El AI Assistant importa ETS, prepara una estructura Control4 revisable y exporta .codu para el driver Composer.
El driver Composer debe mostrar un build report antes de crear: luces, persianas, termostatos, gateways IP KNX, items omitidos, avisos de duplicados y candidatos no soportados. Esa pausa es aun mas importante cuando el proyecto se actualiza, se refresca o pasa entre equipos.
Riesgo de upgrade: no mezclar UI upgrade con cleanup KNX
Un upgrade Control4 ya es un evento de planificacion. Mezclarlo con limpieza KNX manual dentro de Composer aumenta el riesgo porque luego cuesta saber si el problema viene del upgrade, del gateway, del mapping o de un dispositivo duplicado.
Trata el import KNX como un artefacto revisado propio. Prepara ETS, revisa mappings, exporta .codu, lee el build report y solo entonces deja que Composer cree la estructura soportada.
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
Control4 X4 resuelve automaticamente el mapping KNX?
No. X4 puede afectar experiencia y requisitos de upgrade, pero el mapping KNX sigue necesitando contexto ETS, revision DPT, gateways y plan de build Composer.
Debo revisar primero requisitos oficiales Control4 X4?
Si. Version, controlador, suscripcion, licencias y disponibilidad regional deben confirmarse con fuentes oficiales Control4/dealer antes de planificar.
CoduWorks ayuda en un proyecto X4 KNX?
CoduWorks ayuda en la parte ETS a Composer: importar .knxproj, revisar contexto KNX, preparar estructura Control4 y exportar .codu para el driver Composer.
Que revisar antes de que Composer cree dispositivos?
Rooms, luces, persianas, termostatos, gateways IP KNX, feedback, DPTs, items no soportados y riesgos de duplicado antes del run create-only.
Prepara KNX antes del build Composer en X4
Importa ETS, revisa la estructura Control4 con contexto KNX y exporta .codu cuando el build report deberia cuadrar con el alcance.