MQTT es un protocolo de mensajería ligero que permite a los dispositivos enviar mensajes pequeños a través de un servidor central, llamado bróker, en lugar de comunicarse directamente entre sí. Un dispositivo publica un mensaje con una etiqueta llamada tema o topic, y cada programa suscrito a ese tema recibe una copia. Por eso MQTT se utiliza en sensores, pasarelas industriales, concentradores Zigbee y sistemas de edificios.

Andy Stanford-Clark, de IBM, y Arlen Nipper, entonces en Arcom Control Systems, lo diseñaron en 1999 para supervisar oleoductos mediante enlaces por satélite lentos y caros. Ese origen sigue explicando buena parte de su diseño: desde los paquetes diminutos hasta la forma en que un dispositivo puede hacer que se anuncie su propia desconexión.

Lo esencial

  • MQTT funciona mediante publicación y suscripción: los dispositivos publican mensajes en los temas de un bróker, que los reenvía a todos los suscriptores correspondientes.
  • Quien publica y quien se suscribe no necesitan conocerse. Se puede añadir un panel, una base de datos o un servicio de alertas más adelante sin modificar el dispositivo.
  • Tres niveles de QoS permiten equilibrar el ancho de banda con las garantías de entrega, y el último testamento avisa cuando un dispositivo pierde la conexión.
  • Sparkplug añade a MQTT una estructura común de temas, un formato de datos y el seguimiento del estado conectado o desconectado para sistemas industriales.

¿Para qué se utiliza MQTT?

MQTT se utiliza cuando muchos dispositivos envían con frecuencia pequeñas cantidades de datos y algún sistema necesita reaccionar. Por ejemplo, una sonda que mide cada minuto la temperatura de una cámara frigorífica, un controlador que indica si una bomba está funcionando o un concentrador Zigbee que transmite eventos de puertas y movimiento. La misma conexión sirve en sentido contrario: una aplicación puede enviar una orden a un dispositivo, como conmutar un relé o cambiar una consigna.

Tres características explican por qué encaja en estos usos. La primera es su escaso tráfico adicional: la cabecera fija de un paquete MQTT puede ocupar solo dos bytes, mientras que una petición HTTP suele incluir varios cientos de bytes de cabeceras antes de la lectura. Cuando un dispositivo envía un número cada pocos segundos, la diferencia se acumula.

La conexión, además, permanece abierta. Como la ha iniciado el dispositivo hacia el exterior, el bróker puede devolverle mensajes aunque esté detrás de un cortafuegos o en una red móvil que bloquearía las peticiones entrantes.

Por último, el emisor y los receptores son independientes. Un sensor que publica en un tema no sabe si lo escucha un programa o veinte. Añadir un panel o un servicio de alertas un año después no obliga a cambiar su firmware.

Muchos equipos que interesa supervisar no hablan MQTT de forma nativa. Los contadores de energía y los variadores suelen utilizar Modbus; los controladores de edificios, BACnet; las máquinas de fábrica ofrecen OPC UA, y numerosos sensores inalámbricos de edificios utilizan Zigbee. Lo habitual es instalar una pasarela local que lea el protocolo original y publique los valores como mensajes MQTT. Puede ser un equipo industrial de Advantech o Moxa, un pequeño ordenador con Node-RED o un concentrador Zigbee2MQTT que publique en JSON los datos de cada dispositivo Zigbee. A partir de ahí, el resto del sistema solo tiene que entender un protocolo.

MQTT no resuelve cualquier necesidad. HTTP suele ser más sencillo para intercambios ocasionales de petición y respuesta, como un dispositivo que sube un informe al día o una aplicación que descarga un archivo de configuración. Un sensor a batería pensado para durar años normalmente no puede mantener abierta una conexión TCP. Por eso suele utilizar una radio de bajo consumo, como LoRaWAN, y acceder al resto del sistema a través de una pasarela. El vídeo en directo y la transferencia de archivos grandes también requieren otros protocolos.

¿Qué es un servidor MQTT?

Un servidor MQTT es el programa al que se conectan todos los dispositivos y aplicaciones. Se suele llamar bróker porque no sirve páginas como un servidor web. Recibe cada mensaje, consulta su tema y entrega una copia a cada cliente con una suscripción que coincida. Entre los brókeres conocidos están Eclipse Mosquitto, de código abierto, EMQX y HiveMQ, además de servicios en la nube como AWS IoT Core.

Los temas son cadenas de texto divididas en niveles mediante barras, de forma parecida a una ruta de archivo. Una sonda de cámara frigorífica podría publicar en plant1/coldroom3/temperature, y un contacto de puerta en plant1/dock2/door. No hay que crear el tema previamente: existe en cuanto alguien publica en él. Por eso conviene acordar desde el principio una estructura de nombres. El bróker acepta cualquier escritura, y una errata simplemente se convierte en un tema nuevo que nadie escucha.

