¿Qué es MQTT? El protocolo MQTT explicado

MQTT es un protocolo de mensajería ligero basado en publicación y suscripción. Los dispositivos y las aplicaciones se conectan a un único servidor, el broker, y publican mensajes en temas con nombre como site/dub01/mdb1/main-incomer. Cualquier cliente suscrito a ese tema recibe el mensaje a través del broker. Publicadores y suscriptores nunca se dirigen unos a otros, así que un contador, un panel y una plataforma en la nube pueden compartir datos sin conocerse. MQTT funciona sobre TCP en el puerto 1883, o sobre TLS en el puerto 8883, y su cabecera fija ocupa solo dos bytes. Como cada dispositivo se conecta hacia fuera al broker y cualquier número de sistemas puede suscribirse a los mismos datos, se ha convertido en el protocolo más común para enviar telemetría de sensores y contadores por Internet.

Cómo funciona MQTT

Un cliente abre una conexión TCP con el broker y envía CONNECT con su identificador de cliente, sus credenciales y un intervalo de keep-alive. El broker responde CONNACK. Después, un publicador envía paquetes PUBLISH; un suscriptor envía SUBSCRIBE con uno o varios filtros de tema, y desde entonces el broker le envía cada PUBLISH que coincida. Si no pasa ningún paquete durante el intervalo de keep-alive, el cliente envía PINGREQ, y el broker cierra una conexión que permanece callada durante vez y media el intervalo.

Como cada cliente abre una conexión saliente hacia el broker, la pasarela de un emplazamiento no necesita ningún puerto entrante abierto. Es la principal razón práctica por la que MQTT sustituyó a los protocolos de sondeo para sacar los datos de un emplazamiento.

Temas y comodines

Los temas son cadenas que distinguen mayúsculas y minúsculas. Un cliente no crea un tema; publica en él, y el broker dirige el mensaje a cada suscripción que coincide. Una suscripción puede usar dos comodines:

+ sustituye un nivel y # todo el resto del árbol, por lo que debe ir al final. Los temas que empiezan por $ están reservados al broker, como $SYS/ para sus estadísticas, y un filtro que empieza por un comodín no los incluye.

Diseñe el árbol de temas antes de que publique el primer dispositivo, porque de él dependen todos los suscriptores y todas las reglas de acceso. Un buen árbol va del ámbito más amplio al más estrecho (organización, emplazamiento, cuadro, dispositivo y después el tipo de mensaje), sitúa cada dispositivo en un solo lugar y deja fuera los valores que cambian, como una lectura, una marca de tiempo o un número de sesión. Separe los temas de telemetría, estado y órdenes, para dar permiso de escritura solo donde haga falta.

QoS, mensajes retenidos y última voluntad

MQTT tiene tres niveles de entrega. Se aplican a un tramo cada vez: del publicador al broker y del broker a cada suscriptor.

Un mensaje retenido lo guarda el broker como último valor de su tema y lo envía en el acto a cada suscriptor nuevo: sirve para el estado de un dispositivo, pero puede entregar una lectura obsoleta. La última voluntad (last will) es un mensaje que el broker publica en nombre de un cliente cuya conexión se corta sin un DISCONNECT limpio; así se entera un suscriptor de que una pasarela está desconectada. La guía de QoS y mensajes retenidos MQTT trata ambos en detalle, junto con la caducidad de mensajes y las sesiones persistentes.

Puertos y seguridad de MQTT

MQTT por sí mismo solo tiene un campo de usuario y contraseña. El cifrado, la identidad del servidor y los certificados de cliente vienen de TLS, y el control de acceso viene de las reglas del broker sobre qué cliente puede publicar o suscribirse a qué temas. La guía de MQTTS explica los certificados, la comprobación del nombre del servidor y cómo probar una conexión TLS desde la línea de órdenes.

MQTT 3.1.1 frente a MQTT 5

MQTT se diseñó en 1999 para la telemetría de oleoductos por enlace satelital. OASIS publicó MQTT 3.1.1 como norma en 2014, que pasó a ser ISO/IEC 20922 en 2016, y MQTT 5.0 en 2019. La mayoría de los brokers admiten las dos versiones, y muchos dispositivos solo hablan la 3.1.1.

