Vista previa de limpieza de nombres KNX
La vista muestra herramientas de busqueda, revision y limpieza usadas antes de exportar un proyecto KNX a un paquete listo para Composer.
Por que importan los nombres antes de Composer
Composer necesita un arbol de dispositivos legible para el usuario. ETS suele tener etiquetas tecnicas, abreviaturas, idiomas mezclados o referencias de estancia inconsistentes. Si esos nombres pasan sin revision, el proyecto Control4 resulta menos fiable.
El AI Assistant puede inferir patrones, pero el instalador debe confirmar cuando una familia de direcciones representa una luz, dimmer, persiana, gateway o solo contexto de programacion.
Patrones de nombre que ayudan a revisar
No existe una unica estructura KNX universal. Las estructuras por funcion, estancia o dispositivo pueden funcionar si son consistentes y se explican por si mismas.
Para el handoff a Control4, lo mas util es que el dispositivo real, la estancia y el rol de la senal sean visibles sin abrir manualmente cada canal de actuador.
- Etiqueta de room o area que coincida con la estancia Control4 esperada.
- Funcion como luz, dimmer, persiana, shade, estado, escena o gateway.
- Rol de senal como comando, feedback, valor, stop, posicion o lama.
Que dificulta la agrupacion automatica
Las convenciones mezcladas dificultan saber si un punto es un dispositivo visible o solo una senal auxiliar. Por ejemplo, un dimmer puede tener switch, dimming relativo, nivel absoluto y feedback con nombres distintos.
Un nombre ambiguo no significa que el proyecto no pueda procesarse. Significa que el instalador debe revisar la vista Control4 generada, editar nombres en bloque y dejar objetos inciertos fuera del build automatico hasta confirmarlos.
- La misma estancia escrita de varias formas dentro de ETS.
- Comandos y feedbacks nombrados como dispositivos no relacionados.
- Objetos de escena, central, lock o diagnostico nombrados como luces normales.
Limpia antes del export .codu
CoduWorks da al instalador un lugar para corregir nombres generados, traducir etiquetas, buscar patrones repetidos y editar estructura en bloque antes de que el driver Composer cree nada.
Esa es la diferencia practica entre un flujo review-first y un import directo. Los nombres se mejoran con la fuente KNX visible, no despues de construir el arbol Control4.
Que debe recibir Composer
Composer debe recibir un paquete .codu revisado con rooms, dispositivos, subtipos y contexto de mapeo legibles. El objetivo no es obligar ETS a una unica norma, sino hacer entendible la estructura Control4 antes de crear.
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
Tengo que renombrar mi proyecto ETS antes de usar CoduWorks?
No necesariamente. Una nomenclatura clara ayuda, pero el AI Assistant permite revisar y limpiar la estructura Control4 generada antes del export.
Que estructura de direcciones KNX es mejor para Control4?
La mejor estructura es consistente y autoexplicativa. Puede ser por estancia, funcion o dispositivo si comando, feedback e intencion quedan claros.
La edicion masiva corrige problemas repetidos de nombres?
Si. Etiquetas repetidas, nombres de rooms, limpieza de idioma y subtipos pueden corregirse antes de exportar el .codu a Composer.
Una mala nomenclatura puede crear dispositivos Control4 incorrectos?
Puede crear ambiguedad. Por eso mapeos, nombres, DPTs y feedback deben revisarse antes de la creacion automatica.
Revisa nombres antes del build Composer
Importa ETS, inspecciona nombres y mapeos generados, limpia patrones repetidos y exporta un .codu revisado.