Explorando protocolos: MQTT en IoT

El mundo del Internet de las cosas (IoT) se expande a gran velocidad, y una de las tecnologías clave que permite una comunicación eficiente y confiable entre dispositivos IoT es MQTT, que significa Message Queuing Telemetry Transport. En este blog exploraremos MQTT, desde su historia y evolución hasta su arquitectura, niveles de QoS, topics, payloads y su papel en las aplicaciones de IoT.

¿Qué es MQTT?

MQTT es un protocolo de mensajería ligero y de código abierto, diseñado para una comunicación eficiente y en tiempo real entre dispositivos, especialmente en entornos con recursos limitados. Fue creado por el Dr. Andy Stanford-Clark, de IBM, y Arlen Nipper, de Arcom, a finales de la década de 1990. MQTT se caracteriza por su baja sobrecarga y su consumo mínimo de ancho de banda y de energía, lo que lo convierte en una opción ideal para muchas aplicaciones de IoT.

MQTT ha recorrido un largo camino desde su creación en cuanto a historia y evolución. En un principio se desarrolló para monitorear oleoductos, pero desde entonces se ha convertido en uno de los estándares de comunicación del IoT. El protocolo respondió a la necesidad de una mensajería confiable, de bajo ancho de banda y baja latencia en redes remotas e inestables.

Por qué MQTT es importante en la era del IoT

MQTT es fundamental en muchas aplicaciones de IoT donde se interconectan unos pocos o millones de dispositivos. Su naturaleza ligera y su fiabilidad lo hacen perfecto para diversas aplicaciones de IoT, en las que los dispositivos suelen tener recursos limitados y conectividad intermitente. MQTT garantiza que los datos se transmitan de forma eficiente y segura entre los dispositivos IoT y los sistemas centrales.

Además, la naturaleza independiente del dispositivo de MQTT asegura que equipos de distintos fabricantes se comuniquen sin fricciones, fomentando la interoperabilidad. El lenguaje común que ofrecen los topics y payloads de MQTT promueve un marco de comunicación estandarizado, que permite integrar dispositivos IoT diversos en un ecosistema cohesionado.

Arquitectura de MQTT

Modelo cliente-servidor

MQTT se basa en un modelo cliente-servidor, donde los clientes son los dispositivos o aplicaciones que se comunican mediante MQTT, mientras que el servidor se denomina broker. El broker se encarga de recibir, enrutar y entregar los mensajes a los clientes correspondientes. Los brokers son la columna vertebral de la comunicación MQTT, ya que actúan como intermediarios que gestionan el flujo de mensajes. Los clientes pueden ser publicadores y suscriptores, enviando y recibiendo mensajes a través del broker.

Muchas plataformas de IoT ofrecen un MQTT Broker integrado; un ejemplo es TagoIO, donde puedes integrar tus dispositivos MQTT y crear scripts para manipular datos, crear notificaciones y visualizar dichos datos.

Modelo de comunicación publicar/suscribir

MQTT emplea un modelo de comunicación publicar/suscribir, donde los publicadores envían mensajes sobre topics específicos y los suscriptores expresan interés en topics específicos. Esto desacopla al emisor del receptor, lo que permite una comunicación más escalable y flexible. Por ejemplo, una estación meteorológica podría publicar datos de temperatura en “weather/temperature”, mientras que una aplicación móvil podría suscribirse a ese topic para recibir actualizaciones sobre los cambios de temperatura.

Qué es la calidad de servicio (QoS) de MQTT

MQTT ofrece tres niveles de calidad de servicio (QoS), que determinan las garantías de entrega de los mensajes:

1. QoS 0 - Como máximo una vez: este nivel no garantiza la entrega. El mensaje se envía una vez, y el emisor no espera ninguna confirmación ni garantía de entrega del mensaje. Este nivel es adecuado para datos no críticos en los que la pérdida de mensajes es aceptable.

