Preparacion ETS/Actualizado Junio 2026/7 min

Como preparar un .knxproj de ETS antes de importarlo en un flujo Control4

El mejor flujo KNX a Control4 empieza antes de subir el archivo. Si el proyecto ETS tiene nombres consistentes y contexto util de DPT, objetos y habitaciones, la revision es mas rapida y el build final en Composer es mas fiable.

Puntos clave

Exporta el archivo de proyecto cuando nombres y topologia sean suficientemente estables.
Haz visibles las relaciones entre command y feedback mediante nombres y estructura de direcciones.
Mantén identificables los dispositivos no soportados o dudosos en vez de esconderlos en nombres genericos.

Antes de exportar: estabiliza el proyecto lo suficiente para revisarlo

El archivo ETS no tiene que ser perfecto, pero si coherente. Nombres de habitaciones, actuadores, objetos de comunicacion y direcciones de grupo deberian ser entendibles para otro integrador.

Los cambios de ultima hora son normales. El objetivo no es congelar el proyecto KNX, sino evitar subir un archivo donde la misma funcion aparece con cinco estilos de nombre distintos.

Usa nombres consistentes para luces, dimmers, persianas, termostatos y gateways.
Evita etiquetas temporales como test, spare, old o copy salvo que deban quedar excluidas.
Confirma que las habitaciones y areas finales aparecen en el contexto ETS.

Haz faciles de entender las familias de direcciones de grupo

Un dispositivo Control4 se infiere mejor cuando las direcciones KNX relacionadas siguen un patron reconocible. Command, status, level, stop y position deberian estar suficientemente cerca en nombre o estructura para revisarse como una funcion.

Si el proyecto usa varias convenciones, documenta la regla antes de importar. Asi la revision no se convierte en adivinanza.

Revisa DPTs y objetos de comunicacion

Los DPTs y nombres de objetos son senales fuertes para el mapeo. Si faltan o son confusos, habra mas revision manual despues, sobre todo en dimming y persianas.

En luces y persianas, conviene distinguir claramente comando y feedback. Cuando el rol no esta claro, es mejor crear un item de revision visible que crear un dispositivo Control4 erroneo.

Mantén visible el contexto de gateways, routers y lineas

Control4 no solo necesita dispositivos finales. Tambien necesita llegar a la instalacion KNX por la ruta IP correcta. Si hay varias lineas, routers o interfaces, ese contexto debe seguir visible en el archivo importado.

Para pricing y conteo de dispositivos, el flujo CoduWorks cuenta luces, persianas, termostatos y gateways IP como dispositivos. Keypads, pulsadores, sensores y entradas similares no cambian el tier de licencia por si solos.

Checklist antes de subir

Antes de subir el .knxproj, comprueba que abre correctamente, representa el ultimo estado comisionado e incluye habitaciones y direcciones relevantes. Si esta protegido o incompleto, resolvelo antes de procesar.

Despues de subirlo, usa la vista KNX para confirmar que topologia, dispositivos y direcciones aparecen como esperas. No esperes a Composer para descubrir que la fuente no era la version correcta.

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

Necesito que el proyecto KNX este terminado antes de importar?

Debe estar suficientemente coherente para revisarlo. Puede cambiar despues, pero nombres inestables y contexto incompleto generan mas limpieza manual.

Un export OPC es suficiente?

Puede servir para listas de direcciones, pero un .knxproj normalmente aporta mas contexto de topologia, dispositivos y objetos para preparar Control4.

Que dispositivos cuentan para el pricing de CoduWorks?

Cuentan luces, persianas, termostatos y gateways IP. Keypads, pulsadores, sensores y entradas similares aportan contexto pero no suben el tier de licencia por si solos.