MQTT

Si te preguntas mqtt qué es exactamente y por qué domina el IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil industrial, la respuesta corta: es el protocolo pub/sub más ligero que existe para redes inestables. Si partes de cero, primero conviene entender qué es IoT y cómo funciona el ecosistema; si ya tienes esa base, sigue leyendo.

Resumen ejecutivo

• MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería pub/sub ligero estandarizado en ISO/IEC 20922 y mantenido por OASIS.
• Funciona sobre TCP/IP con cabeceras minúsculas (2 bytes fijos), pensado para dispositivos con poca CPU, batería limitada y redes inestables.
• Arquitectura: clientes (publishers y subscribers) hablan con un broker central que distribuye mensajes por topics jerárquicos.
• Es el protocolo dominante en IoT industrial (Industria 4.0), smart home (Home Assistant, Tasmota, Shelly) y mensajería masiva (WhatsApp y Facebook Messenger lo usan internamente).
• Versiones: MQTT 3.1.1 (ubiquo, 2014) y MQTT 5.0 (2019, añade shared subscriptions, reason codes, message expiry).
• Puertos: 1883 (TCP plano), 8883 (TLS), 80/443 (WebSockets).
• No usar cuando: necesitas request/reply síncrono (usa HTTP/CoAPCTérminoCoAPCoAP (Constrained Application Protocol) es un protocolo web tipo REST sobre UDP para dispositivos muy limitados, definido en el RFC 7252 del IETF.Ver perfil), tienes mensajes grandes (>256 MB), o no puedes mantener un broker.

Qué es MQTT y para qué sirve

MQTT son las siglas de Message Queuing Telemetry Transport. Es un protocolo de comunicación máquina-a-máquina (M2M) diseñado en 1999 por Andy Stanford-Clark (IBM) y Arlen Nipper (Cirrus Link) para monitorizar oleoductos vía satélite — entornos con ancho de banda escaso y conexiones que se cortan. En Plataforma IoT lo cubrimos junto al resto de protocolos IoT que conforman el ecosistema de conectividad.

A diferencia de HTTP (que es punto a punto, request/response, con headers verbosos), MQTT usa un modelo publicación/suscripción asíncrono con un intermediario:

[Dispositivo A] → publica en topic "fabrica/linea1/temperatura" → [Broker] → distribuye a [Dispositivo B, C, D] suscritos

El broker (Mosquitto, EMQXETérminoEMQXEMQX es un broker MQTT open source de alta escala (escrito en Erlang) para producción IoT, con clustering y soporte multiprotocolo.Ver perfil, HiveMQ, AWS IoT Core, etc.) recibe los mensajes y los reenvía a todos los clientes suscritos al topic correspondiente. El emisor no sabe ni necesita saber quién está escuchando — eso desacopla productores de consumidores y permite escalar a millones de dispositivos.

Cómo funciona MQTT

1. Conexión

Un cliente abre una conexión TCP al broker (por defecto puerto 1883) y envía un paquete CONNECT con:

• client_id (único por dispositivo)
• username y password opcionales
• keep_alive (en segundos: cada cuánto el cliente envía un PINGREQ para mantener viva la sesión)
• will message opcional: mensaje que el broker publicará si el cliente se desconecta abruptamente
• clean_session: si se preservan las suscripciones entre conexiones

El broker responde con CONNACK (success o código de error).

2. Topics

Los topics son strings UTF-8 jerárquicos separados por /:

fabrica/lineaA/maquina01/temperatura
fabrica/lineaA/maquina01/vibracion
hogar/salon/luz/estado

Los suscriptores pueden usar wildcards:

• + (single level): fabrica/+/maquina01/temperatura recibe temperatura de máquina01 en cualquier línea.
• # (multi level): fabrica/# recibe todo bajo fabrica.

3. Publish / Subscribe

Para publicar: paquete PUBLISH con topic, payload (cualquier bytes — texto, JSON, binario hasta 256 MB), qos y retain.

Para suscribirse: paquete SUBSCRIBE con lista de topics y QoSQTérminoQoS de MQTTEl QoS (Quality of Service) de MQTT define la garantía de entrega de un mensaje en tres niveles: 0 (como mucho una vez), 1 (al menos una vez) y 2 (exactamente una vez).Ver perfil deseado por cada uno.

