¿Por qué se ha impuesto MQTT en el IoT industrial?
El IoT industrial genera millones de lecturas al día: sensores que transmiten datos cada minuto, controladores que envían estados cada segundo, contadores que transmiten lecturas cada hora. Estos flujos de datos deben transmitirse de forma fiable, ligera y segura.
MQTT responde exactamente a estas necesidades:
- Ultraligero: encabezado de entre 2 y 5 bytes. HTTP/REST genera cientos de bytes de encabezados para una carga útil de unos pocos bytes.
- Conexión persistente: la pasarela se conecta una vez al broker y mantiene la conexión. No hay handshake TCP con cada mensaje.
- Publicar/Suscribirse: varios suscriptores (supervisión en la nube, ERP, BI) pueden recibir los mismos datos sin que la pasarela lo sepa.
- QoS configurable: en función de la importancia de los datos.
- Resiliencia: los mensajes se almacenan si el cliente se desconecta temporalmente (retención, sesión persistente).
Arquitectura MQTT industrial
Temas sobre MQTT: estructura y buenas prácticas
Un tema MQTT es una cadena jerárquica separada por /:
eziwan/{site_id}/{equipamiento}/{variable}
Exemples :
eziwan/sitio-bombeo-01/autómata/presión_de_impulso
eziwan/site-pompage-01/compteur/energie_kwh
eziwan/batiment-paris/cvc/temperature_zone_a
Buenas prácticas de nomenclatura:
- Incluir siempre el identificador del sitio para filtrar por sitio.
- Separar los tipos de datos (medida, estado, alarma, comando) en temas distintos.
- Utilizar nombres legibles, no códigos opacos.
- Evitar temas demasiado amplios (
eziwan/#) para las suscripciones en producción.
Niveles de QoS: ¿qué opción elegir para la industria?
| QoS | Garantía | Sobrecarga | Uso recomendado |
|---|---|---|---|
| 0 | Como máximo una vez (mejor esfuerzo) | Mínima | Mediciones frecuentes (1/s), se admite pérdida |
| 1 | Al menos una vez (con acuse de recibo) | Bajo | Supervisión estándar, alertas |
| 2 | Exactamente una vez (4 intercambios) | Medio | Órdenes, datos críticos |
Para la supervisión típica del IoT industrial (mediciones cada 5 a 60 segundos), QoS 1 es el equilibrio adecuado: fiabilidad suficiente y sobrecarga aceptable.
MQTT frente a HTTP para el IoT: comparación
| Criterio | MQTT | HTTP/REST |
|---|---|---|
| Modelo | Publicación/Suscripción | Solicitud/Respuesta |
| Tamaño de la sobrecarga | 2–5 bytes | 200–400 bytes |
| Conexión | Persistente | Por solicitud (o keep-alive) |
| Envío de datos | Nativo (suscripción) | Polling o WebSocket |
| Latencia | < 50 ms | 100–500 ms |
| Multisuscriptores | Nativo | Webhooks/colas externas |
| Apto para IoT de bajo ancho de banda | ★★★★★ | ★★ |
El enfoque de Eziwan
El Eziwan Gateway implementa un cliente MQTT que publica los datos Modbus/OPC UA recopilados en el broker MQTT de Eziwan Cloud. Los temas se generan automáticamente según la configuración de cada equipo. El transporte está protegido mediante TLS con autenticación mediante certificado de cliente; nunca se establece una conexión MQTT no segura.
Para más información: Modbus en la nube, pasarela de IoT industrial y supervisión de instalaciones remotas.