Por que aparecen duplicados en proyectos KNX a Control4
Habitaciones y dispositivos duplicados aparecen cuando el proceso no puede emparejar con confianza la estructura Control4 deseada. Nombres parecidos, dispositivos de prueba antiguos, etiquetas ETS inconsistentes e imports manuales repetidos aumentan el riesgo.
Composer es potente, pero no es el mejor sitio para limpiar en masa despues de un mal import. Una vez creados los duplicados, el integrador debe revisar bindings, referencias de programacion y UI antes de borrar nada.
Revisar antes del build, no despues
El flujo mas seguro es importar, procesar con IA, revisar manualmente, exportar .codu y construir en Composer. El build deberia recibir una estructura revisada con habitaciones, nombres, tipos soportados y contexto de gateway claros.
Asi las correcciones se hacen en la plataforma, donde bulk edit, busqueda, rollback y contexto KNX son mas comodos. Composer queda como entorno de creacion, no de limpieza.
Usar un plan visible antes de crear nada
Un build report da al instalador una pausa antes de crear. Debe dejar claro que habitaciones y dispositivos se crearan, que parece duplicado y que necesita atencion.
Un run create-only es mas facil de razonar que un flujo que edita dispositivos existentes en silencio. En las primeras versiones de una herramienta de build, evitar cambios destructivos importa mas que ser demasiado automatico.
- Revisar rutas y nombres de habitaciones antes de crear.
- Revisar tipo de dispositivo y contexto KNX de origen.
- Revisar warnings antes de ejecutar el build.
Usar reglas de nombres que sobrevivan a exports repetidos
La estabilidad de nombres es la base para evitar duplicados. Si un instalador cambia nombres de forma distinta en ETS, plataforma y Composer, los futuros imports seran mas dificiles de emparejar.
Un flujo revisable debe permitir normalizar nombres Control4 manteniendo visible la fuente KNX. Asi el nombre de usuario queda limpio sin perder trazabilidad.
Cuando el proyecto Composer ya existe
Los proyectos existentes requieren mas cuidado. Antes de ejecutar un nuevo build, compara la estructura propuesta con lo que ya existe en Composer. Nombres parecidos deberian ser items de revision, no creaciones automaticas.
El primer objetivo es crear estructura nueva sin tocar trabajo existente. Cuando el instalador confia en el plan, los flujos de update se pueden plantear aparte.
Referencias externas
Estas referencias se incluyen como contexto; la guia de flujo se basa en la implementacion de CoduWorks y revision real de integraciones.
Preguntas frecuentes
El driver puede borrar o renombrar dispositivos existentes en Composer?
El valor por defecto mas seguro es create-only: construir el paquete revisado sin cambios destructivos. Los dispositivos existentes no deberian modificarse salvo que el instalador ejecute un update controlado.
Que papel tiene el archivo .codu?
El .codu es el handoff cerrado de la plataforma al driver Composer. Debe llevar estructura revisada, contexto de dispositivos y datos del plan de build.
Como reduzco riesgo de duplicados antes de exportar?
Normaliza habitaciones, nombres, tipos soportados, contexto de gateway y avisos de duplicados en la plataforma antes de importar en Composer.
KNX -> Control4
Exporta un .codu revisado antes de abrir Composer
Usa el AI Assistant para limpiar nombres, revisar avisos de duplicados y entregar al driver Composer un paquete con plan de build visible.