Introducción
En KNX, muchas veces hablamos de direcciones de grupo, actuadores, pulsadores, sensores, gateways DALI, interfaces HVAC, visualizaciones y sistemas BMS.
Pero hay un detalle dentro de ETS que muchas veces se subestima:
los flags de los objetos de comunicación.
A simple vista parecen solo pequeñas letras dentro de ETS, pero en realidad definen cómo se comunica cada objeto KNX en el bus.
Los flags indican si un objeto puede enviar, recibir, responder, actualizarse o recuperar un valor después de un reinicio.
Aquí es donde muchas veces empieza la confusión.
Un pulsador no se comporta igual que un actuador.
Un objeto de comando no se comporta igual que un objeto de estado.
Una visualización no necesita la misma configuración que un sensor.
Por eso, entender los flags en ETS es fundamental para diseñar, programar y mantener una instalación KNX profesional.
La documentación oficial de KNX Association describe los flags principales como Comunicación, Lectura, Escritura, Transmisión, Actualización y Lectura al Inicio, y explica cómo reaccionan ante telegramas KNX como GroupValueRead, GroupValueWrite y GroupValueResponse.
1. Por qué los flags son importantes en ETS
KNX es un sistema descentralizado de automatización de edificios.
Esto significa que los dispositivos se comunican directamente entre sí mediante telegramas.
Por ejemplo:
Un pulsador puede enviar un comando ON/OFF.
Un actuador puede recibir ese comando.
Un sensor puede enviar una temperatura.
Una visualización puede mostrar el estado real de una luz.
Un gateway puede intercambiar información con un sistema HVAC, DALI, BACnet o Modbus.
Pero para que esta comunicación funcione correctamente, ETS necesita saber qué puede hacer cada objeto.
Aquí entran los flags.
Los flags ayudan a definir:
Qué objeto puede enviar telegramas.
Qué objeto puede recibir telegramas.
Qué objeto puede responder cuando otro dispositivo pregunta por un valor.
Qué objeto puede actualizar su valor interno.
Qué objeto puede recuperar información después de un reinicio.
En proyectos pequeños, un error en los flags puede pasar desapercibido durante la puesta en marcha.
Pero en proyectos más grandes, como residencias premium, hoteles, edificios de oficinas o integraciones BMS, una mala configuración puede causar problemas difíciles de diagnosticar.
2. Qué son los objetos de comunicación en KNX
Cada dispositivo KNX tiene objetos de comunicación.
Estos objetos son los puntos mediante los cuales el dispositivo intercambia información con el bus KNX.
Por ejemplo:
Un pulsador puede tener un objeto para enviar ON/OFF.
Un actuador puede tener un objeto para recibir ON/OFF.
Un actuador también puede tener otro objeto para enviar el estado real de su salida.
Un sensor puede tener un objeto para enviar temperatura, humedad o presencia.
Una visualización puede tener objetos para mostrar estados, valores o alarmas.
Cada uno de estos objetos puede tener diferentes flags.
Por eso, no basta con enlazar una dirección de grupo.
También hay que entender qué función cumple el objeto dentro de la comunicación.
Un objeto puede ser de comando.
Otro puede ser de estado.
Otro puede ser de medición.
Otro puede ser de retroalimentación.
Otro puede ser usado por una visualización o lógica.
Cada uno necesita una configuración lógica de flags.
3. Tabla general de flags en ETS
En ETS, los flags normalmente se muestran como letras.
En español, los nombres principales son:
| Letra ETS | Nombre en español | Nombre en inglés | Significado simple |
|---|---|---|---|
| C | Comunicación | Communication | El objeto participa en la comunicación KNX |
| W | Escritura | Write | El objeto puede recibir un telegrama de escritura desde el bus |
| T | Transmisión | Transmit | El objeto puede enviar telegramas al bus |
| R | Lectura | Read | El objeto puede responder a una solicitud de lectura |
| U | Actualización | Update | El objeto puede actualizar su valor interno desde una respuesta |
| I | Lectura al Inicio | Read on Init | El objeto puede solicitar un valor después de un reinicio |
El punto importante no es solamente memorizar las letras.
Lo importante es entender la dirección de la comunicación.
En ETS:
Transmisión significa enviar.
Escritura significa recibir.
Esta diferencia es una de las claves más importantes para entender los flags.
4. Flag C: Comunicación
La bandera C significa Comunicación.
Este flag indica que el objeto participa en la comunicación KNX.
En palabras simples:
Comunicación = este objeto está activo para comunicarse en el bus KNX.
Normalmente, los objetos que se enlazan con direcciones de grupo tienen este flag activo.
Ejemplo:
Un pulsador que envía un comando de luz necesita Comunicación.
Un actuador que recibe ese comando también necesita Comunicación.
Un sensor que transmite una temperatura necesita Comunicación.
Una visualización que recibe estados también necesita Comunicación.
La documentación de KNX indica que la bandera de Comunicación habilita la relevancia de los demás flags para el objeto.
Por eso, se puede considerar el flag base para la comunicación del objeto.
5. Flag W: Escritura
La bandera W significa Escritura.
Este es probablemente el flag que más confusión genera.
Muchas personas piensan que Escritura significa que el objeto escribe o envía algo al bus.
Pero en ETS no funciona así.
En ETS:
Escritura significa que el objeto puede recibir un telegrama desde el bus.
La documentación oficial de KNX explica que, cuando el flag de Escritura está activo, el dispositivo reacciona a un telegrama GroupValueWrite procedente del bus y sobrescribe el valor del objeto.
Ejemplo práctico:
Un actuador de conmutación tiene un objeto para encender o apagar una salida.
Cuando un pulsador envía ON, el actuador recibe ese telegrama.
Para que el actuador pueda recibir ese comando, el objeto del actuador necesita el flag de Escritura.
En este caso, los flags típicos serían:
C + W
Comunicación + Escritura.
En palabras simples:
W / Escritura = este objeto puede ser controlado desde el bus KNX.
6. Flag T: Transmisión
La bandera T significa Transmisión.
Este flag indica que el objeto puede enviar telegramas al bus KNX.
La documentación de KNX explica que, cuando el flag de Transmisión está activo, el dispositivo transmite un valor actualizado del objeto enviando un telegrama GroupValueWrite al bus.
Ejemplos típicos:
Un pulsador envía ON/OFF.
Un detector de presencia envía presencia.
Un sensor de temperatura envía la temperatura ambiente.
Un actuador envía el estado real de una salida.
Un gateway HVAC envía el estado de funcionamiento de una unidad.
Para un pulsador que envía un comando, los flags típicos serían:
C + T
Comunicación + Transmisión.
En palabras simples:
T / Transmisión = este objeto puede enviar información al bus KNX.
7. Flag R: Lectura
La bandera R significa Lectura.
Este flag permite que un objeto responda cuando otro dispositivo solicita su valor.
La documentación oficial de KNX indica que, cuando el flag de Lectura está activo, el dispositivo reacciona a un telegrama GroupValueRead procedente del bus y envía un telegrama GroupValueResponse como respuesta.
Ejemplo práctico:
Una visualización se reinicia.
Después del reinicio, necesita saber si una luz está encendida o apagada.
La visualización puede enviar una solicitud de lectura a la dirección de grupo de estado.
El dispositivo que conoce el valor real, normalmente el actuador, puede responder si su objeto tiene activo el flag de Lectura.
Para un objeto de estado real de un actuador, una configuración típica puede ser:
C + T + R
Comunicación + Transmisión + Lectura.
Esto permite que el actuador envíe el estado cuando cambia y también responda cuando otro dispositivo pregunta por el valor actual.
8. Flag U: Actualización
La bandera U significa Actualización.
Este flag permite que un objeto actualice su valor interno cuando recibe una respuesta desde el bus.
Según KNX Association, cuando el flag de Actualización está activo, el dispositivo reacciona a un telegrama GroupValueResponse procedente del bus y sobrescribe el valor del objeto.
En palabras simples:
Actualización = el objeto puede sincronizar su valor interno desde una respuesta del bus.
Esto puede ser útil en diferentes casos:
LEDs de pulsadores que deben seguir el estado real de una luz.
Controladores de habitación que necesitan sincronizar valores.
Visualizaciones que deben mantener estados internos actualizados.
Módulos lógicos que trabajan con valores reales.
Gateways que deben mantener una referencia interna del estado.
No todos los objetos necesitan este flag.
Depende del dispositivo, del fabricante y del programa de aplicación.
Por eso, siempre es importante revisar la documentación del producto y entender el comportamiento esperado del objeto.
9. Flag I: Lectura al Inicio
La bandera I significa Lectura al Inicio.
En inglés se conoce como Read on Init.
Este flag permite que un objeto solicite su valor después de un reinicio.
La documentación de KNX explica que, cuando este flag está activo, el dispositivo envía un telegrama GroupValueReaddespués de un reinicio para recuperar el valor actualizado mediante un GroupValueResponse.
Esto puede ocurrir después de:
Un fallo de alimentación.
Un reinicio del bus.
Un reinicio del dispositivo.
Una descarga desde ETS.
Un reinicio de una visualización o servidor.
Ejemplo práctico:
Una visualización KNX se reinicia.
Después del reinicio, no sabe el estado actual de luces, persianas, climatización o escenas.
Con Lectura al Inicio, puede solicitar los valores actuales y sincronizarse nuevamente con la instalación real.
Este flag es especialmente importante en:
Visualizaciones.
Pantallas táctiles.
Controladores de habitación.
Módulos lógicos.
Gateways BMS.
Supervisión centralizada.
Servidores KNX.
En palabras simples:
Lectura al Inicio = el objeto puede pedir el valor actual después de reiniciarse.
10. La confusión más común: Escritura no significa enviar
Este es el punto más importante del artículo.
En el lenguaje normal, la palabra “escritura” puede sonar como si el objeto estuviera escribiendo o enviando algo.
Pero en ETS no es así.
En ETS:
Escritura = recibir desde el bus.
Transmisión = enviar al bus.
Por eso, un pulsador que envía un comando necesita Transmisión.
Un actuador que recibe ese comando necesita Escritura.
Un sensor que envía una temperatura necesita Transmisión.
Un objeto de estado que envía retroalimentación necesita Transmisión.
Y si otros dispositivos deben poder preguntar por ese estado, normalmente también necesita Lectura.
Este punto parece simple, pero es la causa de muchos errores en proyectos reales.
11. Ejemplo práctico: control ON/OFF de una luz
Imaginemos una luz sencilla en una sala.
Tenemos:
Un pulsador KNX.
Un actuador KNX.
Una dirección de grupo para el comando.
Una dirección de grupo para el estado.
La estructura podría ser la siguiente:
Dirección de grupo de comando
1/1/10 Luz Sala ON/OFF Comando
| Dispositivo | Función del objeto | Flags típicos |
|---|---|---|
| Pulsador | Envía ON/OFF | C + T |
| Actuador | Recibe ON/OFF | C + W |
El pulsador envía el comando.
El actuador recibe el comando.
Esta es la dirección básica de la comunicación.
El pulsador no necesita Escritura en ese objeto, porque no está recibiendo el comando.
El actuador no necesita Transmisión en ese objeto de entrada, porque ese objeto no está enviando.
Dirección de grupo de estado
1/1/11 Luz Sala ON/OFF Estado
| Dispositivo | Función del objeto | Flags típicos |
|---|---|---|
| Actuador | Envía estado real de la salida | C + T + R |
| LED del pulsador | Recibe o actualiza estado | C + W o C + U, según el dispositivo |
| Visualización | Muestra el estado real | Depende del sistema |
El actuador conoce el estado real de la salida.
Por eso, el estado real debe venir del actuador, no del pulsador.
Un comando solo indica lo que se pidió.
Un estado indica lo que realmente ocurrió.
Esta diferencia es fundamental en una instalación KNX profesional.
12. Comando y estado: por qué no deben confundirse
Un error común en ETS es usar la misma dirección de grupo para comando y estado.
En proyectos muy pequeños, puede parecer que funciona.
Pero en instalaciones profesionales, normalmente conviene separar comando y estado.
¿Por qué?
Porque un comando no siempre confirma el estado real.
Ejemplo:
Un pulsador envía ON.
Pero el actuador puede estar bloqueado.
El canal puede estar forzado.
Una función central puede estar activa.
Una condición de seguridad puede impedir el cambio.
Puede existir un fallo.
La salida puede no cambiar como se esperaba.
Si una visualización solo sigue el comando, puede mostrar ON aunque la salida real siga apagada.
Por eso, una estructura KNX limpia normalmente utiliza:
Dirección de grupo de comando para enviar órdenes.
Dirección de grupo de estado para confirmar retroalimentación real.
Esta separación facilita mucho el diagnóstico con el monitor de grupos de ETS.
Permite ver claramente quién envió el comando, quién lo recibió y quién confirmó el estado real.
13. Errores comunes en ETS con los flags
Los errores con flags pueden generar problemas que no siempre aparecen de inmediato.
Algunos errores comunes son:
Activar Transmisión en el objeto incorrecto.
No activar Escritura en un actuador que debe recibir comandos.
No activar Transmisión en un sensor que debe enviar valores.
No activar Lectura en el objeto que debe responder a una visualización.
Activar Lectura en demasiados objetos dentro de la misma dirección de grupo.
Usar el comando como si fuera estado real.
No usar Lectura al Inicio en visualizaciones o gateways que necesitan recuperar valores después de reinicio.
No revisar el comportamiento específico del fabricante.
Un caso típico es activar el flag de Lectura en varios objetos de una misma dirección de grupo.
Cuando una visualización pregunta por el valor, varios dispositivos pueden responder.
Si las respuestas no son iguales, el sistema puede comportarse de forma confusa.
Como regla práctica:
Normalmente debe responder a una solicitud de lectura el dispositivo que posee el valor real.
Para una luz, normalmente responde el actuador.
Para una temperatura, normalmente responde el sensor o controlador de habitación.
Para una persiana, normalmente responde el actuador de persianas.
Para HVAC, normalmente responde el gateway o controlador correspondiente.
14. Regla práctica para integradores KNX
Una forma sencilla de recordar los flags es esta:
Comunicación = el objeto participa en el bus KNX.
Escritura = el objeto recibe desde el bus.
Transmisión = el objeto envía al bus.
Lectura = el objeto responde cuando alguien pregunta.
Actualización = el objeto sincroniza su valor interno desde una respuesta.
Lectura al Inicio = el objeto solicita el valor después de un reinicio.
En una lógica simple:
Un pulsador normalmente transmite.
Un actuador normalmente recibe comandos.
Un sensor normalmente transmite valores.
Un actuador o gateway normalmente transmite estados reales.
Una visualización normalmente necesita leer o actualizar estados.
Ejemplo rápido:
| Función | Flags típicos |
|---|---|
| Pulsador enviando ON/OFF | C + T |
| Actuador recibiendo ON/OFF | C + W |
| Sensor enviando temperatura | C + T |
| Actuador enviando estado real | C + T + R |
| Visualización recuperando valores | I, según configuración |
| LED de pulsador siguiendo estado | C + W o C + U, según fabricante |
Esta regla evita muchos problemas durante programación, puesta en marcha y mantenimiento.
Conclusión
Los flags en ETS son pequeños ajustes, pero tienen un impacto grande en el funcionamiento real de una instalación KNX.
Definen cómo se comporta cada objeto de comunicación.
La diferencia más importante es entre Escritura y Transmisión.
Escritura significa que el objeto recibe desde el bus.
Transmisión significa que el objeto envía al bus.
Cuando esta diferencia se entiende correctamente, la programación KNX se vuelve más clara, más lógica y mucho más fácil de diagnosticar.
En una instalación KNX profesional, no basta con enlazar direcciones de grupo.
El integrador debe entender qué rol cumple cada objeto:
Quién envía.
Quién recibe.
Quién responde.
Quién actualiza.
Quién recupera valores después de un reinicio.
Un buen proyecto KNX no se basa solo en los dispositivos instalados.
Se basa en una comunicación clara, estable y bien estructurada.
Y los flags de ETS son una de las herramientas clave para lograrlo.
