Guías

Versiones del protocolo MQTT

Guía detallada de versiones MQTT: MQTT 3.1, MQTT 3.1.1, MQTT 5.0, MQTT-SN, compatibilidad, funciones y migración.

Versiones del protocolo

Versiones del protocolo MQTT

Las versiones de MQTT no son solo etiquetas históricas. Definen el paquete CONNECT, la compatibilidad con brokers, el diagnóstico de errores, la vida de sesión, los metadatos de mensajes y la observabilidad. El mapa práctico es MQTT 3.1, MQTT 3.1.1, MQTT 5.0 y el protocolo relacionado MQTT-SN. En mayo de 2026, el directorio oficial de OASIS lista MQTT 3.1.1 y MQTT 5.0 como estándares principales, no MQTT 5.1.

Respuesta rápida

Elige MQTT 5.0 para sistemas nuevos si necesitas reason codes, properties, expiración de mensajes, request-response, control de flujo o mejor diagnóstico.
Usa MQTT 3.1.1 como base de compatibilidad para dispositivos antiguos, módulos baratos, SDK existentes y despliegues industriales.
Trata MQTT 3.1 como compatibilidad histórica, no como objetivo para productos nuevos.
Evalúa MQTT-SN solo cuando la red exige sensores de muy bajo consumo o enlaces no TCP/IP.

VersiónEstadoNivelMejor encajeGuía para proyectos nuevos

MQTT 3.1Histórico3Clientes legacy, brokers antiguos, compatibilidad IBM tempranaUsar solo si lo exige el legado

MQTT 3.1.1OASIS / ISO4Compatibilidad IoT amplia, gateways y telemetría ligeraBase segura de compatibilidad

MQTT 5.0OASIS5Brokers modernos, cloud, multi-tenant y mejor diagnósticoPreferido para sistemas nuevos

MQTT-SN 1.2Especificación relacionadaIndependienteRedes de sensores, enlaces no TCP/IP y dispositivos limitadosSolo si la red lo requiere

MQTT 3.1: versión histórica para compatibilidad legacy

MQTT 3.1 es la base previa a OASIS. Ya incluía clientes, brokers, CONNECT, PUBLISH, SUBSCRIBE, QoS 0/1/2, retained messages, will messages, keep alive y topic filters.

Su valor actual está en explicar comportamientos antiguos: nombres de protocolo distintos, paquetes CONNECT legacy y switches de compatibilidad en brokers.

No lo elijas para un producto nuevo salvo que el firmware, un gateway de campo o un cliente antiguo no pueda actualizarse.

Puntos de implementación

Confirma que el broker permite MQTT 3.1.
Revisa protocol name y protocol level en CONNECT.
No confundas una negociación de versión fallida con un fallo de red.

MQTT 3.1.1: la base real de compatibilidad

MQTT 3.1.1 es la versión estandarizada más extendida y sigue siendo el idioma común de muchos dispositivos, gateways, brokers open source, servicios cloud y clientes WebSocket.

Funciona muy bien cuando el modelo necesita publish, subscribe, QoS, retain y last will sin metadatos avanzados.

Sus límites aparecen en producción: errores poco detallados, sin properties estándar, menos control de sesión, expiración, flow control y diagnóstico que MQTT 5.0.

Cuándo seguir con 3.1.1

SDKs o módulos no soportan MQTT 5.0.
El modelo de mensajes es simple.
La compatibilidad máxima importa más que funciones nuevas.
Actualizar dispositivos cuesta más que el beneficio.

MQTT 5.0: la versión moderna para sistemas nuevos

MQTT 5.0 conserva publish/subscribe y añade properties y reason codes en conexión, publicación, suscripción, acuses y desconexión.

Properties cubre session expiry, message expiry, maximum packet size, receive maximum, topic alias, response topic, correlation data, user properties, payload format indicator y content type.

Reason codes hacen que CONNACK, PUBACK, SUBACK, UNSUBACK y DISCONNECT expliquen fallos con precisión: autenticación, permisos, tamaño de paquete, migración o cierre administrativo.

Capacidades clave

Reason codes para diagnósticos claros.
Properties para metadatos de sesión y mensaje.
Message Expiry para evitar comandos obsoletos.
Receive Maximum y Maximum Packet Size para proteger recursos.
Response Topic y Correlation Data para request-response.

MQTT-SN: protocolo relacionado para redes de sensores

MQTT-SN no reemplaza MQTT sobre TCP. Lleva el modelo publish/subscribe a redes no TCP/IP y sensores muy limitados.

Suele usar un gateway que traduce direcciones cortas, Topic IDs y restricciones de enlace hacia un broker MQTT normal.

Si tu dispositivo puede usar TCP/TLS o WebSocket de forma fiable, normalmente no necesitas MQTT-SN.

Cómo elegir

Cloud IoT y WebSocket: MQTT 3.1.1 o 5.0.
Redes no TCP/IP o sensores con sueño profundo: MQTT-SN.
Integración con brokers existentes: diseña bien el gateway MQTT-SN.

Migrar de MQTT 3.1.1 a MQTT 5.0

Verifica soporte MQTT 5.0 en broker, SDKs, gateways, cloud y herramientas de prueba.
Empieza por lo que da más valor operativo: reason codes, DISCONNECT reason, message expiry, session expiry y maximum packet size.
Mantén primero semántica compatible con 3.1.1 y adopta User Properties, Response Topic y Topic Alias gradualmente.
En flotas mixtas, permite 3.1.1 y 5.0 en paralelo y migra por tenant, producto o firmware.

Preguntas frecuentes

¿MQTT 5.0 es compatible con MQTT 3.1.1?

Comparten el modelo publish/subscribe, pero el protocol level de CONNECT es distinto. El broker puede soportar ambos, pero cada sesión usa una versión.

¿Existe MQTT 5.1?

En mayo de 2026, el directorio oficial de OASIS lista MQTT 3.1.1 y MQTT 5.0, no MQTT 5.1 como estándar principal.

¿Todo proyecto nuevo debe usar MQTT 5.0?

No siempre. Si dispositivos y plataforma lo soportan, es mejor por defecto. Si el hardware solo soporta 3.1.1, esa opción es más pragmática.

Referencias oficiales

Continuar a la guía QoS Abrir cliente MQTT