Revision de fuente ETS exportada
La vista de import muestra contexto de proyecto ETS revisado antes del procesamiento con IA. Los exportes parciales pueden apoyar la revision, pero la fuente completa da mejor contexto antes del export Control4.
Que suelen contener los exportes parciales ETS
Un export OPC o ESF es util cuando otra herramienta necesita nombres de direcciones de grupo y estructura de direcciones. Los exportes CSV o XML de direcciones tambien ayudan a auditar naming, compartir listados o revisar familias fuera de ETS.
Eso los hace practicos para diagnostico y referencia. El problema es que un flujo Control4 necesita mas que una lista: necesita entender que direcciones forman juntas una luz, dimmer, persiana o contexto gateway.
- Nombres de direcciones de grupo y niveles de direccion.
- Algo de informacion de datapoint segun tipo de export y version ETS.
- Datos utiles para checks, handover o troubleshooting.
Que se puede perder frente a .knxproj
Un export parcial puede perder topologia, dispositivos, objetos de comunicacion, contexto de aplicacion de fabricante y parte del detalle DPT. Puede valer para consulta rapida, pero es arriesgado como unica fuente para generar estructura Control4 automaticamente.
El AI Assistant razona mejor cuando ve la fuente del proyecto. Nombres, dispositivos, ComObjects, rooms y pistas DPT ayudan a decidir si varias direcciones forman un dispositivo visible o solo contexto de soporte.
- Contexto de room y topologia incompleto.
- Nombres ComObject y relacion con dispositivo fuente ausentes.
- Exportes OPC antiguos pueden no representar todos los DPT modernos limpiamente.
Cuando OPC, ESF o CSV sigue siendo util
Los exportes parciales ayudan cuando un .knxproj protegido no puede procesarse todavia, cuando el instalador quiere comparar nombres de direcciones o cuando soporte necesita una lista rapida antes de tener la fuente ETS completa.
Usalos como evidencia de apoyo y vuelve al flujo .knxproj cuando el objetivo sea generar una estructura Control4 revisable y un paquete .codu para Composer.
Por que Composer no debe recibir una lista a ciegas
Composer necesita un plan de build: rooms, dispositivos, tipos soportados, direcciones de comando, feedbacks, contexto gateway y checks de duplicados. Un export plano puede ocultar los supuestos detras de ese plan.
Antes del export, revisa que familias de direcciones se convierten en dispositivos core, cuales quedan como contexto y cuales necesitan programacion manual en Composer. Asi una lista de direcciones no termina en dispositivos duplicados o incompletos.
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 construir Control4 desde un export OPC o ESF?
Usalo solo como referencia. Para CoduWorks se prefiere .knxproj porque puede traer mas contexto de topologia, dispositivos y ComObjects.
CSV basta para mapear direcciones de grupo?
Puede ayudar a auditar nombres y direcciones, pero puede no mostrar como direcciones, DPTs, feedback y dispositivos fuente pertenecen juntos.
Cuando uso OPC, ESF o CSV?
Para consulta, diagnostico o comparacion. Usa un .knxproj procesable para preparar un .codu revisable para Composer.
Que pasa si mi .knxproj esta protegido?
Resuelve primero el acceso ETS o el alcance KNX Secure. Un export parcial puede ayudar a hablar del proyecto, pero no debe sustituir la fuente sin visibilidad.
Usa exportes parciales como checks, no como fuente final
Importa .knxproj cuando sea posible, compara referencias OPC/ESF/CSV si ayudan y exporta .codu solo tras revisar la estructura Control4.