Vista previa de cross-check de keypads KNX
La vista de cross-check mantiene la fuente KNX junto a la estructura Control4 generada para revisar keypads, pulsadores, dispositivos y feedback antes del export.
Por que importan aunque no sean dispositivos core
Un keypad KNX puede revelar intencion de estancia, patrones de nombre, escenas y relacion entre interaccion fisica y automatizacion Control4. Ese contexto ayuda al revisar la estructura generada.
La decision importante no es convertir cada keypad en dispositivo Control4. La decision importante es si sus direcciones y nombres explican algo que el instalador debe comprobar antes de crear el proyecto final en Composer.
- Usar etiquetas y ComObjects de pulsadores para entender comportamiento de la estancia.
- Separar eventos de boton de la creacion de luces y persianas.
- Revisar entradas binarias y direcciones de pulsador antes del export si afectan a automatizacion.
La intencion de trigger necesita revision
Algunas pulsaciones KNX pueden usarse para disparar comportamiento Control4, pero depende del soporte del driver, DPT, transmit flags, objetos de estado y modelo de programacion en Composer.
Un flujo review-first debe marcar esas senales claramente en vez de esconderlas dentro del bulk build principal. Asi el instalador no confunde una entrada fisica con una luz, persiana o gateway generado.
Keypads y pulsadores no suben el tier de licencia
Para el pricing de CoduWorks, el conteo son luces, persianas, termostatos y gateways KNX/IP. Un proyecto puede tener cientos de keypads, pulsadores, sensores o entradas binarias sin subir por si solo el tier de licencia.
Esa regla hace los proyectos KNX mas accesibles y permite mantener estos objetos visibles como contexto para revision, diagnostico y add-ons especificos.
Composer debe recibir creacion limpia mas contexto
El handoff .codu debe crear estructura soportada en Composer y conservar contexto suficiente para que el instalador programe escenas o comportamientos custom de forma deliberada.
Si el comportamiento de un keypad requiere programacion especifica, debe quedar como item de revision, no mezclarse con la creacion automatica de dispositivos donde puede generar ruido o controles duplicados.
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
Los keypads KNX cuentan como dispositivos de licencia CoduWorks?
No. El tier cuenta luces, persianas, termostatos y gateways KNX/IP. Keypads, pulsadores y entradas binarias pueden quedar visibles como contexto sin subir el tier.
Un pulsador KNX puede disparar programacion Control4?
Puede ser posible segun driver, DPT, transmit flags y como se represente la senal en Composer. Debe revisarse como intencion de trigger, no asumirse a ciegas.
Los keypads deben generarse automaticamente como dispositivos Control4?
No dentro del flujo automatico. Normalmente conviene tratarlos como contexto o programacion especifica mientras el build crea luces, persianas, termostatos y gateways.
Revisa el contexto de keypads antes del export
Importa ETS, conserva keypads y pulsadores visibles, y exporta un .codu limpio centrado en dispositivos Control4 soportados.