Los suscriptores pueden utilizar dos comodines. El signo más representa exactamente un nivel: plant1/+/temperature recibe la temperatura de todas las salas de la planta 1. La almohadilla representa todo lo que hay por debajo de un nivel: plant1/# recibe todos los mensajes de esa planta. Los comodines solo sirven para suscribirse; al publicar siempre se indica un tema concreto.

El bróker nunca examina el contenido del mensaje. La carga útil no es más que bytes: un número, un objeto JSON como {"temperature": 4.2, "battery": 87} o un formato binario. Cada suscriptor debe saber interpretarla. Ese es el problema que Sparkplug resuelve para los sistemas industriales.

Otras dos funciones del bróker determinan cómo se comporta el sistema. Cuando un mensaje se publica con la marca retain, el bróker lo conserva como mensaje retenido de ese tema, uno por tema, y lo entrega inmediatamente a cada nuevo suscriptor. Así, un panel recién abierto muestra la posición actual de una válvula sin esperar a la siguiente actualización. Una sesión persistente permite recordar las suscripciones de un cliente mientras está desconectado y poner en cola sus mensajes QoS 1 y QoS 2 hasta que vuelva a conectarse. Que también se encolen los mensajes QoS 0 depende del bróker.

Se puede mantener un bróker propio o utilizar uno gestionado por un proveedor: la conexión de dispositivos MQTT a Kilo funciona de las dos formas. Con Cloud MQTT, Kilo aprovisiona un bróker con un punto de conexión y credenciales propios para cada conector. Solo acepta conexiones MQTTS cifradas en el puerto 1884. Con External MQTT, Kilo se conecta a un bróker que ya esté en funcionamiento, como Mosquitto, HiveMQ o AWS IoT Core. En ambos casos, se elige cómo se asocia cada mensaje con su dispositivo: mediante un patrón de tema o mediante un identificador de dispositivo dentro del JSON.

¿Qué es un cliente MQTT?

Un cliente MQTT es cualquier elemento que se conecta al bróker: un sensor, una pasarela, una aplicación móvil, un programa que escribe en una base de datos o una plataforma en la nube. Aparte del propio bróker, el protocolo no distingue funciones separadas. Todos los clientes pueden publicar, suscribirse o hacer ambas cosas.

Al conectarse, el cliente envía un identificador que debe ser único en ese bróker. Si llega una segunda conexión con el mismo identificador, el bróker cierra la primera. Es una causa habitual de que dos dispositivos se desconecten mutuamente una y otra vez. El cliente también puede enviar un usuario y una contraseña o presentar un certificado, e indica un intervalo de mantenimiento de conexión, por ejemplo 60 segundos. Si no tiene nada que enviar durante ese tiempo, manda un pequeño ping para que el bróker sepa que sigue ahí.

Existen bibliotecas cliente, como las de Eclipse Paho, para casi todos los lenguajes de programación y para pequeños microcontroladores. Así, un script de Python y una placa ESP32 pueden compartir bróker. Para diagnosticar problemas, un cliente MQTT de escritorio suscrito a # en un bróker de pruebas muestra cada mensaje a medida que llega.

¿Cuáles son los niveles de QoS de MQTT?

La calidad de servicio, o QoS, es un ajuste de cada mensaje que indica cuánto esfuerzo deben hacer emisor y receptor para entregarlo. MQTT tiene tres niveles.

  • QoS 0, como máximo una vez. El mensaje se envía una vez, sin confirmación. Si se pierde en la red, no se recupera. Es adecuado para lecturas frecuentes.
  • QoS 1, al menos una vez. El receptor confirma cada mensaje. Si no llega la confirmación, el emisor lo reenvía, normalmente tras reconectarse. No se pierde nada, pero un mensaje puede llegar dos veces, por lo que el receptor debe admitir duplicados.
  • QoS 2, exactamente una vez. Un intercambio de cuatro pasos garantiza que el mensaje se entregue una sola vez. Es el nivel que requiere más intercambios y encaja cuando un duplicado causaría un perjuicio, por ejemplo al facturar por evento.

La QoS se aplica por separado a cada tramo: del emisor al bróker y del bróker a cada suscriptor. El suscriptor recibe cada mensaje con el menor de los dos niveles.

Pensemos en un sensor de depósito que publica el nivel de llenado cada 30 segundos por una conexión móvil. Con QoS 0, perder alguna lectura no supone un problema: la siguiente llegará 30 segundos después. Una orden para cerrar una válvula es distinta. Perderla sí importa, por lo que se envía con QoS 1 y el controlador trata una segunda orden de «cerrar» sin consecuencias adicionales.

