Protocolo MQTT

3 respuestas

MQTT son las siglas de Message Queue Telemetry Transport y tras ellas se encuentra un protocolo ideado por IBM y liberado para que cualquiera podamos usarlo enfocado a la conectividad Machine-to-Machine (M2M).

Web: https://mqtt.org/ 

MQTT fue creado por el Dr. Andy Stanford-Clark de IBM y Arlen Nipper de Arcom — ahora Eurotech — en 1999 como una forma rentable y confiable de conectar los dispositivos de monitoreo utilizados en las industrias del petróleo y el gas a servidores empresariales remotos. Cuando se les planteó el reto de encontrar la manera de enviar los datos de los sensores de los oleoductos en el desierto a sistemas SCADA externos (control de supervisión y adquisición de datos), decidieron utilizar una topología de publicación/suscripción basada en TCP/IP que se basaría en los eventos para mantener bajos los costos de transmisión de los enlaces satelitales.

Aunque MQTTT todavía está estrechamente asociado con IBM, ahora es un protocolo abierto que es supervisado por la Organización para el Avance de los Estándares de Información Estructurada (OASIS).

Web: http://mqtt.org/ 

Está enfocado al envío de datos en aplicaciones donde se requiere muy poco ancho de banda. Además, sus características le permiten presumir de tener un consumo realmente bajo así como precisar de muy pocos recursos para su funcionamiento.

Estas características han hecho que rápidamente se convierta en un protocolo muy empleado en la comunicación de sensores y, consecuentemente, dentro del Internet de las Cosas.

MQTT es un protocolo pensado para IoT que está al mismo nivel que HTTP o CoAP:

Comparativa MQTT y CoAP:

Un aspecto importante a tener en cuenta de los dispositivos IoT no es solamente el poder enviar datos al Cloud/Servidor, sino también el poder comunicarse con el dispositivo, en definitiva la bidireccionalidad. Este es uno de los beneficios de MQTT: es un modelo brokered, el cliente abre una conexión de salida al bróker, aunque el dispositivo esté actuando como Publisher o subscriber. Esto normalmente evita los problemas con los firewalls porque funciona detrás de ellos o vía NAT.

Cómo funciona MQTT

En el caso de que la comunicación principal se base en HTTP, la solución tradicional para enviar información al dispositivo sería HTTP Polling. Esto es ineficiente y tiene un coste elevado en aspectos de tráfico y/o energía. Una manera más novedosa de hacerlo sería con el protocolo WebSocket, que permite crear una conexión HTTP completa bidireccional. Esto actúa de canal socket (parecido al canal típico TCP) entre el servidor y el cliente. Una vez establecido, ya es trabajo del sistema escoger un protocolo para hacer un túnel sobre la conexión.

El Transporte de telemetría de cola de mensajes (MQTT) es un protocolo de código abierto que se desarrolló y optimizó para dispositivos restringidos y redes de bajo ancho de banda, alta latencia o poco confiables. Es un transporte de mensajería de publicación/suscripción que es extremadamente ligero e ideal para conectar dispositivos pequeños a redes con ancho de banda mínimo. El MQTT es eficiente en términos de ancho de banda, independiente de los datos y tiene reconocimiento de sesión continua, porque usa TCP. Tiene la finalidad de minimizar los requerimientos de recursos del dispositivo y, a la vez, tratar de asegurar la confiabilidad y cierto grado de seguridad de entrega con calidad del servicio.

El MQTT se orienta a grandes redes de dispositivos pequeños que necesitan la supervisión o el control de un servidor de back-end en Internet. No está diseñado para la transferencia de dispositivo a dispositivo. Tampoco está diseñado para realizar «multidifusión» de datos a muchos receptores. El MQTT es simple y ofrece pocas opciones de control. Las aplicaciones que usan MQTT, por lo general, son lentas en el sentido de que la definición de «tiempo real» en este caso se mide habitualmente en segundos.

Para filtrar los mensajes que son enviados a cada cliente los mensajes se disponen en topics organizados jerárquicamente. Un cliente puede publicar un mensaje en un determinado topic. Otros clientes pueden suscribirse a este topic, y el broker le hará llegar los mensajes suscritos.

Los clientes inician una conexión TCP/IP con el broker, el cual mantiene un registro de los clientes conectados. Esta conexión se mantiene abierta hasta que el cliente la finaliza. Por defecto, MQTT emplea el puerto 1883 y el 8883 cuando funciona sobre TLS.

Para ello el cliente envía un mensaje CONNECT que contiene información necesaria (nombre de usuario, contraseña, client-id…). El broker responde con un mensaje CONNACK, que contiene el resultado de la conexión (aceptada, rechazada, etc).

Para enviar los mensajes el cliente emplea mensajes PUBLISH, que contienen el topic y el payload.

Para suscribirse o desuscribirse se emplean mensajes SUBSCRIBE y UNSUSCRIBE, que el servidor responde con SUBACK y UNSUBACK.

Por otro lado, para asegurar que la conexión está activa los clientes mandan periódicamente un mensaje PINGREQ que es respondido por el servidor con un PINGRESP. Finalmente, el cliente se desconecta enviando un mensaje de DISCONNECT.

Más información:

MQTT Protocolo para IoT

MQTT es un protocolo que está cobrando mucha importancia en la industria (IIoT). MQTT (Message Queuing Telemetry Transport, ‘Cola de mensajes telemetría y transporte’) es un protocolo publicar/suscribir diseñado para SCADA. Se centra en un mínimo encabezado (dos bytes) y comunicaciones confiables. También es muy simple. Tal como HTTP, la carga MQTT es específica para la aplicación, y la mayoría de las implementaciones usan un formato JSON personalizado o binario.

MQTT en PLCs: https://www.youtube.com/watch?v=aX20J-sLyKU 

Comparativa MQTT y Modbus: http://inubo.es/noticia/comparativa-entre-mqtt-y-modbus-como-protocolos-iot 

MQTT es interesante usarlo cuando el ancho de banda bajo y no conozca su infraestructura. Asegúrese de que su proveedor tenga un broker MQTT a quien le pueda publicar información, y siempre asegure la comunicación con TLS (Transport Layer Security, ‘seguridad en la capa de transporte’).

Por ejemplo, MQTT sería una buena opción para monitorizar y controlar los paneles solares. MQTT es un protocolo de publicación/suscripción con brokers de mensajes centrales. Cada panel solar puede contener un nodo IoT que publique mensajes de tensión, corriente y temperatura.

