Vista previa de importacion KNX generica
La vista muestra un proyecto KNX importado desde ETS, revisado en la vista KNX y procesado hacia una estructura Control4 antes del export a Composer.
Por que un wizard puede mostrar cero rooms o dispositivos
Algunas rutas de importacion estan pensadas para datos de dispositivos KNX Control4 conocidos o supuestos de proyecto muy concretos. En un ETS generico, la informacion util puede estar en nombres, direcciones de grupo, ComObjects, DPTs y topologia, no en registros especificos de Control4.
Por eso un wizard puede encontrar el archivo pero terminar mostrando cero floors, rooms o dispositivos. El sintoma suele ser una diferencia entre lo que espera el import y como se comisiono realmente el proyecto KNX.
Cuando pasa eso, un import de un paso puede dar un resultado vacio o incompleto aunque el ETS contenga informacion suficiente para construir una estructura Control4 util.
Puede que el proyecto no tenga dispositivos ETS especificos de Control4
Una instalacion KNX normal puede tener luces, persianas, actuadores, sensores, keypads y contexto gateway utiles sin contener dispositivos Control4 dentro de ETS.
CoduWorks lo trata como un problema de parsing de proyecto, no como un callejon sin salida. El AI Assistant lee el contexto KNX amplio y prepara una estructura Control4 revisable antes de entregar .codu a Composer.
Que extrae CoduWorks de un ETS estandar
El AI Assistant trata el .knxproj como fuente de contexto KNX. Revisa rooms, lineas, dispositivos, direcciones de grupo, ComObjects, DPTs y patrones de naming para proponer estancias y dispositivos Control4.
La idea no es convertir cada objeto KNX en un dispositivo Control4 final. La idea es crear una estructura que el instalador pueda revisar antes de construir en Composer.
- Luces, dimmers, persianas y contexto de gateway KNX/IP para el build core.
- Direcciones de comando y feedback vinculadas a dispositivos generados.
- Objetos ambiguos o no soportados visibles para revision, no escondidos.
La revision va antes de crear en Composer
Un ETS generico puede traer naming inconsistente, feedback ausente, DPTs que no coinciden y supuestos de topologia. Todo eso debe revisarse antes de que un driver cree rooms y dispositivos en Composer.
CoduWorks exporta .codu despues de revisar la estructura generada, para que el driver de Composer reciba un plan de build cerrado y no notas sueltas.
Esto no es comisionado ETS
CoduWorks no comisiona dispositivos KNX, no configura flags ETS y no cambia filter tables de acopladores. ETS sigue siendo la herramienta fuente e infraestructura.
La plataforma se centra en el puente que falta entre un proyecto KNX terminado y un build Control4 limpio: parsing, revision, contexto de mapeo y handoff a Composer.
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
Puedo importar un KNX sin dispositivos Control4 en ETS?
Si. El flujo parte del .knxproj y genera una estructura Control4 revisable desde contexto KNX, no solo desde dispositivos Control4 especificos en ETS.
Por que el wizard Control4 ETS import no muestra rooms o dispositivos?
A menudo porque el ETS usa dispositivos KNX estandar y naming propio, no los registros o supuestos especificos de Control4 que espera esa ruta de importacion.
Cada dispositivo KNX se convierte en dispositivo Control4?
No. El build automatico core se centra en luces, dimmers, persianas, termostatos acotados y contexto de gateway KNX/IP. Keypads, sensores y objetos no soportados quedan como contexto o revision.
Sustituye esto a las herramientas oficiales de Control4?
No. Es un flujo separado con revision previa para preparar un paquete .codu para el driver CoduWorks en Composer. Usa herramientas oficiales cuando encajen con tu proyecto.
Importa el KNX real y revisa el build Control4
Sube el .knxproj, deja que el AI Assistant prepare la estructura Control4, revisa mapeos y exporta .codu para Composer.