Vista previa del flujo de dispositivos soportados
La vista muestra el flujo revisable desde ETS a Control4. Las familias soportadas se preparan para exportar mientras el resto del contexto KNX queda visible para revision.
Alcance principal de dispositivos generados
El primer alcance de produccion se centra en familias que se pueden revisar de forma predecible desde ETS: luces switch, dimmers, persianas open-close, persianas porcentuales y gateways KNX/IP. Son los objetos que el instalador puede preparar, revisar y exportar al build del driver Composer.
Este alcance mas concreto es intencionado. Hace que el paquete de build sea mas facil de auditar y evita convertir cada objeto KNX en un dispositivo Control4 solo porque existe en ETS.
- Luces switch y dimmers con revision de comando y feedback.
- Persianas con open-close, stop, porcentaje y feedback de posicion cuando exista.
- Contexto de gateway KNX/IP para routing, visibilidad y conteo de licencia.
Que cuenta para el tier de licencia
Para pricing y tiering, CoduWorks cuenta luces, persianas, termostatos y gateways KNX/IP. Keypads, pulsadores, sensores y registros similares pueden ser contexto importante, pero no suben el tier de licencia por si solos.
Esto hace mas asequibles los proyectos KNX grandes cuando contienen muchas entradas fisicas pero menos dispositivos Control4 visibles que generar.
Contexto que debe seguir visible
Un keypad, pulsador, entrada binaria o sensor puede explicar por que una habitacion se llama de una forma o por que existe una direccion de grupo. El flujo no debe descartar ese contexto; debe mantenerlo visible durante la revision.
El contexto visible ayuda al instalador a decidir mejor sin forzar familias no soportadas dentro del build create-only de Composer.
Add-ons y sistemas fuera del core
Termostatos, HVAC, RGB, tunable white, DALI y logica custom necesitan una revision mas especifica por proyecto. Pueden depender de setpoints, modos, canales de color, comportamiento de gateway o DPTs concretos del fabricante.
Esos sistemas deben acotarse por separado en vez de esconderse dentro del bulk build principal. Si se revisan como add-ons, el instalador puede confirmar las senales necesarias antes de entregar el paquete a Composer.
Por que no generar todos los objetos KNX automaticamente
La creacion automatica solo aporta valor cuando el dispositivo generado se entiende y se puede revisar. Crear todos los objetos KNX a ciegas produciria ruido, controles duplicados y dispositivos con poco valor de usuario.
Un mejor flujo mantiene visible la fuente KNX, crea estructura Control4 desde patrones soportados y deja las familias inciertas como items de revision.
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 dispositivos KNX soporta el flujo core?
El flujo core se centra en luces switch, dimmers, persianas y gateways KNX/IP. Se revisan antes del export y luego se construyen con el driver Composer.
Los keypads o pulsadores cuentan como dispositivos?
No. Pueden ser contexto KNX util, pero no suben el tier de licencia salvo que el proyecto anada un flujo separado para ellos.
Termostatos y HVAC avanzado estan soportados?
Se tratan como revision add-on separada porque setpoints, modos, fan speed, demanda y feedback cambian mucho entre proyectos KNX.
Revisa los dispositivos soportados antes del export
Usa el AI Assistant para convertir ETS en un paquete Control4 enfocado: luces, persianas, termostatos, gateways e items claros de revision para lo demas.