MQTT está diseñado para minimizar el ancho de banda, lo que lo convierte en una buena opción para el monitoreo satelital de la línea de transmisión, pero hay una trampa. La ausencia de metadatos en las cabeceras de los mensajes significa que la interpretación de los mensajes depende completamente del diseñador del sistema.

Para compensar las redes poco fiables, MQTT soporta tres niveles de Calidad de Servicio (QoS):

  • Disparar y olvidar (0) – Fire and Forget – At most once
  • Al menos una vez (1) – At least once
  • Exactamente una vez (2) – Exactly once

Si se solicita el nivel de calidad de servicio 1 ó 2, el protocolo gestiona la retransmisión de mensajes para garantizar la entrega. La calidad de servicio puede ser especificada por los clientes de publicación (cubre la transmisión del publicador al broker) y por los clientes suscriptores (cubre la transmisión de un broker a un suscriptor).

MQTT QoS 2 aumentará la latencia porque cada mensaje requiere dos handshake completos de ida y vuelta del remitente al receptor (cuatro en total del publicador al suscriptor).

En un patrón de publicación/suscripción es difícil saber la diferencia entre «Ha pasado mucho tiempo desde que supe de mi publicador» y «Mi publicador murió». Ahí es donde entra en juego la Última Voluntad y el Testamento (LWT) de MQTT. Los clientes pueden publicar mensajes sobre temas específicos (por ejemplo, aisle15/rack20/panel5/FalloSensor) para que se entreguen si se desconectan sin enviar un mensaje de «desconexión». Los mensajes se almacenan en el broker y se envían a cualquier persona que se haya suscrito al tema.

MQTT de un vistazo

  • Ancho de banda muy bajo
  • TCP/IP
  • Publicar/suscribir transferencia de mensajes
  • Topología de muchos a muchos a través de un broker central
  • Sin metadatos
  • Tres niveles de QoS
  • Última Voluntad y Testamento revela nodos desconectados

Las ventajas de usar el protocolo MQTT son:

  • Es asíncrono con diferentes niveles múltiples de calidad del servicio, lo que resulta ser importante en los casos donde las conexiones de Internet son poco confiables.
  • Envía mensajes cortos que se vuelven adecuados para las situaciones de un bajo ancho de banda.
  • No se requiere de mucho software para implementar a un cliente, lo cual lo vuelve fantástico para los dispositivos como Arduino con una memoria limitada.
  • Podemos cifrar los datos enviados y usar usuario y password para proteger nuestros envíos.

Si quisiera grabar en una BBDD con MQTT, un suscriptor a una serie de topics se encarga de grabar los datos cada vez que cambia un valor o cada cierto tiempo, por ejemplo con un script de python o ejecutando Node-RED en una máquina virtual o en el propio servidor (o Raspberry Pi) donde corre el broker (Mosquitto):

NodeRed no es más que un software que se instala en un nodo aunque se instale en el mismo servidor que el broker.

Cinco cosas a saber de MQTT: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en 

Buen artículo sobre MQTT: https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport 

Software MQTT: https://mqtt.org/software/ 

Recursos MQTT:

Para ampliar información de MQTT en Arduino y Raspberry Pi:

Buenos artículos de MQTT en español:

Arquitectura MQTT

MQTT (Message Queue Telemetry Transport), un protocolo usado para la comunicación machine-to-machine (M2M) en el «Internet of Things». Este protocolo está orientado a la comunicación de sensores, debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos (CPU, RAM, …).

