8.5. Introducción a MQTT: Telemetría y Pub/Sub

UF1794 | El protocolo ligero que impulsa el IoT Industrial (IIoT)

graph TD subgraph Publishers ["Publicadores (Planta)"] SENS1["Sensor de Temp
Publica: '25.4'
Topic: planta/horno/temp"] PLC1["PLC Control
Publica: 'RUN'
Topic: planta/linea1/estado"] end subgraph Core ["El Corazón MQTT"] BROKER(("MQTT Broker
(Ej: Mosquitto / AWS IoT)")) end subgraph Subscribers ["Suscriptores (IT / Cloud)"] SCADA["SCADA
Suscrito a: planta/linea1/estado"] BBDD["Base de Datos
Suscrito a: planta/horno/temp"] DASH["Dashboard Móvil
Suscrito a: planta/# (Todo)"] end SENS1 -->|"Publish"| BROKER PLC1 -->|"Publish"| BROKER BROKER -. "Push" .-> SCADA BROKER -. "Push" .-> BBDD BROKER -. "Push" .-> DASH style BROKER fill:#f39c12,color:#fff,stroke:#d35400,stroke-width:3px style SENS1 fill:#27ae60,color:#fff style PLC1 fill:#27ae60,color:#fff style SCADA fill:#3498db,color:#fff style BBDD fill:#3498db,color:#fff style DASH fill:#3498db,color:#fff

1. Origen: Tuberías en el Desierto

A finales de los 90, IBM necesitaba monitorizar oleoductos en zonas remotas a través de conexiones satelitales lentísimas, carísimas y que se cortaban constantemente. Los protocolos tradicionales como HTTP o Modbus eran demasiado "pesados" (enviaban demasiadas cabeceras inútiles). Para solucionar esto, inventaron MQTT (Message Queuing Telemetry Transport).

Hoy en día, MQTT es el protocolo rey del Internet de las Cosas (IoT) y la Industria 4.0 debido a su extrema ligereza. Su cabecera mínima es de tan solo 2 bytes, lo que lo hace ideal para dispositivos con poca batería y redes inestables.



2. Cambio de Paradigma: Adiós al Polling, Hola Pub/Sub

En protocolos clásicos (Modbus, HTTP), el cliente tiene que preguntar sin parar: "¿Ha cambiado la temperatura? ¿Ha cambiado la temperatura?" (Polling). Esto satura la red. MQTT rompe con esto utilizando una arquitectura de Publicación y Suscripción (Pub/Sub) basada en un intermediario central llamado Broker.

  • El Broker: Es el servidor central (ej. Eclipse Mosquitto). Ningún sensor habla directamente con el SCADA. Todos hablan con el Broker.
  • Publishers (Publicadores): Los sensores o PLCs. Cuando cambia la temperatura, el sensor "publica" (envía) el nuevo dato al Broker y se olvida.
  • Subscribers (Suscriptores): Los sistemas SCADA, ERPs o BBDD. Se "suscriben" al Broker para recibir datos específicos. Cuando el Broker recibe un dato de un publicador, se lo empuja (Push) inmediatamente a todos los suscriptores interesados.


3. El Enrutamiento: Temas (Topics)

¿Cómo sabe el Broker a quién enviar la información? Utilizando Topics (Temas). Un Topic no es más que una cadena de texto jerárquica, separada por barras (como las carpetas de tu ordenador).

Por ejemplo, un PLC publica un dato en el Topic: fabrica/linea1/hornoA/temperatura.

El poder de los Topics radica en el uso de "Wildcards" (comodines) para la suscripción:

  • El comodín '+' (Un nivel): Si el SCADA se suscribe a fabrica/linea1/+/temperatura, recibirá la temperatura del hornoA, del hornoB y de cualquier otra máquina en la linea1, pero no de la linea2.
  • El comodín '#' (Multinivel): Si el ERP se suscribe a fabrica/linea1/#, recibirá absolutamente todo el tráfico (temperaturas, alarmas, velocidades) que cuelgue de esa línea.


4. Calidad de Servicio (QoS) y Última Voluntad (LWT)

Como MQTT nació para redes inestables, un técnico de UF1794 dispone de tres niveles de QoS (Quality of Service) para garantizar la entrega de datos:

  • QoS 0 (At most once): El publicador envía el mensaje una vez y no espera confirmación. (Rápido, pero puede perderse).
  • QoS 1 (At least once): El publicador envía el mensaje y espera un "Acuse de recibo" (PUBACK) del Broker. Si no llega, lo reenvía. Garantiza la entrega, pero podría llegar duplicado.
  • QoS 2 (Exactly once): Usa un "apretón de manos" de 4 pasos para garantizar que el mensaje llega de forma segura y sin duplicados. (Más lento, ideal para comandos financieros).

LWT (Last Will and Testament): Es una genialidad para el diagnóstico. Cuando un sensor se conecta al Broker, le deja un "testamento" (ej. "Sensor Desconectado"). Si el sensor pierde la cobertura de red o se apaga bruscamente, el Broker publicará inmediatamente ese testamento a todos los suscriptores, permitiendo al SCADA mostrar una alarma de "Pérdida de Comunicación" al instante.

Infografía de la arquitectura MQTT con un Broker central y varios dispositivos.
Figura 1: La arquitectura MQTT. La separación total entre quien produce el dato (Publisher) y quien lo consume (Subscriber) permite que la red sea extremadamente escalable. Se pueden añadir cien nuevos sensores a la planta sin tener que tocar la configuración del SCADA, siempre que respeten la jerarquía de los Topics.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Domina el IIoT con MQTT

1. ¿Qué ventaja principal ofrece la arquitectura "Publicación/Suscripción" (Pub/Sub) de MQTT frente a los protocolos tradicionales de "Polling" (pregunta-respuesta) como Modbus TCP?

2. Un analista de datos quiere recibir en su ordenador todas las alarmas de los motores de todas las líneas de producción de la fábrica. Si los PLCs publican en topics con esta estructura: fabrica/lineaX/motorY/estado, ¿A qué topic debería suscribirse usando un "Wildcard" (comodín)?

3. Se necesita enviar la "Cuenta de Piezas Totales Diarias" desde la fábrica a la nube del ERP para facturar. Si un paquete se pierde, la facturación será incorrecta. Si se duplica, se facturará el doble. ¿Qué Nivel de Calidad de Servicio (QoS) de MQTT es obligatorio usar aquí?

🤖 Ejercicio Práctico 8: Cliente Publicador MQTT (Python)

Objetivo: Crear un dispositivo IoT virtual (Publisher) que se conecte a un Broker y envíe telemetría estructurada usando Topics.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un desarrollador IoT. Escribe un script en Python utilizando la librería `paho-mqtt` que simule un sensor de temperatura industrial publicando datos. El script debe: 1. Importar la librería cliente de paho.mqtt. 2. Conectarse al Broker público y gratuito de pruebas de Eclipse (`broker.hivemq.com`), puerto 1883. 3. Entrar en un bucle continuo que se ejecute cada 3 segundos. 4. En cada iteración, generar una temperatura aleatoria entre 60.0 y 80.0 grados. 5. Publicar ese valor como un string en el Topic: `curso_uf1794/alumno/[tu_nombre]/horno/temperatura`. Usa QoS=1. 6. Imprimir en la consola local un mensaje indicando el valor y el topic al que se acaba de publicar. Comenta el código indicando que, al estar en un Broker público, cualquier alumno del curso que escriba un script "Suscriptor" apuntando al topic `curso_uf1794/alumno/+/horno/temperatura` podrá ver los datos en tiempo real desde cualquier parte del mundo.