4. QoS (Quality of Service)

MQTT define 3 niveles:

Aviso de seguridad: los niveles de QoS son independientes del cifrado. MQTT sin TLS transmite todo en texto plano, incluidas credenciales. Para despliegues en producción consulta nuestra guía de seguridad en IoT donde detallamos las mejores prácticas de autenticación y cifrado para brokers.

Aviso: QoS 2 añade latencia significativa. En IoT industrial, casi siempre QoS 1 + idempotencia en el consumidor es mejor que QoS 2.

5. Retained messages

Si publicas con retain=true, el broker guarda el último mensaje del topic. Cuando un nuevo cliente se suscribe, recibe inmediatamente ese último valor. Útil para estado actual (ej. "última temperatura conocida").

6. Last Will & Testament (LWT)

Si el cliente se desconecta abruptamente (corte de red, crash), el broker publica automáticamente el "will message" que el cliente declaró en CONNECT. Patrón típico: device/123/status con valor online retained + LWT offline retained, permite presencia en tiempo real.

Casos de uso reales

Brokers MQTT principales

Ventajas y desventajas

Ventajas

• Ligero: cabecera de 2 bytes fijos, ideal para microcontroladores (ESP32, nRF52).
• Resiliente a redes pobres: pensado para conexiones intermitentes.
• Asíncrono: desacopla productores y consumidores, escala bien.
• Standard maduro: ISO/IEC 20922, ecosistema enorme.
• TLS soportado: cifrado de extremo a extremo en transporte.

Desventajas

• Necesita broker: no es peer-to-peer; el broker es punto único de fallo si no haces clustering.
• No nativamente seguro: sin TLS, todo va en plano. Sin auth, cualquiera publica. Hay que configurarlo.
• Difícil de debugear: payload binario, multi-publisher, requiere herramientas (MQTT Explorer, mosquitto_sub).
• QoS 2 caro: 4-way handshake añade latencia.
• Sin discovery automático: no hay forma estándar de listar topics activos (en MQTT 5 puedes hacerlo con $SYS/, pero depende del broker).

MQTT vs HTTP vs CoAP

Resumen: MQTT gana cuando tienes muchos dispositivos enviando datos continuos. HTTP gana para APIs request/response y catálogos. CoAP gana en dispositivos extremadamente constrained que no pueden sostener TCP. Si aún estás evaluando qué protocolo encaja en tu proyecto, la sección de plataformas IoT puede ayudarte a entender el stack completo.

Cómo empezar: setup mínimo

1. Levanta un broker local (Mosquitto)

# macOS
brew install mosquitto
brew services start mosquitto

# Docker (cross-platform)
docker run -d --name mosquitto -p 1883:1883 eclipse-mosquitto

2. Suscríbete a un topic

mosquitto_sub -h localhost -t "test/topic" -v

3. Publica desde otra terminal

mosquitto_pub -h localhost -t "test/topic" -m "Hola IoT"

Verás el mensaje aparecer en el suscriptor. Ya tienes pub/sub funcionando.

MQTT también es el protocolo de elección para patrones de edge computing en IoT: el broker puede correr en un gateway local y procesar los datos antes de subirlos al cloud, reduciendo latencia y coste de transmisión.

4. Conecta un MCU (ESP32 + Arduino)

#include <WiFi.h>
#include <PubSubClient.h>

WiFiClient espClient;
PubSubClient client(espClient);

void setup() {
  WiFi.begin("ssid", "pass");
  client.setServer("192.168.1.10", 1883);
  client.connect("esp32-01");
  client.publish("hogar/salon/temperatura", "22.5");
  client.subscribe("hogar/salon/luz/cmd");
}

void callback(char* topic, byte* payload, unsigned int length) {
  // procesar comando entrante
}

Recursos primarios

• OASIS MQTT specification — spec oficial (acceso: 2026-05)
• mqtt.org — sitio oficial OASIS (acceso: 2026-05)
• Eclipse Mosquitto — broker reference open source
• HiveMQ MQTT Essentials — serie pedagógica
• MQTT 5 features (acceso: 2026-05)