Vista previa del editor de driver Control4
La vista muestra dispositivos Control4 revisados y editados con contexto KNX antes de exportar el paquete de build a Composer.
DriverEditor frente a editor de proyecto
El DriverEditor oficial de Control4 y DriverWorks sirven para crear o modificar drivers. Un editor KNX a Control4 tiene un objetivo mas concreto: limpiar rooms, dispositivos, naming y contexto de mapping antes de ejecutar el driver existente en Composer.
La diferencia importa. No deberias tener que escribir Lua, crear un driver IR o modificar un driver Control4 para revisar cientos de luces y persianas derivadas de KNX antes de crearlas.
- Intencion DriverEditor: desarrollar o modificar drivers.
- Intencion DriverWorks: Lua, comportamiento de proxy, XML y packaging de driver.
- Intencion CoduWorks: revisar estructura Control4 derivada de KNX.
- Intencion Composer: ejecutar el build final desde el paquete .codu.
Cuando el DriverEditor oficial si es la respuesta
Usa Control4 DriverEditor, Driver Wizard o DriverWorks SDK cuando el trabajo sea crear un nuevo driver, editar XML, escribir comportamiento Lua, empaquetar un .c4z/.c4i o trabajar contra la base oficial de drivers Control4.
Eso es distinto de un import KNX. Si el driver ya existe y el problema son rooms, nombres, luces, persianas, termostatos, gateways, direcciones de grupo o contexto DPT, el trabajo pertenece a la capa de revision antes del export .codu.
- Ruta driver oficial: DriverEditor, DriverWorks SDK, Lua, XML, proxies y archivos .c4z/.c4i.
- Ruta CoduWorks: import .knxproj, procesamiento IA, revision, bulk edits, export .codu y build report Composer.
- Decision del instalador: no abrir un flujo de desarrollo de driver solo para limpiar un arbol KNX generado.
Para que sirve el editor
El editor no sustituye a Composer. Prepara la estructura que el driver de Composer va a construir usando el contexto KNX del proyecto ETS.
Es util cuando cientos de objetos importados necesitan limpieza de nombres, ubicacion en estancias o ajustes de subtipo antes de convertirse en dispositivos Control4.
Por que no editar todo en Composer
Composer es potente, pero el trabajo repetitivo de nombres y mapeos se vuelve lento si cada cambio se hace despues de crear dispositivos.
Editar antes de exportar reduce limpieza, facilita revision masiva y mantiene visible la fuente KNX mientras se toman decisiones.
Estado de revision antes de exportar
Un buen flujo de editor marca que se ha revisado, que necesita atencion y que esta listo para exportar.
Asi el .codu no se convierte en un paquete de suposiciones sin resolver.
- Dispositivos soportados marcados con claridad.
- Mapeos ambiguos visibles antes del build.
- Cambios masivos revisables antes de exportar.
Construccion con el driver de Composer
Cuando la estructura esta revisada, el driver de Composer recibe el .codu y muestra el plan antes de crear.
El editor se centra en preparar y el driver en crear el proyecto de forma fiable.
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
Es lo mismo que Control4 DriverEditor o DriverWorks?
No. Control4 DriverEditor y DriverWorks son para desarrollo de drivers, comportamiento Lua, trabajo XML/proxy y packaging de drivers como .c4z o .c4i. Este flujo edita la estructura Control4 derivada de KNX antes de que el driver Composer cree dispositivos.
Debo usar Driver Wizard o DriverEditor para limpiar un import KNX?
No si el driver ya existe. Driver Wizard y DriverEditor sirven para crear o mantener drivers. La limpieza de import KNX trata de contexto ETS, rooms, dispositivos, mapeos y revision antes del export .codu.
Esto sustituye a Control4 Composer?
No. Composer sigue siendo el entorno final Control4. El editor prepara y revisa el proyecto antes de que el driver lo construya.
Que se puede editar antes de exportar?
Estancias, nombres de dispositivo, subtipos soportados, contexto de mapeo y cambios masivos antes del export .codu.
Por que mantener visible el contexto KNX?
Porque el instalador puede comprobar que cada dispositivo Control4 sigue correspondiendo con la fuente KNX, direcciones y datapoints originales.
Prepara el build del driver Control4 con revision
Usa el editor para limpiar la estructura generada y exporta un .codu que el driver de Composer pueda construir.