Vista previa de cross-check de escenas KNX
La vista de cross-check mantiene objetos de escena KNX, DPTs, keypads y estructura Control4 generada visibles juntos para revisar contexto antes de programar en Composer.
Un objeto de escena KNX no es una escena Composer
Un objeto de escena KNX puede llamar o guardar un numero de escena en el bus. Una escena Control4 es una construccion de Composer con luces, cargas, comportamiento de estancia, tracking y a menudo bindings de keypad. Pueden relacionarse, pero no deben fusionarse como un dispositivo automatico.
CoduWorks debe mantener visible la evidencia de escena KNX para que el instalador decida si se convierte en contexto de programacion Composer, nota de intencion de keypad o tarea manual de reconstruccion de escena.
DPT 17 y DPT 18 necesitan revision explicita
DPT 17 suele transportar un numero de escena. DPT 18 puede transportar control de escena con semantica call/store. Esos detalles importan porque un boton de escena puede significar solo recall, store/learn o una tabla de valores propia del proyecto.
La revision debe identificar DPT, dispositivo fuente, nombre de direccion de grupo y comportamiento esperado antes de planificar programacion Control4.
- DPT 17 scene number y rango de payload usado en el proyecto.
- DPT 18 call/save o learn cuando exista.
- Label de numero de escena en ETS frente al payload enviado en bus KNX.
- Keypad, pantalla, modulo logico o objeto fuente del actuador.
- Si el objeto de escena es comando, estado, trigger o logica heredada.
Los offsets de escena pueden crear errores de una posicion
Algunas herramientas KNX presentan escenas como 1 a 64 mientras el payload de bus puede representarse como 0 a 63. Si no se comprueba esa convencion, una accion Control4 puede disparar la escena KNX equivocada o el label visible equivocado.
Un flujo review-first debe marcar los supuestos de numero de escena como decisiones del instalador, no traducirlos en silencio a programacion Composer.
Los botones de escena son contexto de keypad
Una tecla de escena en un keypad suele indicar que debe hacer la estancia: welcome, all off, night, relax, clean, away u otro label del proyecto. Esa intencion es valiosa aunque el keypad no se cree como dispositivo core.
El paquete .codu debe conservar nombre fuente, DPT y direccion de grupo para que la programacion Composer sea deliberada despues de crear luces, persianas, termostatos y gateways soportados.
Mantener escenas fuera del build automatico
El build core debe seguir centrado en dispositivos soportados. Objetos de escena KNX, teclas de escena y payloads DPT 17/18 pertenecen al contexto de revision o a scope de programacion especifico.
Asi el proyecto Composer generado sigue limpio y aun muestra la evidencia de escenas que puede acelerar la programacion final.
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 objetos de escena KNX crean escenas Control4 automaticamente?
No en el flujo core. Deben revisarse como contexto de escena. Composer sigue siendo donde se programan escenas finales y bindings de keypad.
Por que importan DPT 17 y DPT 18?
DPT 17 suele representar numero de escena y DPT 18 puede incluir comportamiento call/store. La diferencia afecta a si la senal es trigger, guardado o contexto.
Que problema hay con 0-63 y 1-64?
Los labels de escena KNX pueden verse como 1 a 64 mientras el payload de bus se representa como 0 a 63. El instalador debe verificar la convencion antes de mapear Control4.
Los botones de escena cuentan como licencia?
No. Botones de escena, keypads y triggers no suben el tier por si solos. El conteo sigue siendo luces, persianas, termostatos y gateways KNX/IP.
Revisa escenas KNX antes de Composer
Importa ETS, inspecciona objetos de escena, DPTs e intencion de keypads, y exporta .codu conservando contexto para programacion.