Vista previa de search y GA lookup KNX
La vista muestra busqueda, replace y lookup de Group Addresses KNX desde la vista Control4 generada, manteniendo visible el contexto fuente antes del export.
Por que buscar antes de Composer
Composer puede buscar drivers y tiene Find and Replace para referencias de programacion, pero una revision de import KNX tiene otro problema: el instalador necesita conectar un candidato Control4 con sus direcciones ETS, DPTs y ComObjects.
Esa busqueda debe ocurrir antes del build. Encontrar un feedback incorrecto o un patron de naming despues de crear dispositivos en Composer convierte una revision en limpieza dentro del proyecto vivo.
- Encontrar un dispositivo generado por nombre, room, linea, subtipo o patron de direccion.
- Mantener visible el contexto de group address y ComObject mientras se revisa.
- Detectar patrones repetidos de naming o mapping antes de exportar el .codu.
Que debe encontrar el lookup
Un GA lookup util no es solo un filtro de texto. Debe ayudar al instalador a entender por que se creo un candidato de luz, persiana o gateway Control4 y que objetos KNX hay detras.
La revision debe mostrar direcciones de comando, direcciones de feedback, pistas DPT, nombres de ComObjects, nombres de dispositivos, room y linea para confirmar la estructura antes de entregar el paquete a Composer.
- Valores y labels de Group Address desde la fuente ETS.
- ComObjects conectados al candidato Control4 generado.
- DPT y funcion para separar comando, estado, nivel, stop y posicion.
- Rooms, lineas y convenciones repetidas de naming que pueden necesitar limpieza.
Search and replace con frontera clara
Search and replace sirve para limpieza repetida de naming, convenciones de rooms o labels consistentes. No debe usarse para ocultar incertidumbre de mapping.
Si un DPT no esta claro, falta feedback o una familia de dispositivos esta fuera del scope soportado, ese item debe seguir visible para revision tecnica en vez de renombrarse como si estuviera terminado.
No es lo mismo que la busqueda de drivers en Composer
La busqueda de Control4 Composer sirve para encontrar y anadir drivers. La vista de busqueda de CoduWorks es distinta: busca dentro del proyecto derivado de KNX antes de que el driver Composer lo construya.
Esto permite responder antes preguntas del proyecto: que direccion mueve esta luz, donde esta el feedback, que DPT se ha inferido y por que el AI Assistant puso el dispositivo en esta room.
Revision antes del export .codu
La entrega final no debe ser una lista suelta de direcciones. Debe ser un paquete de build revisado donde resultados de busqueda, reemplazos y decisiones de mapping ya se han comprobado.
Asi Composer recibe un paquete create-only mas limpio y el instalador tiene una pausa clara antes de que el driver cree dispositivos.
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
CoduWorks puede buscar group addresses KNX desde la vista Control4?
Si. La vista de revision esta pensada para buscar dispositivos Control4 generados manteniendo visibles group addresses, ComObjects y contexto DPT.
Es lo mismo que Search de Composer?
No. Search de Composer ayuda a encontrar drivers e items dentro de Composer. CoduWorks busca la estructura derivada de KNX antes del export .codu.
Search and replace arregla mappings?
Puede limpiar patrones repetidos de naming o estructura, pero problemas como feedback ausente, DPT incorrecto o scope no soportado siguen necesitando revision tecnica.
Por que no usar una hoja ETS?
Una hoja puede listar direcciones, pero no mantiene juntos el candidato Control4, room, ComObjects y estado de revision dentro del mismo flujo.
Busca el proyecto antes de Composer
Importa ETS, encuentra GAs y ComObjects desde la vista Control4 revisable y exporta .codu solo cuando el contexto de mapping este claro.
