Los telegramas en KNX

Las dos últimas semanas he estado introduciendo el sistema KNX y sus características. Así, primero hice una introducción general y hablé de su topología para a continuación presentar su direccionamiento y acceso al medio. Hoy quiero finalizar el apartado teórico de esta tecnología hablando de cómo KNX trabaja con bloques de información: te presento los telegramas.

Siempre que se detecte un evento se producirá el envío de un mensaje o telegrama. Por ejemplo, detección de niveles de gas inapropiados o activación de un pulsador. El dispositivo encargado de iniciar la comunicación (emisor) es un sensor que comprueba la disponibilidad del bus durante un tiempo t1 y envía el telegrama. Si no hay colisiones, a la finalización de la transmisión espera un intervalo de tiempo t2 la recepción del reconocimiento (Ack). Si la recepción es incorrecta, no se recibe reconocimiento (o bien se recibe no reconocimiento), y la transmisión  se reintenta hasta tres veces.

Siempre que se detecte un evento se producirá el envío de un mensaje o telegrama.

[Tweet]

Todos los dispositivos direccionados envían el reconocimiento simultáneamente.

[caption id="attachment_754" align="aligncenter" width="888"] Secuencia de Envío de Telegrama[/caption]

Los telegramas se transmiten en modo asíncrono, a una velocidad de 9600 baudios, donde cada palabra consta de 1 bit de inicio, 8 bits de datos, 1 bit de paridad par,1 bit de parada y una pausa de 2 bits hasta la siguiente transmisión.

[caption id="attachment_753" align="aligncenter" width="883"] Formato de transmisión de 1 byte[/caption]

De este modo la transmisión de un byte supone un tiempo de 1,35 ms, y la de un telegrama completo entre 20 y 40 ms (la mayoría de las órdenes son de marcha-paro y suponen un tiempo de envío de 20 ms).

[caption id="attachment_751" align="aligncenter" width="961"] Formato de un telegrama[/caption]

El telegrama que se transmite por el bus, y que contiene la información específica sobre el evento que se ha producido, tiene siete campos, seis de control para conseguir una transmisión fiable y un campo de datos útiles con el comando a ejecutar.

Control. Este campo de 8 bits incluye la prioridad que dicho telegrama tiene al ser enviado según el tipo de función (alarma, servicios del sistema o servicios habituales). El bit de repetición se pone a cero en caso de repetirse algún envío a causa del no reconocimiento de alguno de los destinatarios. De este modo se evita que los mecanismos que ya han ejecutado la orden la vuelvan a repetir.

Dirección de origen. El dispositivo que retransmite la trama envía su dirección física (4 bits con el área, 4 bits de identificador de línea y 8 bits de identificador de dispositivo), de modo que se conozca el emisor del telegrama en las tareas de mantenimiento.

Dirección de destino. La dirección de destino puede ser de dos tipos, en función del valor que tome el bit de mayor peso de este campo (bit 17). Si tiene valor ‘0’, se trata de una dirección física, y el telegrama se dirige únicamente a un dispositivo. Si tiene valor ‘1’, se trata de una dirección de grupo, y el telegrama se dirige a todos los mecanismos que deben escucharlo (los que tengan esa dirección de grupo).

[caption id="attachment_750" align="aligncenter" width="888"] Formato del Campo de Datos[/caption]

Longitud e información útil. Contiene los datos necesarios para la ejecución de órdenes y transmisión de valores. En los cuatro bits de longitud se indica cuántos bytes contiene el campo de datos (0 = 1 byte, 15 = 16 bytes). El campo de datos útiles contiene el tipo de comando (sólo hay cuatro) y los datos, de acuerdo con el EIB Interworking Standard (EIS).

El EIS contiene los datos útiles para cada función asignada a los objetos de comunicación. Según este estándar existen siete tipos diferentes, cada uno asignado a un tipo de acción de control (conmutación, regulación de luz, envío de valor absoluto, envío de valor en punto flotante, etc). De este modo se garantiza la compatibilidad entre dispositivos del mismo tipo de diferentes fabricantes.

Los objetos de comunicación son instancias de clases definidas en el estándar, y son los programas almacenados en la memoria de los dispositivos para realizar una determinada acción.

Campo de comprobación. Consiste en un byte que se obtiene del cálculo de la paridad longitudinal par (LRC2) de todos los bytes anteriores incluidos en el telegrama. Cuando un dispositivo recibe el telegrama, comprueba si éste es correcto a partir del byte de comprobación. Si dicha recepción es correcta, se envía un reconocimiento. De lo contrario se envía un no reconocimiento (NAK) para que el emisor repita el envío. Si el dispositivo está ocupado envía un código Busy para que el emisor reintente la transmisión tras un pequeño retardo.

[caption id="attachment_752" align="aligncenter" width="677"] Tipos de Respuesta Reconocimiento[/caption]

Con este post doy por finalizada la explicación teórica del que considero el protocolo de comunicación más importante dentro del mundo de la domótica, KNX. En próximas entregas hablaré de implementaciones prácticas del protocolo domótico. Sin embargo, antes hay que tomarse un respiro de tanto KNX, así que en próximos posts hablaré de temáticas diferentes. Mientras tanto, ¿ya te has inscrito a la mailist? Si no es así, no se a que estás esperando. Quiero darte las gracias por compartir esta entrada en tus redes sociales: cada día somos más :)

Un saludo! ;)

Actualización:

Gracias ras por tus aportes y correcciones