Para telemetría, lo más útil de MQTT 5 son los códigos de motivo, porque el cliente ve que el broker rechazó un mensaje, y la caducidad de mensajes, porque una orden retrasada por un corte se descarta en lugar de ejecutarse tarde.

Carga útil: JSON, Sparkplug B y el contrato de datos

MQTT transporta bytes y no dice nada de su significado. La mayoría de las plataformas de energía esperan JSON, por ejemplo:

{"ts":"2026-10-28T09:15:00Z","kW":184.2,"kWh":1532871.4,"V1":231.4,"PF":0.94,"q":"good"}

El tema dice de qué contador se trata; la carga útil lleva la hora de la medida, los valores y un indicador de calidad. Las unidades y el significado de cada clave tienen que estar escritos y acordados con cada suscriptor: kW o W, energía importada o neta, la hora del contador o la hora en que la pasarela recibió el valor. Ese acuerdo, y no la compatibilidad con MQTT, es lo que hace que dos sistemas trabajen juntos. La guía de interoperabilidad enumera lo que debe fijar un contrato de datos, y la guía de hora de medida y hora de llegada explica por qué la hora de la medida debe ir en la carga útil.

Sparkplug B, una especificación de la Eclipse Foundation habitual en sistemas industriales, fija en cambio ese contrato. Los temas siguen spBv1.0/<group>/<message type>/<edge node>/<device>, la carga útil es binaria en Protocol Buffers y cada nodo edge publica un certificado de nacimiento con sus métricas y un certificado de defunción (a través de la última voluntad) cuando se desconecta. Así un suscriptor puede descubrir dispositivos y marcar los datos como obsoletos sin ningún acuerdo propio, a cambio de un formato binario que necesita un cliente compatible con Sparkplug para leerse.

Ejemplo práctico: ¿cuántos datos consume la telemetría MQTT?

Cincuenta contadores publican cada 10 segundos el mensaje JSON anterior con QoS 1. La carga útil ocupa 88 bytes y el tema 28 bytes, así que cada paquete PUBLISH tiene unos 122 bytes. TLS añade unos 22 bytes por registro y TCP e IP unos 52 bytes por segmento, de modo que cada mensaje ocupa en la línea unos 200 bytes.

El mensaje por emplazamiento lleva las 50 lecturas en una matriz JSON de unos 3650 bytes (unos 73 bytes por contador, con una sola marca de tiempo para todo el mensaje), más el tema y las cabeceras, que TCP reparte en tres segmentos.

En el primer caso, los PUBACK de vuelta suman otros 30 MB al día aproximadamente. En una línea fija nada de esto importa; con una SIM móvil decide la tarifa de datos. Agrupar las lecturas de un emplazamiento en un solo mensaje, o enviar solo los cambios, reduce la sobrecarga. La calculadora de demanda por intervalo ayuda a elegir un intervalo que siga respondiendo a la pregunta para la que sirven los datos.

MQTT comparado con otros protocolos

MQTT suele ser el enlace entre un emplazamiento y una plataforma, mientras que Modbus, BACnet y OPC UA leen los dispositivos del emplazamiento. La comparación entre OPC UA, Modbus y MQTT los enfrenta para proyectos industriales, y ¿Qué es Modbus? explica el lado del sondeo.

MQTT con EpiSensor

Edge, en la Gateway ZGW-20, lee los dispositivos Zigbee, Modbus, BACnet y LoRaWAN del emplazamiento, registra cada lectura con su hora de medida y publica en el broker de una plataforma como cliente MQTT, normalmente por MQTTS en el puerto 8883 con un certificado de cliente. Publica con QoS 1 y guarda las entregas fallidas en una cola local, que reenvía con sus marcas de tiempo originales cuando el broker vuelve a estar disponible. Los temas y la carga útil siguen el contrato de la plataforma, y Conectar Edge con su plataforma muestra las formas en que Edge envía los datos.