Vista previa cross-check de dimmer KNX
La vista cross-check mantiene objetos KNX, DPTs y candidatos dimmer Control4 visibles juntos para revisar comando, nivel y feedback antes del export.
Un actuador dimmer es una familia de objetos
Un canal dimmer KNX puede incluir varios ComObjects. Uno puede encender la carga, otro cambiar brillo con dimming relativo, otro fijar un nivel absoluto y otro informar el valor actual.
CoduWorks debe usar el contexto ETS para agrupar esos objetos en un unico candidato dimmer Control4 revisado. Asi se evitan duplicados y el paquete .codu es mas fiable antes de crear nada en Composer.
- Comando switch y estado switch opcional.
- Dimming relativo, habitual en pulsacion mantenida de keypad.
- Valor absoluto de brillo, normalmente DPT 5.001 scaling.
- Feedback de brillo o valor de estado.
- Bloqueos, funciones centrales, staircase, presets u objetos de escena como contexto.
DPT 5.001 y la escala de brillo deben verificarse
DPT 5.001 se usa habitualmente para representar brillo como porcentaje. Aun asi, hay que revisar porque nombres ETS, comportamiento del gateway y objetos de feedback deciden que direccion manda y cual informa.
Si el proyecto mezcla comando de nivel y feedback de nivel, Control4 puede mostrar un valor incorrecto tras un cambio desde keypad KNX, sensor o escena fuera de la UI Control4.
El dimming relativo por si solo no es un dimmer estable
DPT3 relative dimming sirve para subir/bajar o pulsacion mantenida, pero por si solo no da a Control4 un estado absoluto fiable de brillo.
La revision debe emparejar dimming relativo con valor absoluto y feedback cuando ETS los aporta. Si no existen, el instalador debe ver la limitacion antes de aceptar el build plan.
El feedback decide si Control4 queda sincronizado
Un dimmer puede cambiar desde keypads KNX, logica de movimiento, escenas, objetos central off o automatizacion de fabricante. Sin feedback de brillo, la interfaz Control4 solo parece correcta cuando Control4 fue el ultimo controlador.
El AI Assistant debe marcar feedback ausente o ambiguo para que el instalador decida si continuar, corregir nombres ETS o dejar el objeto fuera del build create-only.
Composer debe recibir un dimmer limpio
El handoff .codu debe decir al driver Composer que dimmer Control4 crear y que direcciones KNX pertenecen a ese dimmer. No debe obligar al instalador a resolver agrupaciones dentro de Composer despues de crear dispositivos.
Esto importa especialmente en proyectos grandes donde docenas de canales dimmer repiten patron de nombres, DPTs y convenciones de feedback.
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 objetos KNX necesita normalmente un dimmer Control4?
Un dimmer revisado suele necesitar comando switch, comando de brillo y feedback de brillo. Algunos proyectos tambien incluyen feedback switch, dimming relativo y objetos de contexto extra.
DPT 5.001 es obligatorio en todos los dimmers KNX?
Es un datapoint habitual para escala de brillo, pero hay que revisar el modelo ETS real. Dimming relativo por si solo no equivale a un nivel absoluto estable con feedback.
Los dimmers KNX cuentan en el tier de licencia?
Si. Canales de luz y dimmer soportados son dispositivos contabilizados, asi que cuentan en el tier de luces, persianas, termostatos y gateways.
Bloqueos o escenas deben crear dispositivos Control4 extra?
Normalmente no. Bloqueos, funciones centrales, staircase y escenas deben quedar como contexto salvo que el proyecto los scopee aparte.
Comprueba dimmers KNX antes de Composer
Importa ETS, revisa cada canal de actuador dimmer, verifica DPTs y feedback, y exporta un .codu limpio para Composer.