Llevamos unas entradas viendo los servicios de mensajería en IoT. En esta entrada profundizaremos en los Topics en MQTT, viendo qué son y cómo emplearlos correctamente en nuestros proyectos.
En la primera entrada vimos distintos protocolos de comunicación para IoT. En la anterior presentamos MQTT, el popular protocolo M2M especialmente indicado para aplicaciones de IoT por su sencillez y ligereza.
Recordamos que MQTT es un servicio de mensajería con patrón publicador/suscriptor (pub-sub) que funciona sobre TCP/IP. Es decir, un servidor central, que en MQTT se denomina Broker, recibe los mensajes, los filtra y los distribuye a los clientes.
También recordamos que en MQTT los mensajes transmitidos están formados por una cabecera que contiene, entre otros, el tipo de comando enviado. La otra parte importante del mensaje es el propio contenido o Payload.
Nos quedó ver los Topic, un componente fundamental del protocolo MQTT. En esta entrada veremos qué son, cómo usarlos, y como organizar correctamente su estructura en un sistema IoT.
¿Qué son los Topics en MQTT?
Como hemos dicho, los Broker MQTT aplican un filtrado a los mensajes que son recibidos desde los publicadores, para discriminar a que clientes suscritos es entregado.
En MQTT este filtro se denomina Topic, y simplemente consiste en una cadena de texto UTF-8, y una longitud máxima de 65536 caracteres (aunque lo normal es que sea mucho menor). Se distingue entre mayúsculas y minúsculas.
Los Topics están formados por uno o más “niveles” separados entre sí por una barra inclinada ’/‘. Cada nivel debe está formado por uno o más caracteres.
Por ejemplo, ejemplos de Topic válidos podrían ser,
Casa/Cocina/Temperatura
Casa/Salon/Temperatura
Casa/Salon/PersianaCómo funcionan los Topics en MQTT
El funcionamiento de los Topcis en MQTT es sencillo y transparente. Por un lado el Broker acepta todos los Topics. No es necesario crearlo explícitamente antes de publicar o suscribirse al Broker.
Por su parte, los clientes pueden suscribirse a uno o varios Topic. Para ello, el cliente puede establecer varias suscripciones y/o emplear Wildcards, como veremos en el siguiente apartado.
Finalmente, los clientes publican mensajes indicando un único Topic. El Broker recibe el mensaje y, si encuentra alguna suscripción que cumpla con el filtro del Topic, transmite el mensaje a los clientes suscritos.
Wildcards
Cuando un cliente establece una suscripción puede suscribirse a un Topic específico, o usar Wildcards para suscribirse a múltiples Topic. Existen dos Wildcards que podemos emplear,
Wildcard Nivel único
El carácter + puede ser empleado para sustituir un único nivel en cualquier lugar del Topic.
Por ejemplo:
# patron
Casa/+/Temperatura
# SI cumplen
Casa/Salon/Temperatura
Casa/Cocina/Temperatura
# NO cumplen
Casa/Salon/Nevera/TemperaturaMientras que:
# patron
Casa/Salon/+
# SI cumplen
Casa/Salon/Temperatura
Casa/Salon/Persiana
# NO cumplen
Casa/Salon/Nevera/Temperatura
Casa/Salon/Persiana/MotorWildcard Nivel múltiple
El carácter # puede ser empleado para sustituir cualquier número de niveles y puede usarse únicamente al final del Topic.
Por ejemplo:
Casa/Salon/#
# SI cumplen
Casa/Salon/Temperatura
Casa/Salon/Persiana
# NO cumplen
Casa/Dormitorio/Temperatura
Casa/ComedorLos Wildcards son únicamente para la suscripción. Los mensajes pueden publicarse únicamente contra un Topic.
Recomendaciones al organizar los Topic
El éxito de un sistema de IoT depende enormemente de la arquitectura que diseñemos para la mensajería. En el caso de MQTT es esencial planear y organizar los Topic que vamos a emplear en el proyecto. Hay varios consejos que podemos seguir.
El principal es diseñar el sistema de Topic para que sea ampliable y mantenible. Queremos poder añadir más dispositivos a nuestra red o nuevas funcionalidades, y evitar darnos cuenta en el futuro de que el sistema que elegimos es insuficiente.
De lo contrario, podemos enfrentarnos a la pesadilla de tener que reprogramar todos los dispositivos (cosa que seguramente no podremos hacer), o bien tener que arreglarlo con “ñapas”.
Otro consejo es mantener los Topic lo más pequeños y claros posible. Asimismo, es recomendable usar Topics lo más específicos posibles, evitando enviar mensajes a varios dispositivos y discriminar por el contenido del mensaje.
Así, por ejemplo, si tenéis varios sensores emplear /Salon/Humedad/1/ , /Salon/Humedad/2/ , /Salon/Temperatura/1/ en lugar de usar /Salon/ para todos los dispositivos
Finalmente, otro pequeño consejo es emplear únicamente caracteres ASCII estándar, evitando caracteres especiales e incluso espacios. Esto hará más sencillo la interpretación de Topics, y la interoperabilidad entre lenguajes de programación y dispositivos.
Así, por ejemplo, es preferible emplear /Salon/ frente a /Salón/ y /Humedad/ frente a /Sensor humedad/.
Cómo organizar un API con Topics en MQTT
Ahora que hemos visto qué son los Topic, cómo funcionan y algunas recomendaciones y consejos, podemos plantear un ejemplo de cómo organizar correctamente un sistema de Topics en MQTT de forma que sea ampliable, versátil, y mantenible.
Por supuesto, no existe una única forma y cada maestrillo tiene su librillo. Una tendencia, en mi opinión adecuada, es plantearlo de forma similar a un API REST. Así, dispondremos de niveles en el Topic para identificar cada Endpoint, y el último nivel corresponderá a las acciones que ofrece el Endpoint.
Por ejemplo, en el caso común de querer controlar las instalaciones domóticas de una serie de edificios, un posible diseño de Topic para MQTT sería el siguiente.
Veréis que hemos dejado raíces específicas para Edificio (center) y Habitación (Room). Cada uno de ellos, sigue un identificador, en este caso numérico, aunque por sencillez podéis sustituirlo por un texto (CasaA, CasaB, Salon, Cocina).
Al poner una raíz dejamos libre poder añadir nuevas “familias”, como por ejemplo una infraestructura común como el alumbrado, que no está asociado con ningún edificio.
Posteriormente, definimos las diferentes “subfamilias” de dispositivos (temperatura, luz, etc). Finalmente, terminamos con las acciones posibles en cada dispositivo. Por ejemplo, un hipotético dispositivo de temperatura podría permitir leer la temperatura, o ponerla.
Es una de muchas estructuras posibles, y sois libres de modificarla a según vuestras necesidades. Por ejemplo, podría ser interesante añadir un nuevo nivel de “Planta”. Pero se entiende el concepto de dedicar un rato a planificar el sistema de Topics antes de ponernos a distribuir dispositivos “a lo loco”.
Hasta aquí esta entrada dedicada a los Topic en MQTT y su uso. En la próxima entrada de esta sección de IoT veremos algunos de los principales Broker para MQTT ¡Hasta pronto!