Un ejemplo de uso de este protocolo es la aplicación de Facebook Messenger tanto para android y Iphone. La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de servidor o «broker». El broker es el encargado de gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes mandan periódicamente un paquete (PINGREQ) y esperan la respuesta del broker (PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.

En esta forma de comunicación se desacoplan los clientes que publican (Publisher) de los que consumen los datos (Suscribers). Eso significa que los clientes no se conocen entre ellos unos publican la información y otros simplemente la consumen, simplemente todos tienen que conocer al message broker.

El desacoplamiento se produce en tres dimensiones:

  • En el espacio: El publicador y el suscriptor no tienen porqué conocerse. No hace falta saber la dirección IP del contrario, ubicación, ni nada, el publicador manda el dato y lo entrega el broker. Muy interesante si cambio el equipo suscriptor de IP o de ubicación.
  • En el tiempo: El publicador y el suscriptor no tienen porqué estar conectados en el mismo momento. Como el email, que lee el dato publicado cuando el suscriptor está disponible, pero necesita el retained u otro método con persistencia de los admitidos por MQTT.
  • En la sincronización: las operaciones en cualquiera de los dos componentes no quedan interrumpidas mientras se publican o se reciben mensajes.

Es precisamente el broker el elemento encargado de gestionar la red y transmitir los mensajes.

Una característica interesante es la capacidad de MQTT para establecer comunicaciones cifradas lo que aporta a nuestra red una capa extra de seguridad.

MQTT server network Architecture: https://cirrus-link.com/mqtt-server-network-architecture/ 

  • Cloud – Hosted
  • Private – On Premise
  • Híbrido

Topics MQTT

La comunicación se basa en unos «topics» (temas), que el cliente que publica el mensaje crea y los nodos que deseen recibirlo deben suscribirse a él. La comunicación puede ser de uno a uno, o de uno a muchos.

Dentro de la arquitectura de MQTT, es muy importante el concepto «topic» o «tema» en español ya que a través de estos «topics» se articula la comunicación puesto que emisores y receptores deben estar suscritos a un «topic» común para poder entablar la comunicación. Este concepto es prácticamente el mismo que se emplea en colas, donde existen un publicadores (que publican o emiten información) y unos suscriptores (que reciben dicha información) siempre que ambas partes estén suscritas a la misma cola.

Los Broker MQTT aplican un filtrado a los mensajes que son recibidos desde los publicadores, para discriminar a qué 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.

Este tipo de arquitecturas, lleva asociada otra interesante característica: la comunicación puede ser de uno a uno o de uno a muchos.

Un «topic» se representa mediante una cadena y tiene una estructura jerárquica. Cada jerarquía se separa con ‘/’.

Por ejemplo, «edificio1/planta5/sala1/raspberry2/temperatura» o «/edificio3/planta0/sala3/arduino4/ruido«. De esta forma se pueden crear jerarquías de clientes que publican y reciben datos, como podemos ver en la imagen:

De esta forma un nodo puede subscribirse a un «topic» concreto («edificio1/planta2/sala0/arduino0/temperatura»)  o  a varios («edificio1/planta2/#»).

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. Los clientes pueden suscribirse a uno o varios Topic. Para ello, el cliente puede establecer varias suscripciones y/o emplear Wildcards.

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.

Un broker no necesita mantener una lista de los temas a los que se han publicado los mensajes, sólo comprueba la lista de temas a los que está suscrito cada cliente cuando llega un mensaje.

Un topics especiales son los topics de sistema, que son aquello que publica el propio broker para mandar información de su estado. Estos están bajo la jerarquía de $SYS: https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics

Existen dos comodines en MQTT para suscribirse a varios topics (no se pueden usar para publicar):

  • Multi-level Wildcard: # (se suscribe a todos los hijos bajo esa cola)
  • Single Level Wildcard: + (se suscribe solo a ese nivel)

No se puede publicar con wildcards:

Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier suscripción de root wild card. Normalmente, el $ se utiliza para transportar mensajes específicos del servidor o del sistema.

Ejemplos de Topics MQTT Válidos:

  • casa/prueba/topic
  • casa/+/topic
  • casa/#
  • casa/+/+
  • +/#
  • #

Explicación del comodín de single level:

Entender los topics de MQTT: http://www.steves-internet-guide.com/understanding-mqtt-topics/

Diseño de Estructura de Topics

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.

Es importante diseñar el sistema de Topics 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.

Mantener los Topic lo más pequeños y claros posible. Un topic debe dar la información clara del dato que publica. Es recomendable usar Topics lo más específicos posibles, evitando enviar mensajes a varios dispositivos y discriminar por el contenido del mensaje.

Emplear únicamente caracteres ASCII estándar en los topics, evitando caracteres especiales e incluso espacios. Esto hará más sencillo la interpretación de Topics desde los dispositivos, y la interoperabilidad entre lenguajes de programación y dispositivos.

En el caso de grandes estructuras de dispositivos o conectividad entre aplicaciones, el siguiente esquema de división de Topics funciona muy bien en múltiples aplicaciones: 

protocol_prefix/src_id/dest_id/message_id/extra_properties

  • protocol_prefix se usa para diferenciar entre diferentes protocolos/aplicaciones que se pueden usar al mismo tiempo
  • src_id es el ID del cliente mqtt que publica el mensaje. Se espera que sea el mismo que el «ID de cliente» que se usa para conectarse al broker MQTT. Permite un control rápido de ACL para verificar si el cliente puede publicar un tema específico.
  • dest_id es el ID de cliente de la unidad de «destino», es decir, a quién está destinado el mensaje. También permite un control rápido de ACL en el broker para determinar si el cliente puede suscribirse a un tema en particular. Puede haber topics de «destino» reservados para especificar que el mensaje se transmite a cualquier interesado. Por ejemplo el topic “todos”.
  • message_id es el ID real del mensaje dentro del protocolo utilizado. Por lo general, usa un valor numérico (como una cadena, por supuesto), porque el dispositivo IoT u otro sistema embebido que está conectado al broker MQTT puede tener otros enlaces de E/S y usar el mismo protocolo (pero con un marco de transporte diferente) para controlar el dispositivo utilizando estos otros enlaces de E/S. Usualmente usar ID de mensajes numéricos en tales enlaces de comunicación.
  • extra_properties es un subtema opcional que se puede utilizar para comunicar otra información adicional específica de MQTT (por ejemplo, pares clave=valor separados por comas). Un buen ejemplo sería informar la marca de tiempo del mensaje cuando realmente fue enviado por el cliente. En el caso de mensajes «retenidos», puede ayudar a identificar la relevancia del mensaje recibido. Con el protocolo MQTTv5, la necesidad de este subtema puede desaparecer porque habrá otra forma de comunicar propiedades adicionales.

En otros casos para dispositivos IoT que queramos controlar, el dispositivo (dev) podría suscribirse (sub) al tema de control y publicar (pub) al tema de estado.:

  • pub: clients/dev/dev_id/status
  • sub: clients/dev/dev_id/control

De esta manera, la lógica sub, pub es muy simple tanto para clientes como para dispositivos.

Más información: https://www.luisllamas.es/que-son-y-como-usar-los-topics-en-mqtt-correctamente/ 

Escalado MQTT 

MQTT me permite gran escalabilidad. Añadir un nuevo Arduino o un suscriptor es muy sencillo dentro de la jerarquía vista

Con escalable me refiero a la capacidad que tiene un sistema para ser ampliado. Los sistemas de sensores en general, particularmente en nuestro caso hablamos del mundillo del Internet de las Cosas, se caracterizan por enviar muchos datos de pequeño tamaño en tiempo real ya que hay muchos sensores transmitiendo simultáneamente y cada breves periodos de tiempo, cuya información necesita ser consumida por otros elementos en tiempo real.

En una Arquitectura basada en Broker es fundamental evitar el SPOF (punto único de fallo). 

En el contexto MQTT hay 2 estrategias principales:

  • Bridging: hace forward de mensajes a otro bróker MQTT. Es la solución de HiveMQ, Mosquitto, IBM MQ
  • Clustering: soportando el añadido dinámico de nodos al cluster. Lo usa ActiveMQ, HiveMQ o RabbitMQ.

Cuando un sistema de estas características se empieza a saturar se bloquean las comunicaciones y se pierde la característica de «tiempo real».

Hasta ahora, todos los sistemas que habíamos visto se basaban en un cliente que se comunicaba con un servidor. Si cualquier cliente se intenta comunicar con un servidor que está procesando tanta información que, en ese momento, no es capaz de trabajar con más contenido, el sistema entero fallará, o bien porque se satura y bloquea a nivel global o porque empieza a descartar aquella información que no puede procesar (lo que es inadmisible en muchos caso, imagina una alarma de Riesgo de Explosión en tu cocina porque se ha detectado una fuga de gas…).

Existen varias formas de abordar esta problemática pero, a día de hoy, una de las más empleadas es usar sistemas de colas donde se deja toda la información y el encargado de procesarla va «sacando» de esta cola la información. De esta manera, si ponemos más «encargados de procesamiento» son capaces de vaciar más rápido la cola si viésemos que está se está empezando a llenar y, de cara a los sensores, no sería necesario hacer ningún cambio, ya que ellos siempre envían al mismo sitio.

MQTT no hace exactamente lo mismo ya que, para empezar, no hay colas sino «topics» pero la filosofía es muy parecida, permitiendo a grandes sistemas operar con total fluidez y, junto con sus optimizaciones que buscan entre otras cosas reducir consumos y tamaños de trama para poder operar en elementos embebidos, es el motivo por el que es un protocolo tan empleado en comunicaciones M2M.

Además, nos permite una gestión de la seguridad razonablemente sencilla que facilita que nuestros sistemas se comporten de una forma más robusta.

MQTT será el nexo entre hardware (sensor) y todos los elementos típicos del mundo software (servidores, bases de datos, Big Data). En esta capa nos preocupamos de que la información llegue a un sistema que posteriormente se ocupa de distribuirlo entre las demás partes y nos da igual lo que haya a partir de ese momento y su tamaño. Puede que no tengamos nada más que una web de visualización o puede que tengamos un complejo sistema de Machine Learning y Big Data. Puede que seamos un particular enviando un dato de temperatura a un panel de visualización en su Raspberry o puede que seamos una multinacional que controla en tiempo real su producción de amoniaco a nivel global bajando y subiendo la carga de producción en sus diferentes fábricas según los costes de transporte y el consumo de sus diferentes centros de distribución. Nos es lo mismo a este nivel porque nosotros hacemos sólo una cosa y la hacemos bien: enviar datos de un dispositivo hardware a un sistema mucho mayor. Es lo que se llama microservicios que ha popularizado netflix (http://enmilocalfunciona.io/arquitectura-microservicios-1/) 

Interesante artículo a la hora de usar MQTT sobre la escalibilidad: https://www.iotforall.com/mqtt-broker-iot-scalability/

Las cargas de la plataforma basada en MQTT aumentan en n al cuadrado. Por ejemplo, supongamos un escenario extremo en el que hay dos clientes en los que cada uno se suscribe a todos los temas posibles. Cuando un cliente publica un mensaje, el broker necesita recibir un mensaje y otro cliente también necesita recibir el mensaje. Esto significa que un mensaje enviado podría resultar en dos transmisiones. Lo mismo ocurre con el otro cliente, por lo que son cuatro mensajes en total para un sistema de dos clientes.

Para un sistema de tres clientes, este número se convierte en nueve mensajes en total (es decir, tres mensajes por cliente). El simple hecho de tener 10 dispositivos conectados significa que el intermediario de mensajes debe ser capaz de manejar 10*10 (es decir, 100 mensajes, etc.).

Cuando la cantidad de clientes MQTT comience a crecer, la carga en el broker de mensajes, el sistema general y la plataforma crecerán casi exponencialmente.

Siempre tener esto en cuenta cuando escale cualquier plataforma IoT que se base en MQTT en las etapas posteriores o agregue más dispositivos.

Protocolo MQTT

MQTT está diseñado para requerir una sobrecarga mínima del protocolo para cada paquete con el fin de preservar el ancho de banda para los dispositivos embebidos con recursos limitados. Es un marco de trabajo realmente sencillo para la gestión de redes mesh de dispositivos habilitados para TCP.

Los mensajes MQTT se entregan asincrónicamente («push») a través de la arquitectura publish subscribe. El protocolo MQTTT funciona intercambiando una serie de paquetes de control MQTT de una manera definida. Cada paquete de control tiene un propósito específico y cada bit del paquete se crea cuidadosamente para reducir los datos transmitidos a través de la red. 

Publish and subscribe:

MQTT specificaction: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html 

Una sesión MQTT se divide en cuatro etapas: conexión, autenticación, comunicación y terminación. Un cliente comienza creando una conexión TCP/IP con el broker utilizando un puerto estándar o un puerto personalizado definido por los operadores del broker. Al crear la conexión, es importante reconocer que el servidor puede continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada.

Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor.

MQTT es llamado un protocolo ligero porque todos sus mensajes tienen una pequeña huella de código. Cada mensaje consta de una cabecera fija, una cabecera variable opcional, una carga útil de mensaje limitada a 256 MB de información y un nivel de calidad de servicio (QoS).

MQTTT soporta BLOBS (Binary Large Object) de mensajes de hasta 256 MB de tamaño. El formato del contenido es específico de la aplicación. Las suscripciones de temas se realizan utilizando un par de paquetes SUBSCRIBE/SUBACK. La anulación de la suscripción se realiza de forma similar utilizando un par de paquetes UNSUBSCRIBE/UNSUBACK.

Durante la fase de comunicación, el cliente puede realizar operaciones de publicación, suscripción, cancelación (unsuscribe) y ping. La operación de publicación envía un bloque binario de datos, el contenido, a un topic  definido por el publisher.

La operación de ping al servidor del broker usando una secuencia de paquetes PINGREQ/PINGRESP, que se usa para saber si está viva la conexión. Esta operación no tiene otra función que la de mantener una conexión en vivo y asegurar que la conexión TCP no ha sido apagada por una pasarela o un router.

Cuando un publicador o suscriptor desea finalizar una sesión MQTT, envía un mensaje DISCONNECT al broker y, a continuación, cierra la conexión. Esto se denomina “graceful shutdown” porque le da al cliente la posibilidad de volver a conectarse fácilmente al proporcionarle su identidad de cliente y reanudar el proceso donde lo dejó.

Si la desconexión ocurre repentinamente sin tiempo para que un publisher envíe un mensaje DISCONNECT, el broker puede enviar a los suscriptores un mensaje del publisher que el broker ha almacenado previamente en caché. El mensaje, que se llama testamento, proporciona a los suscriptores instrucciones sobre qué hacer si el editor muere inesperadamente.

MQTT tiene 14 tipos de mensajes, normalmente un usuario sólo usa los mensajes de CONNECT, PUBLISH, SUBSCRIBE Y UNSUBSCRIBE. Si queréis conocer los tipos de mensajes podéis consultarlos en: https://dzone.com/refcardz/getting-started-with-mqtt

El identificador de cliente (ClientId) identifica a cada cliente MQTT que se conecta a un broker MQTT. El broker usa el ClientID para identificar al cliente y el estado actual del cliente. Por lo tanto, este ID debe ser único por cliente y broker. En MQTT 3.1.1, puede enviar un ClientId vacío, si no necesita que el broker mantenga un estado. El ClientId vacío da como resultado una conexión sin ningún estado. En este caso, el indicador “clean session” debe establecerse en verdadero o el broke rechazará la conexión.

El parámetro de ClientId es muy importante cuando queremos tener persistencia en datos y que el cliente pueda recuperar datos no obtenidos mientras estaba desconectado, usado junto la QoS2.

Recordar que cada cliente que se conecte a un broker debe tener un ClientId diferente.

Glosario MQTT: https://www.hivemq.com/mqtt/ 

Más información: https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport 

Para saber más sobre el protocolo MQTT y aplicaciones:

MQTT V5

MQTT se ha convertido en un protocolo popular para conectar dispositivos de Internet de las cosas (IoT) a la nube. MQTT se desarrolló originalmente en 1999 para monitorear oleoductos y oleoductos a través de redes satelitales. En ese momento, la necesidad era un protocolo que fuera eficiente para dispositivos remotos con fuentes de energía limitadas, que tuviera un uso eficiente del ancho de banda y que pudiera operar a través de conexiones de red poco confiables. Cuando se desarrolló MQTT, el término IoT no se había acuñado, la computación en la nube no existía y el conjunto diverso de aplicaciones para IoT no había surgido.

Por estos motivos, era necesario actualizar el protocolo MQTT para abordar algunas de las características faltantes necesarias para alojar MQTT en plataformas en la nube a gran escala y para manejar aplicaciones IoT adicionales. En 2015/2016, se comenzó a trabajar dentro de OASIS en una nueva versión de la especificación, denominada MQTT 5. En marzo de 2019, MQTT 5 fue ratificado como estándar oficial de OASIS.

Mosquitto soporta MQTT V5 

Hay 5 características clave que mejoran el manejo de errores, la escalabilidad y la flexibilidad del despliegue de los sistemas MQTT:

  • Sesión y caducidad del mensaje: MQTT 5 permite ahora que cada sesión y mensaje especifique un límite de tiempo. Si un mensaje no se entrega en un período de tiempo determinado, se borrará. Esto puede ser muy importante para los casos de uso crítico de seguridad si un mensaje necesita llegar dentro de un cierto período de tiempo.
  • Suscripciones compartidas: Las suscripciones compartidas permiten que varias instancias del cliente MQTT compartan las suscripciones del mismo tema de un broker MQTT. Esta característica es muy útil si un cliente MQTT ha sido configurado para transmitir datos MQTT en un sistema empresarial back-end, como una base de datos. Diferentes clientes MQTT que comparten las mismas suscripciones pueden ser desplegados a través de diferentes nodos del clúster para ayudar con la escalabilidad y la alta disponibilidad.
  • Reconocimientos negativos: Un broker MQTT que soporta MQTT 5 puede ahora enviar lo que se llama un acuse de recibo negativo para rechazar ciertos tipos de mensajes, tales como la máxima calidad de servicio, el tamaño máximo de los mensajes y las características no soportadas en el broker. El rechazo de un mensaje que excede el tamaño máximo del mensaje es útil para identificar a los clientes MQTT que podrían haberse convertido en maliciosos.
  • Indicadores de formato de carga útil (Payload): MQTT siempre ha sido agnóstico en cuanto a la carga útil, pero MQTT 5 ahora permite la adición de indicadores de formato de carga útil, valores binarios o texto. Esto facilitará el procesamiento del mensaje MQTT.
  • Propiedades del usuario: Además de los indicadores de formato de carga útil, los mensajes MQTT 5 pueden ahora incluir propiedades de usuario que añaden una propiedad clave-valor al encabezamiento del mensaje. Estas propiedades permiten que se añada información específica de la aplicación a cada cabecera de mensaje.

Aspectos más relevantes en MQTT V5:

  • Clean Sessions pasa a llamarse Clean Start y además al poner clean start a falso, debe darse un “session expiry value”, en caso contrario es 0 y se comporta como siempre. Más información en http://www.steves-internet-guide.com/mqttv5-clean-start-clean-sessions-and-session-expiry/ 
  • Restricción de tamaño de mensaje en cliente. El cliente le dice al servidor el tamaño máximo del mensaje
  • Se puede especificar un delay del envío de mensaje de ultimo deseo (will message) para que no mande mensajes el microcortes
  • Propiedades de usuario: http://www.steves-internet-guide.com/examining-mqttv5-user-properties/, se manda información fuera del payload con información del usuario en formato json. Está disponible en todos los mensajes, incluidos los de acknoledge
  • Server Redirect, en la conexión permite al servidor redireccionar a otro broker.
  • Expiración de mensajes. Se puede establecer un periodo máximo de retención de un mensaje en el broker.
  • Indicador de formato de payload: binary o utf-8
  • Topic aliases: http://www.steves-internet-guide.com/mqttv5-topics-aliases/ 
  • Request/Response: http://www.steves-internet-guide.com/mqttv5-request-response/, básicamente en el mensaje de publicación, indica al que recibe en que topic debe mandar la respuesta, dando así una información del cliente que publica.
  • Non Local Publishing, si se usa esta opción el broker no mandará los mensajes del topic al que mandas si también estás suscrito. Es una opción de suscripción.
  • Suscripciones compartidas, se usar el topic reservado $SHARE y se usa para balanceo de carga, de forma que los clientes suscritos a ese topic compartido no lo reciben todos sino de forma alternativa: http://www.steves-internet-guide.com/mqttv5-shared-subscriptions/
  • Reason Codes en todos los mensajes de ACK excepto PINGRESP

Diferencias entre MQTT versión 3 y versión 5:

Calidad de Servicio MQTT (QoS)

Al enviar mensajes MQTT existe la posibilidad de que los mensajes no lleguen al destinatario.

El envío de mensajes sin saber con seguridad que fueron recibidos se llama «QoS 0» (cero).

Es posible que también desee QoS 1, que le permite saber que el mensaje fue recibido. Básicamente, después de cada publicación, el suscriptor dice «OK». En el lenguaje MQTT se llama «PUBACK» (Reconocimiento de publicación).

También está QoS 2, que no sólo garantiza que su mensaje fue recibido, sino que sólo fue recibido una vez. Esto es un poco más complejo porque necesitas empezar a rastrear los IDs de los paquetes, así que lo dejaremos para más adelante.

Usar un nivel u otro depende de las características y necesidades de fiabilidad de nuestro sistema. Lógicamente, un nivel de QoS superior requiere un mayor intercambio mayor de mensajes de verificación con el cliente y, por tanto, mayor carga al sistema.

Los niveles de calidad de servicio (QoS) determinan cómo se entrega cada mensaje MQTT y deben especificarse para cada mensaje enviado a través de MQTT. Es importante elegir el valor de QoS adecuado para cada mensaje, ya que este valor determina la forma en que el cliente y el servidor se comunican para entregar el mensaje. Con el uso de MQTT se podrían lograr tres niveles de calidad de servicio para la entrega de mensajes:

  • QoS 0 (A lo sumo una vez – at most once) – donde los mensajes se entregan de acuerdo con los mejores esfuerzos del entorno operativo. Puede haber pérdida de mensajes. Confía en la fiabilidad del TCP. No se hacen retransmisiones.
  • QoS 1 (Al menos una vez – at least once) – donde se asegura que los mensajes lleguen, pero se pueden producir duplicados. El Receiver recibe el mensaje por lo menos una vez. Si el receiver no confirma la recepción del mensaje o se pierde en el camino el sender reenvía el mensaje hasta que recibe por lo menos una confirmación. Pueden duplicarse mensajes.
  • QoS 2 (Exactamente una vez – exactly once) – donde se asegura que el mensaje llegue exactamente una vez. Eso incrementa la sobrecarga en la comunicación pero es la mejor opción cuando la duplicación de un mensaje no es aceptable.

Existe una regla simple cuando se considera el impacto del rendimiento de la QoS. Es «Cuanto mayor sea la QoS, menor será el rendimiento«. MQTT proporciona flexibilidad a los dispositivos de IoT para elegir la calidad de servicio apropiada que necesitarían para sus requisitos funcionales y ambientales.

Entender QoS

Entender QoS MQTT: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

Sesiones persistentes: https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/

Para que el broker mantenga/retenga los mensajes publicados para el cliente, si este está momentáneamente desconectado, ocurre cuando un mensaje es publicado con QoS 1 o 2 y el cliente que recibe comple estas condiciones:

  • Conectado con clean session a falso
  • Suscrito con QoS 1 o 2

Desde la V5 de MQTT se puede establecer un expiry interval para que no se retengan los mensajes de forma indefinida en el broker.

Cuando habla de QoS en MQTT, deben considerar los dos lados de la entrega de mensajes:

  • Envío de mensajes desde el cliente de publicación al broker.
  • Entrega de mensajes del broker al cliente suscriptor.

Examinaremos los dos lados de la entrega del mensaje por separado porque existen diferencias sutiles entre los dos. El cliente que publica el mensaje para el broker define el nivel de QoS del mensaje cuando envía el mensaje al broker. El broker transmite este mensaje a los clientes suscriptores utilizando el nivel de calidad del servicio que cada cliente suscriptor define durante el proceso de suscripción. Si el cliente suscriptor define una QoS más baja que el cliente de publicación, el broker transmite el mensaje con la calidad de servicio más baja.

Todos los mensajes enviados con QoS 1 y 2 se ponen en cola para clientes sin conexión hasta que el cliente vuelve a estar disponible. Sin embargo, esta cola solo es posible si el cliente tiene una sesión persistente. Solo el cliente puede solicitar una sesión persistente cuando se conecta al broker (clean session es false)

Las sesiones persistentes guardan toda la información relevante para el cliente en el broker. El ID de cliente que proporciona el cliente cuando establece la conexión con el broker identifica la sesión.

En una sesión persistente, el broker almacena la siguiente información (incluso si el cliente está fuera de línea). Cuando el cliente se vuelve a conectar, la información está disponible de inmediato.

  • Existencia de una sesión (incluso si no hay suscripciones).
  • Todas las suscripciones del cliente.
  • Todos los mensajes en un flujo de calidad de servicio (QoS) 1 o 2 que el cliente aún no ha confirmado.
  • Todos los mensajes nuevos de QoS 1 o 2 que el cliente perdió mientras estaba desconectado.
  • Todos los mensajes de QoS 2 recibidos del cliente que aún no se han reconocido por completo.

Cuando el cliente se conecta al broker, puede solicitar una sesión persistente. El cliente usa un indicador cleanSession para decirle al intermediario qué tipo de sesión necesita.

Cuando el indicador de cleanSession se establece en falso, el broker crea una sesión persistente para el cliente. Toda la información y los mensajes se conservan hasta la próxima vez que el cliente solicite una sesión limpia. Si el indicador de sesión limpia se establece en falso y el broker ya tiene una sesión disponible para el cliente, utiliza la sesión existente y entrega los mensajes previamente en cola al cliente.

Al igual que el broker, cada cliente MQTT también debe almacenar una sesión persistente. Cuando un cliente solicita al servidor que contenga datos de sesión, el cliente es responsable de almacenar la siguiente información:

  • Todos los mensajes en un flujo de QoS 1 o 2, que aún no han sido confirmados por el broker.
  • Todos los mensajes de QoS 2 recibidos del intermediario que aún no se han reconocido por completo.

Por lo tanto para que haya una persistencia lo debe solicitar el suscriptor y el publicador debe mandar con una QoS 1 o 2.

MQTT Clean Session:

Último deseo y Testamento (MQTT LWT)

Un cliente puede establecer un mensaje Last Will and Testament (LWT) en el momento en el que se conecta con el Broker MQTT. Si el cliente no desconecta correctamente el Broker envía el mensaje LWT.

Cuando un cliente MQTT se conecta al servidor MQTT puede definir un tema y un mensaje que necesita ser publicado automáticamente sobre ese tema cuando se desconecta inesperadamente. Esto también se llama «Ultima voluntad y testamento» (LWT). Cuando el cliente se desconecta inesperadamente, el temporizador keep alive del lado del servidor detecta que el cliente no ha enviado ningún mensaje o el PINGREQ keep alive. Por lo tanto, el servidor publica inmediatamente el mensaje Will en el tema Will especificado por el cliente.

La función LWT puede ser útil en algunos escenarios. Por ejemplo, para un cliente MQTT remoto, esta función se puede utilizar para detectar cuando los dispositivos IoT salen de la red. La función LWT se puede utilizar para crear notificaciones para una aplicación que esté supervisando la actividad del cliente.

Paquete:

Ver explicación completa en: https://learn.adafruit.com/mqtt-adafruit-io-and-you/qos-and-wills 

Más información: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en 

Mensajes con Retención

Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.

Normalmente, si se envía un mensaje sobre un topic y nadie está suscrito a ese tema, el mensaje es simplemente descartado por el broker. Sin embargo, el publisher puede decirle al broker que mantenga el último mensaje en ese tema fijando el indicador de mensaje retenido.

Esto puede ser muy útil, como por ejemplo, si tiene un sensor que publica su estado sólo cuando se cambia, por ejemplo, el sensor de puerta. ¿Qué sucede si un nuevo suscriptor se suscribe a este estado?. Sin los mensajes retenidos, el suscriptor tendría que esperar a que el estado cambie antes de recibir un mensaje, sin embargo, con el mensaje retenido, el suscriptor vería el estado actual del sensor.

Lo que es importante entender es que sólo se retiene un mensaje por topic, el siguiente mensaje publicado sobre ese tema reemplaza al último mensaje retenido para ese tema.

NOTA: Si no usas clean sessions, entonces podrías ver mensajes que han sido almacenados pero no retenidos.

Tabla resumen:

Más información:

Otros Conceptos MQTT

  • Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.
  • Cuando un cliente conecta con el Broker puede solicitar que la sesión sea persistente (clean session = false), en ese caso el Broker almacena todas las suscripciones del cliente, todos los mensajes QoS 1 y 2 no procesados o perdidos por el cliente
  • Un mensaje MQTT CONNECT contiene un valor keepAlive en segundos donde el cliente establece el máximo tiempo de espera entre intercambio de mensajes

Seguridad MQTT

Ya sabemos lo importante que es la seguridad, y más en escenarios IoT en el que comunican objetos entre sí.  MQTT confía en tecnologías estándares para esto:

  • Autenticación usuario/Password
  • Seguridad SSL/TLS
  • ACLs

Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor. El cliente también puede proporcionar un certificado de cliente al broker durante el handshake, que el broker puede utilizar para autenticar al cliente. Aunque no forma parte específica de la especificación MQTT, se ha convertido en habitual que los broker admitan la autenticación de clientes con certificados SSL/TLS del lado del cliente.

Dado que el protocolo MQTTT pretende ser un protocolo para dispositivos con recursos limitados y de IoT, el SSL/TLS puede no ser siempre una opción y, en algunos casos, puede no ser deseable. En estos casos, la autenticación se presenta como un nombre de usuario y contraseña de texto claro que el cliente envía al servidor como parte de la secuencia de paquetes CONNECT/CONNNACK. Algunos brokers, especialmente los brokers abiertos publicados en Internet, aceptan clientes anónimos. En tales casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.

Reto MQTT: Seguridad, Interoperabilidad y Autenticación

Debido a que el protocolo MQTT no fue diseñado con la seguridad en mente, el protocolo ha sido tradicionalmente utilizado en redes back-end seguras para propósitos específicos de la aplicación. La estructura temática de MQTT puede fácilmente formar un árbol enorme, y no hay una manera clara de dividir un árbol en dominios lógicos más pequeños que puedan ser federados. Esto dificulta la creación de una red MQTT globalmente escalable porque, a medida que crece el tamaño del árbol temático, aumenta la complejidad.

Otro aspecto negativo de MQTT es su falta de interoperabilidad. Debido a que las cargas útiles de mensajes son binarias, sin información sobre cómo están codificadas (sin metadatos), pueden surgir problemas, especialmente en arquitecturas abiertas en las que se supone que las diferentes aplicaciones de los diferentes fabricantes funcionan a la perfección entre sí.

MQTT tiene características de autenticación mínimas incorporadas en el protocolo. El nombre de usuario y las contraseñas se envían en texto claro y cualquier forma de uso seguro de MQTT debe emplear SSL/TLS, que, lamentablemente, no es un protocolo ligero.

Autenticar clientes con certificados del lado del cliente no es un proceso simple, y no hay manera en MQTT, excepto el uso de medios propietarios fuera de banda, para controlar quién posee un topic y quién puede publicar información sobre él. Esto hace que sea muy fácil inyectar mensajes dañinos, ya sea intencionadamente o por error, en la red.

Además, no hay forma de que el receptor del mensaje sepa quién envió el mensaje original a menos que esa información esté contenida en el mensaje real. Las características de seguridad que tienen que ser implementadas sobre MQTT de forma propietaria aumentan la huella de código (footprint) y hacen que las implementaciones sean más difíciles.

Ventajas MQTT

Son varias las ventajas del protocolo MQTT como sistema de comunicación IoT. Por un lado, tenemos todas las ventajas del patrón pub/sub como son escalabilidad, asincronismo y desacoplamiento entre clientes.

Además, MQTT aporta una serie de características que le han hecho sobresalir sobre otros competidores.:

  • Sencillez y ligereza. Esto lo hace adecuado para aplicaciones IoT, donde frecuentemente se emplean dispositivos de escasa potencia.
  • Menor necesidad de recursos se traduce en un menor consumo de energía, lo cual es interesante en dispositivos que funcionan 24/7 y muy especialmente en dispositivos alimentados por batería.
  • Requiere un ancho de banda mínimo, lo cual es importante en redes inalámbricas, o conexiones con posibles problemas de calidad.
  • Medidas adicionales importantes, como la seguridad y calidad del servicio (QoS).
  • Es una solución largamente testada y consolidada, que aporta robustez y fiabilidad.

Clientes MQTT

Existen muchos clientes y librerías para MQTT, puesto que se trata de un protocolo libre sencillo de implementar.

Una aplicación de cliente MQTT se encarga de recopilar información del dispositivo de telemetría, conectar con el servidor y publicar la información en el servidor. También puede suscribirse a temas, recibir publicaciones y controlar el dispositivo de telemetría.

Cliente online: http://www.hivemq.com/demos/websocket-client/

Los mejores clientes MQTT: https://www.hivemq.com/blog/seven-best-mqtt-client-tools 

Tres herramientas MQTT y como simular MQTT: https://dzone.com/articles/top-3-online-tools-to-simulate-an-mqtt-client 

Herramientas MQTT: https://www.hivemq.com/blog/overview-of-mqtt-client-tools 

MQTT Explorer (Recomendado)

MQTT Explorer es un cliente MQTT integral que proporciona una descripción general estructurada de sus topics MQTT y hace que trabajar con dispositivos/servicios en su broker sea muy simple.

Web http://mqtt-explorer.com/

​​

Características:

  • Visualizar los topics y la actividad del topic.
  • Eliminar topics retenidos
  • Buscar / filtrar topics
  • Eliminar topics de forma recursiva
  • Vista diferente de los mensajes recibidos actuales y anteriores
  • Publicar topics
  • Graficar topics numéricos
  • Conservar un historial de cada topic
  • Temas oscuros/claros

Vídeo: http://mqtt-explorer.com/video.mp4 

Más Información:

MQTT.fx

Uno de los clientes MQTT más populares para instalar en ordenador es MQTT.fx hecho en java y basado en Eclipse Paho http://www.eclipse.org/paho/

Está disponible para Windows, Linux y MAC

Web: https://mqttfx.jensd.de/ 

Descarga: http://www.jensd.de/apps/mqttfx/1.7.1/ 

Referencias: http://mqttfx.jensd.de/index.php/references 

Más información:

MQTT-Spy

MQTT-spy es una utilidad de código abierto destinada a ayudarle a monitorear la actividad sobre temas de MQTTT. Ha sido diseñado para tratar con grandes volúmenes de mensajes, así como con publicaciones ocasionales.

Web: https://www.eclipse.org/paho/components/mqtt-spy/

mqtt-spy es probablemente una de las utilidades de código abierto más avanzadas para publicar y monitorear actividades sobre temas de MQTT. Está dirigido a dos grupos de usuarios:

  • Innovadores que necesitan una herramienta para crear prototipos de IO o proyectos de integración
  • Usuarios avanzados que necesitan una utilidad avanzada para sus entornos de trabajo

Web: https://kamilfb.github.io/mqtt-spy/ 

Wiki: https://github.com/eclipse/paho.mqtt-spy/wiki

Descarga: https://github.com/eclipse/paho.mqtt-spy/wiki/Downloads 

Getting Started: https://github.com/eclipse/paho.mqtt-spy/wiki/GettingStarted 

Ver mqtt-spy como aplicación para probar un mosquitto: https://github.com/kamilfb/mqtt-spy/wiki/Overview 

Resumen: https://github.com/kamilfb/mqtt-spy/wiki/Overview 

Más información:

Clientes MQTT en Autómatas

Para Siemens S7-1200/1500:

Unitronics: https://www.unitronicsplc.com/Download/SoftwareHelp/UniLogic_Knowledgebase/Communications/MQTT.htm

Clientes MQTT para móvil

Eclipse Paho Android Service: https://www.eclipse.org/paho/clients/android/

El que me gusta es https://play.google.com/store/apps/details?id=goliath.mobile.device.iotonoff

La web: https://www.iot-onoff.com/ 

Otro interesante es MQTT Dash: https://play.google.com/store/apps/details?id=net.routix.mqttdash&hl=es_419&gl=US 

Ejemplo de uso: https://www.hackster.io/fabiosouza/use-mqtt-dash-to-control-a-lamp-over-the-internet-97fa63 

Algunos clientes Android (por orden de descargas):

IOS:

Una app que es cliente MQTT, pero enfocada a domótica: https://www.andreas-binner.de/english/projects/visual/ 

Clientes MQTT en Dispositivos embebidos

MQTT se puede usar desde diversos dispositivos como cliente mediante el uso de librerías:

  • Arduino 
  • Python
  • Clientes MQTT
  • Raspberry Pi
  • Autómatas (ver PLC de Unitronics y otros)
  • Otros sistemas embebidos

Cliente MQTT para Python (Paho)

Documentación: https://www.eclipse.org/paho/clients/python/docs/  

Cliente MQTT python que está disponible en python. El proyecto Eclipse Paho proporciona implementaciones de cliente de código abierto de los protocolos de mensajería MQTT y MQTT-SN destinados a aplicaciones nuevas, existentes y emergentes para Internet de las cosas (IoT).

MQTT-SN:

Para usar la librería:

  • import paho.mqtt.client as mqtt # MQTT communication

Guia de MQTT: http://www.steves-internet-guide.com/mqtt/

Guia para novatos: http://www.steves-internet-guide.com/into-mqtt-python-client/

El cliente python de paho es asíncrono, lo que significa que si lanzo un script y finaliza antes de publicar o recibir fallará. Para ello se debe usar los loops y las funciones de callback

Trabajar con conexiones: http://www.steves-internet-guide.com/client-connections-python-mqtt/

Publicar mensajes con paho: http://www.steves-internet-guide.com/publishing-messages-mqtt-client/

Entender las callbacks: http://www.steves-internet-guide.com/mqtt-python-callbacks/

Callbacks: https://pypi.org/project/paho-mqtt/#callbacks

Suscripción a topics con paho: http://www.steves-internet-guide.com/subscribing-topics-mqtt-client/

Manejar multiples conexiones: http://www.steves-internet-guide.com/multiple-client-connections-python-mqtt/

Entender el loop: http://www.steves-internet-guide.com/loop-python-mqtt-client/

Documentación: https://www.eclipse.org/paho/clients/python/docs/

Tutorial: http://www.steves-internet-guide.com/into-mqtt-python-client/

MQTT y Arduino

MQTT ha surgido como un protocolo de mensajería estándar para la IoT. Se puede utilizar en redes TCP/IP y es muy ligero. La norma sigue un modelo de publicación-suscripción («pub/sub»).

Como habrás imaginado, para conseguir una comunicación MQTT, emplearemos una librería. Existen muchas disponibles gracias a la gran (tanto en tamaño como en calidad) comunidad que existe alrededor de Arduino.

Una de las librerías más conocidas y la más estable y flexible es Arduino Client for MQTT http://pubsubclient.knolleary.net/ que nos provee de un sencillo cliente que nos permite tanto subscribirnos como publicar contenido usando MQTT. Internamente, usa la API de Arduino Ethernet Client lo que lo hace compatible con un gran número de shields y placas.

Web: https://pubsubclient.knolleary.net/ 

Repositorio: https://github.com/knolleary/pubsubclient 

Esta librería está disponible en el gestor de librerías.

Documentación: https://pubsubclient.knolleary.net/api.html 

Hardware compatible:

  • Arduino Ethernet
  • Arduino Ethernet Shield
  • Arduino YUN – use the included YunClient in place of EthernetClient, and be sure to do a Bridge.begin() first
  • Arduino WiFi Shield – if you want to send packets greater than 90 bytes with this shield, enable the MQTT_MAX_TRANSFER_SIZE option in PubSubClient.h.
  • Sparkfun WiFly Shield – when used with this library
  • Intel Galileo/Edison
  • ESP8266
  • ESP32

Getting started con esa librería: https://ricveal.com/blog/arduino-mqtt/ 

Más info de esta librería: https://www.hivemq.com/blog/mqtt-client-library-encyclopedia-arduino-pubsubclient/ 

Tutorial con esta librería MQTT, Arduino y bluemix:: https://www.ibm.com/developerworks/ssa/cloud/library/cl-bluemix-arduino-iot2/index.html 

Uso de la librería: http://www.steves-internet-guide.com/using-arduino-pubsub-mqtt-client/ 

MQTT Publish en callback: https://codebender.cc/example/PubSubClient/mqtt_publish_in_callback#mqtt_publish_in_callback.ino

MQTT en Node-RED

Para integrar Node-RED con servicios MQTT existen los nodos de MQTT de publish y suscribe.

Más información: http://www.steves-internet-guide.com/configuring-the-mqtt-publish-node/

MQTT Recipes:

3 comentarios en “Protocolo MQTT”

  1. Pingback: Protocolo MQTT -

  2. Pingback: Diario del Curso IoT, Smart Cities y Node-RED | Aprendiendo Arduino

  3. Pingback: Diario Curso: Raspberry Pi y Node-RED. 2ª ed | Aprendiendo Arduino

Deja un comentario

Este sitio utiliza Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.