Vista previa cross-check de switch actuator KNX
La vista cross-check mantiene objetos KNX, DPTs y candidatos switch-light Control4 visibles juntos para revisar comando, estado e intencion de rele antes del export.
Un actuador switch no siempre es una luz
Muchos canales de actuador switch KNX son circuitos de iluminacion normales. Otros controlan extractores, bombas, puertas, contactos de garaje, toalleros, salidas tecnicas o logica central. Desde un comando DPT 1 aislado pueden parecer iguales.
CoduWorks debe usar nombres ETS, estancia, tipo de dispositivo, ComObjects y feedback para decidir si el canal es una luz switch Control4 soportada o una carga de rele que necesita revision manual.
- Circuito de luz que debe convertirse en switch light Control4.
- Carga tecnica de rele que no debe tratarse como luz normal.
- Central on/off, staircase, bloqueo o prioridad que solo es contexto.
- Objeto de feedback/estado que pertenece a un canal existente.
Comando DPT 1 y feedback deben emparejarse
Una luz switch soportada normalmente necesita direccion de comando on/off y direccion fiable de estado o feedback. El feedback importa cuando la luz cambia desde pulsadores KNX, sensores, timers o funciones centrales en lugar de Control4.
La revision no debe crear dispositivos separados para comando y estado. Debe agruparlos como un candidato switch-light y mostrar feedback ausente o ambiguo antes del export.
Nombres y estancias deciden si el build es util
Los nombres de actuadores switch importados de ETS suelen incluir cuadro, canal, circuito o abreviaturas. Esos labels son utiles para trazar la fuente, pero Control4 necesita nombres de estancia y display legibles.
Bulk edit y search/replace son utiles antes del export .codu porque un patron de nombres puede repetirse en docenas de canales.
Central, lock y staircase no son luces extra
Los actuadores switch pueden exponer central off, forced position, disable, lock, staircase timer, fallo o diagnostico. Esas senales explican comportamiento, pero no deben inflar el device count ni crear luces visibles extra.
El instalador debe ver esos objetos como contexto y decidir si alguno pertenece a programacion Composer, diagnostico o scope manual separado.
Composer debe recibir una luz switch revisada
El paquete .codu debe decir al driver Composer que luz switch crear y que direcciones KNX pertenecen a ella. No debe dejar la agrupacion comando/estado o la intencion de rele como tarea pendiente dentro de Composer.
Asi el build create-only es predecible y evita duplicados, nombres incorrectos o dispositivos de rele inseguros dentro del proyecto Control4 real.
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
Todos los canales de actuador switch KNX se convierten en luces Control4?
No. Solo los canales de iluminacion revisados deben convertirse en switch lights core. Cargas tecnicas, funciones centrales y objetos de bloqueo quedan como contexto o scope separado.
Que direcciones necesita normalmente una luz switch Control4?
Normalmente una direccion de comando on/off y una direccion de feedback/estado. El estado mantiene Control4 alineado cuando KNX cambia la luz fuera de la UI Control4.
Los canales switch actuator cuentan en el tier de licencia?
Si cuando se revisan como canales de luz soportados. Objetos auxiliares como central off, lock o diagnostico no deberian crear dispositivos core extra.
En que se diferencia de reles para gates o pumps?
Una switch-light es una luz normal. Gates, bombas, garajes y otras cargas tecnicas necesitan revision de intencion, seguridad y feedback antes de entrar en scope.
Comprueba actuadores switch antes de Composer
Importa ETS, revisa comando y estado DPT 1, separa luces reales de contexto de rele y exporta un .codu limpio.