Checklist previa/Actualizado mayo 2026

Checklist KNX a Control4 antes de exportar a Composer

Name: Vista previa de checklist antes del export
Uploaded: 2026-05-20
Description: La vista muestra un proyecto KNX a Control4 revisado acercandose al export, con contexto de build comprobado antes de crear dispositivos en Composer.

Antes de convertir un proyecto KNX en build Control4, el instalador debe saber que esta listo, que no esta soportado y que necesita revision. Esta checklist mantiene el export .codu centrado en una estructura revisada, no en supuestos sueltos.

Comprueba calidad de la fuente ETS antes de procesar.
Revisa dispositivos soportados, DPTs, feedback y contexto gateway.
Confirma conteo de pricing y expectativas del build report antes de Composer.

Abrir AI Assistant Ver producto

Vista previa de checklist antes del export

La vista muestra un proyecto KNX a Control4 revisado acercandose al export, con contexto de build comprobado antes de crear dispositivos en Composer.

1. Archivo fuente ETS

Empieza con un proyecto ETS terminado. El .knxproj debe reflejar topologia, rooms, naming y organizacion de direcciones que quieres usar como fuente de verdad.

Usa un .knxproj procesable, no protegido con password.
Comprueba que buildings, floors y rooms tienen nombres claros.
Guarda backup del proyecto ETS antes de procesar.

2. Alcance de dispositivos soportados

Confirma que objetos deben convertirse en dispositivos Control4. El alcance contabilizado actual se centra en luces switch/dimmer, persianas open-close o porcentaje, termostatos e IP gateways KNX.

Luces y dimmers tienen comando y feedback.
Persianas tienen posicion/open-close, stop y feedback cuando existe.
Keypads, pulsadores y sensores no deben subir el tramo de licencia.
Termostatos cuentan cuando entran en scope y deben revisarse con detalle HVAC propio.

3. Direcciones, DPTs y feedback

Revisa comando y feedback juntos. Un build limpio necesita mas que una lista de direcciones: necesita contexto de datapoint y funcion.

Valores tipo DPT-1 para switch, stop u open-close.
Valores tipo DPT-5 para nivel dimmer, posicion persiana o feedback porcentaje.
Objetos DPT3 relative dimming visibles para revision, no generacion automatica.

4. Contexto gateway y routing

Comprueba que los telegramas relevantes pueden llegar a la ruta Control4. Si gateway, router o filter table ocultan direcciones, Composer puede parecer mal aunque el mapeo sea logico.

5. Readiness para build en Composer

Antes de ejecutar el driver en Composer, revisa el build report. Los numeros deben coincidir con rooms revisadas, dispositivos soportados y comportamiento create-only esperado.

Revisa riesgo de duplicados antes de crear dispositivos.
Confirma que el tramo de licencia cuenta luces, persianas, termostatos e IP gateways.
Usa el .codu como paquete cerrado, no como sitio donde resolver decisiones pendientes dentro de Composer.

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

Que se debe revisar antes del export .codu?

Calidad ETS, dispositivos soportados, direcciones de grupo, DPTs, feedback, gateway, riesgo de duplicados y conteo esperado.

Keypads y sensores cuentan para pricing?

No. Los tramos cuentan luces, persianas, termostatos e IP gateways. Keypads, pulsadores y sensores no suben el tramo.

Debo forzar dispositivos no soportados al build?

No. Combinaciones no soportadas o poco claras deben quedar visibles para revision, no convertirse a ciegas en dispositivos Control4.