2. QoS 1 - Al menos una vez: este nivel ofrece entrega garantizada, pero puede generar duplicados. El mensaje se envía al menos una vez, y el emisor espera una confirmación del receptor. Si no se recibe la confirmación, el emisor reenvía el mensaje. Este nivel es apropiado para datos críticos en los que la pérdida de mensajes es inaceptable.

3. QoS 2 - Exactamente una vez: este nivel ofrece entrega garantizada sin duplicados. El mensaje se envía exactamente una vez, y el emisor espera una confirmación del receptor. Si no se recibe la confirmación, el emisor reenvía el mensaje. Este nivel es adecuado para datos críticos con cero tolerancia a la pérdida de mensajes.

La elección del nivel de QoS depende de los requisitos específicos de la aplicación. Seleccionar el nivel de QoS adecuado influye en la entrega de mensajes, afectando la duplicación de mensajes y la sobrecarga de la red.

Topics y payloads de MQTT

Los topics y los payloads de MQTT son dos componentes esenciales del protocolo MQTT. Los topics son como canales en los que se publican y desde los que se suscriben los mensajes. Son jerárquicos y ayudan a organizar los mensajes.

Los payloads de los mensajes contienen los datos reales que se van a transmitir. Según los requisitos de la aplicación, pueden tener distintos formatos, como JSON, XML o binario. El formato del payload debe elegirse según las necesidades de la aplicación y los recursos disponibles.

Un vistazo a casos de uso reales con MQTT

A medida que exploramos la eficiencia de MQTT en la comunicación IoT, es clave examinar cómo este protocolo se integra sin fricciones con dispositivos de distintos fabricantes como Dragino, RAK Wireless, Seeed Studio y Khomp. Veamos casos de uso reales que muestran la versatilidad de MQTT en los dispositivos IoT.

1. Sistemas SCADA con MQTT (Supervisory Control and Data Acquisition): MQTT suele integrarse en sistemas SCADA para facilitar el intercambio de datos en tiempo real entre los dispositivos de campo y el sistema central de monitoreo. Ayuda a recopilar y gestionar datos de diversos sensores y dispositivos distribuidos en un entorno industrial.

2. Monitoreo en salud con sensores portátiles: los escenarios de salud incluyen sensores portátiles de distintos proveedores, cada uno con capacidades de monitoreo propias. Sin importar la marca, los sensores portátiles pueden publicar datos de signos vitales en un topic estandarizado como “health/patient1/vital-signs”. La interoperabilidad de MQTT garantiza una integración sin fricciones, lo que permite a los profesionales de la salud monitorear a los pacientes con tipos de sensores diversos.

3. Monitoreo ambiental con diversos sensores: el monitoreo ambiental combina sensores de varios fabricantes, que ofrecen parámetros como la calidad del aire, los niveles de ruido o la detección de radiación. La comunicación basada en topics de MQTT permite que los sensores ambientales publiquen datos en topics compartidos como “environment/air-quality” o “environment/noise-levels”. Esta interoperabilidad facilita la integración de diversos sensores ambientales en un sistema de monitoreo completo.

¿Qué le depara el futuro a MQTT?

MQTT destaca como un protocolo de comunicación muy ventajoso para las soluciones de IoT, y atrae atención como opción preferida. Aun así, el amplio terreno de los protocolos de IoT presenta varias alternativas, siendo CoAP un competidor destacado. Una característica distintiva de CoAP es su capacidad de operar sobre TCP/IP y UDP, lo que lo diferencia de MQTT, que se asocia principalmente con TCP/IP. La evolución constante del panorama del IoT añade incertidumbre sobre qué protocolo de comunicación terminará siendo el más adoptado. A medida que los avances tecnológicos sigan dando forma al ecosistema del IoT, la interacción dinámica entre MQTT, CoAP y otros competidores determinará al final qué protocolo se ajusta mejor a las diversas y cambiantes necesidades de las aplicaciones de IoT.