¿Qué es el último testamento de MQTT?

El último testamento, o Last Will and Testament, normalmente abreviado LWT, es un mensaje que el cliente entrega al bróker al conectarse. Incluye un tema, una carga útil y un nivel de QoS. El bróker lo guarda y solo lo publica si el cliente desaparece sin despedirse: se cae la red, falla la alimentación o vence el intervalo de mantenimiento sin tráfico. Si el cliente se desconecta correctamente, el bróker descarta el testamento.

El patrón habitual es el siguiente. Cuando una pasarela se conecta, publica online como mensaje retenido en plant1/gateway7/status y registra un testamento que publicará offline, también como mensaje retenido, en el mismo tema. Cualquier suscriptor conoce así el estado actual de la pasarela, incluso después de una avería.

La especificación concede al bróker una vez y media el intervalo de mantenimiento antes de considerar desconectado a un cliente silencioso. Con un intervalo de 60 segundos, el mensaje de desconexión puede tardar unos 90 segundos en aparecer. MQTT 5, la versión actual del protocolo, también permite retrasar el testamento para que una reconexión breve no se anuncie como un fallo.

¿Qué es MQTT Sparkplug?

MQTT Sparkplug es una especificación que concreta las reglas que MQTT deja abiertas. MQTT no establece cómo nombrar los temas, codificar la carga útil ni saber si una máquina está conectada. Por eso dos fabricantes pueden utilizar MQTT y aun así no entender los datos del otro. Sparkplug nació en Cirrus Link Solutions y pasó en 2019 a la Fundación Eclipse, que lo mantiene actualmente.

La estructura de los temas es fija: spBv1.0/<group>/<message type>/<edge node>/<device>. Las cargas útiles utilizan una codificación binaria compacta basada en Protocol Buffers, con métricas identificadas por nombre, tipos de datos y marcas de tiempo. El estado se sigue mediante certificados de nacimiento y defunción. Cuando un nodo de borde se conecta, publica un mensaje de nacimiento que enumera todas las métricas que enviará, con su nombre y tipo. A partir de ahí solo transmite los valores que cambian, lo que reduce el tráfico en instalaciones grandes. El certificado de defunción del nodo se registra como su último testamento MQTT. Si el nodo se desconecta, el bróker informa a todos los suscriptores sin que tengan que preguntar.

La «B» de Sparkplug B corresponde a la versión del formato de carga útil que se utiliza hoy. Se encuentra sobre todo en fábricas y sistemas SCADA donde equipos de distintos fabricantes comparten un bróker.

Preguntas frecuentes sobre MQTT

¿Qué puerto utiliza MQTT?

MQTT sin cifrar utiliza el puerto TCP 1883, y MQTT sobre TLS el 8883. Ambos están registrados para MQTT en la IANA. También se puede configurar un bróker para que escuche en otro puerto.

¿MQTT utiliza TCP o UDP?

El MQTT estándar funciona sobre TCP porque necesita una conexión bidireccional fiable que mantenga el orden de los datos. También puede funcionar sobre WebSockets, lo que permite que una página web actúe como cliente MQTT. Existe una variante separada, MQTT-SN, para UDP y para redes de sensores que no transportan TCP.

¿Es seguro MQTT?

MQTT no cifra nada por sí solo, así que la seguridad depende de la configuración del bróker. Las medidas habituales son cifrar la conexión con TLS, dar a cada dispositivo sus propias credenciales o certificado cliente y limitar los temas en los que cada cliente puede publicar o suscribirse. Un bróker que acepta conexiones anónimas y sin cifrar desde Internet permite que cualquiera que acceda a él lea todos los mensajes y publique órdenes.

¿Qué diferencia hay entre MQTT 3.1.1 y MQTT 5?

MQTT 3.1.1 se convirtió en estándar de OASIS en 2014 y posteriormente se publicó como ISO/IEC 20922. MQTT 5 llegó en 2019 y añadió códigos de motivo en las confirmaciones, caducidad de mensajes y sesiones, suscripciones compartidas que distribuyen los mensajes de un tema entre varios clientes, propiedades de usuario y alias de temas. Muchos brókeres admiten ambas versiones, y cada cliente elige la suya al conectarse.

Crea un conector Cloud MQTT en una cuenta gratuita de Kilo, publica una lectura JSON por TLS desde cualquier cliente MQTT al punto de conexión proporcionado y registra un dispositivo para ese tema. La pestaña Mapping del dispositivo mostrará todos los campos enviados y sus valores actuales. El JSON anidado se aplana en claves como sensor.temperature, y eliges qué campos se convierten en métricas. Un dispositivo de prueba deja espacio para otros cuatro en el plan gratuito cuando el primero ya transmite correctamente.