Elegir un broker MQTT para IoT es una de las pocas decisiones de infraestructura que afecta a todos los dispositivos que vayas a lanzar, así que merece la pena acertar antes de la primera versión del firmware. Esta guía te ofrece una lista de comprobación de 12 puntos, una tabla de preguntas para cualquier proveedor y una prueba práctica rápida que puedes hacer en cinco minutos. Por el camino mostramos cómo responde ConnectMQ a cada punto, usando únicamente funciones que realmente tiene.
Si aún estás decidiendo entre operar tu propio broker o usar un servicio, lee primero ¿Qué es un broker MQTT gestionado?.
Por qué importa la elección del broker MQTT para IoT
El broker está en medio de cada mensaje: los dispositivos publican en él y las aplicaciones se suscriben a través de él. Una vez que miles de dispositivos llevan grabados en el firmware un hostname, un puerto, una cadena de certificados y una estructura de topics, cambiar de broker se convierte en una migración costosa. El broker también define tu perímetro de seguridad, tu techo de escalado y buena parte de tu coste operativo mensual.
Por eso, un buen proceso de selección va más allá de «¿habla MQTT?» y examina la profundidad del soporte del protocolo, la seguridad, el aislamiento, la operación y el camino del prototipo a producción.
La lista de 12 puntos para elegir un broker MQTT para IoT
1. Soporte de protocolo: MQTT 3.1.1 y MQTT 5.0
La mayoría de los dispositivos y librerías existentes hablan MQTT 3.1.1, mientras que los proyectos nuevos se benefician de las funciones de MQTT 5.0: reason codes, expiración de sesión y de mensaje, topic aliases, suscripciones compartidas y petición/respuesta. Un broker debería admitir ambas versiones a la vez para que convivan dispositivos antiguos y nuevos. Comprueba qué funciones de MQTT 5 están realmente implementadas, no solo si se acepta el paquete CONNECT. La lista completa de funciones está en la especificación MQTT 5.0 de OASIS, y nuestra guía de características de MQTT 5 las explica en la práctica.
ConnectMQ: admite MQTT 3.1.1 y MQTT 5.0, incluidas suscripciones compartidas, retained messages, session expiry, topic alias, message expiry interval, response topic y reason codes. El CONNACK anuncia los límites del broker (Maximum QoS, Retain Available, Wildcard y Shared Subscription Available, Receive Maximum).
2. Transporte: TCP, TLS y WebSocket
Los dispositivos en redes limitadas pueden usar TCP sin cifrar durante el desarrollo, pero el tráfico de producción debe ir cifrado. Los navegadores y paneles necesitan MQTT sobre WebSocket, idealmente WebSocket seguro (WSS) para que funcionen desde páginas HTTPS.
ConnectMQ: TCP en el 1883, TLS en el 8883, WebSocket en el 8083 y WSS en el 8084 (ruta /mqtt), con un certificado de Let's Encrypt en el que ya confían los almacenes de CA estándar.
3. Autenticación
Pregunta cómo demuestran los dispositivos su identidad y cómo se emiten y rotan las credenciales. Como mínimo, quieres credenciales por broker y protección frente a clientes que se hagan pasar por otros mediante el client ID.
ConnectMQ: el usuario y la contraseña se emiten por broker en el portal, y los client IDs están restringidos al client ID emitido y a sus variantes con _suffix (por ejemplo YOUR_CLIENT_ID_sensor1). Consulta las buenas prácticas de seguridad en MQTT para tener la imagen completa.
4. Multitenencia y aislamiento
En un servicio compartido, tus topics deben ser invisibles para cualquier otro cliente. Si construyes un producto para tus propios clientes, necesitas la misma garantía un nivel más abajo.
ConnectMQ: los topics de cada inquilino están aislados de los demás inquilinos y del área pública de pruebas. Si además necesitas aislamiento a nivel de infraestructura, el plan Dedicated te da un clúster de brokers propio.
5. Escalabilidad y límites de conexión
Fíjate en los límites de conexiones simultáneas por plan, en los límites de tamaño de mensaje y en cómo pasas de un nivel al siguiente sin cambiar el código de los dispositivos.
ConnectMQ: Serverless (Free) permite hasta 25 conexiones simultáneas y mensajes de 256 KB; Serverless (Paid), hasta 1.000 conexiones y mensajes de 1 MB; Dedicated, BYOC y Self Managed Enterprise cubren despliegues mayores y aislados.
6. QoS y sesiones
QoS 1 y 2 te dan garantías de entrega; las sesiones persistentes permiten que los dispositivos que se reconectan recojan los mensajes encolados. Confirma qué niveles de QoS admite cada plan y durante cuánto tiempo se conservan las sesiones. Contexto: Niveles de QoS en MQTT explicados.
ConnectMQ: QoS hasta 1 en Serverless (Free) y QoS 2 en Serverless (Paid); la expiración de sesión tiene un tope por plan.
7. Retained messages y mensajes offline
Los retained messages dan a cada nuevo suscriptor el último valor conocido de inmediato, algo esencial para el estado y la configuración de los dispositivos. Los mensajes Last Will avisan al resto del sistema cuando un dispositivo se cae.
ConnectMQ: los retained messages están disponibles en todos los planes, los mensajes Last Will se entregan tal como exige la especificación y $SYS/broker/connection/{clientId}/state expone el estado de conexión de un cliente.
8. Estándares industriales: Sparkplug B e ISA-95
Las fábricas organizan cada vez más sus datos en un Unified Namespace que sigue los niveles ISA-95 (empresa, planta, área, línea, celda) y usan Sparkplug B para payloads tipados y con estado. Un broker que entiende estas convenciones ahorra trabajo de integración.
ConnectMQ: detecta estructuras de topics ISA-95 / Unified Namespace, detecta y decodifica Sparkplug B (Protobuf y JSON) y puede republicar Sparkplug B en una estructura ISA-95; por ejemplo, spBv1.0/factory1/DDATA/line1/cnc1 se convierte en connectmq/factory1/production/line1/cnc1/telemetry. Más información en Sparkplug B y el Unified Namespace.
9. Observabilidad
Cuando un dispositivo falla a las 3 de la madrugada, necesitas ver qué publicó y por qué se rechazó. Busca una vista de topics en tiempo real, el estado de las conexiones y códigos de error con significado.
ConnectMQ: el portal incluye un panel de control, un cliente MQTT en el navegador, un explorador de topics en tiempo real, una vista de dispositivos organizada por niveles ISA-95, reglas de alerta por umbral y un registro de alertas. Los reason codes de MQTT 5, como 0x97 (Quota exceeded) y 0x89 (Server busy), explican los rechazos, y la extensión de ConnectMQ para VS Code muestra los reason codes de CONNACK, SUBACK y PUBACK durante el desarrollo.
10. Modelos de despliegue
Algunos equipos quieren cero operación; otros deben mantener los datos en su propia cuenta cloud o en on-premises.
ConnectMQ: Serverless (clúster compartido), Dedicated (clúster aislado), BYOC (brokers en tu propia cuenta cloud, gestionados por ConnectMQ) y Self Managed Enterprise (broker con licencia en tu propia infraestructura).
11. Cuotas y protección
Un solo dispositivo con errores atrapado en un bucle de reconexión puede perjudicar a todos los que usan el broker. Pregunta cómo se defiende el broker a sí mismo y a tu inquilino.
ConnectMQ: cuotas por plan, protección contra avalanchas de conexiones con bloqueos temporales, bloqueo de IP tras intentos repetidos con credenciales erróneas y protección adaptativa frente a sobrecarga.
12. Coste y operación
Compara el coste total: cómputo, almacenamiento, parches, renovación de certificados, monitorización, guardias y actualizaciones. Un plan gratuito que te permita hacer prototipos sin tarjeta de crédito reduce el riesgo de la evaluación.
ConnectMQ: un broker MQTT gestionado con un plan Serverless gratuito (sin tarjeta de crédito) y planes de pago cuando necesitas límites de producción. Consulta los detalles actuales de los planes en connectmq.com.
Qué preguntar a tu proveedor de broker MQTT para IoT
Usa esta tabla como hoja de evaluación. Cópiala en tu propio documento y rellena una columna por candidato.
| Criterio | Pregunta | Respuesta de ConnectMQ |
|---|---|---|
| Protocolo | ¿Qué versiones de MQTT y qué funciones de MQTT 5 están implementadas? | MQTT 3.1.1 y 5.0; suscripciones compartidas, topic alias, expiración, response topic, reason codes |
| Transporte | ¿Qué puertos para TCP, TLS, WS y WSS? ¿Qué certificado? | 1883, 8883, 8083, 8084; Let's Encrypt |
| Autenticación | ¿Cómo se emiten las credenciales? ¿Puede un dispositivo suplantar otro client ID? | Usuario/contraseña por broker; client ID restringido al ID emitido y sus variantes _suffix |
| Aislamiento | ¿Pueden otros clientes ver mis topics? | No, los topics de cada inquilino están aislados |
| Escala | ¿Cuáles son los límites de conexiones y de tamaño de mensaje por plan? | 25 / 256 KB (Free), 1.000 / 1 MB (Paid), Dedicated para más |
| QoS | ¿Qué niveles de QoS por plan? ¿Expiración de sesión? | QoS 1 (Free), QoS 2 (Paid); expiración de sesión con tope por plan |
| Estado | ¿Retained messages, Last Will, estado de conexión? | Sí; $SYS/broker/connection/{clientId}/state |
| Industrial | ¿Soporte de Sparkplug B e ISA-95? | Detecta y decodifica Sparkplug B, republica en topics ISA-95 |
| Observabilidad | ¿Puedo ver topics, dispositivos y alertas en tiempo real? | Panel del portal, explorador de topics, vista de dispositivos, reglas de alerta |
| Despliegue | ¿Compartido, dedicado, en mi nube, on-premises? | Serverless, Dedicated, BYOC, Self Managed Enterprise |
| Protección | ¿Cómo se gestionan las avalanchas y los ataques de fuerza bruta? | Cuotas, bloqueos por avalancha, bloqueo de IP, protección frente a sobrecarga |
| Prueba | ¿Puedo probar sin tarjeta de crédito? | Sí, Serverless (Free) y el servidor MQTT público gratuito |
Pregunta también a cada proveedor qué no está incluido. Por ejemplo, ConnectMQ se centra en el broker en sí: no ofrece un motor de reglas en el servidor, webhooks ni conectores de datos integrados hacia Kafka o bases de datos, así que, si los necesitas, prevé consumir los datos con tu propio servicio suscriptor.
Prueba rápida contra broker.connectmq.com
Las fichas técnicas solo llegan hasta cierto punto. Antes de preseleccionar cualquier broker MQTT para IoT, conecta un cliente real. El servidor MQTT público gratuito de ConnectMQ, pensado para pruebas y no para datos de producción, no necesita cuenta: solo un client ID no vacío y un prefijo de topic único (todo lo que hay en el área pública puede leerlo cualquiera, así que usa únicamente datos de prueba). Los detalles y límites están en el artículo enlazado.
export ID=eval-$(openssl rand -hex 3)
# Terminal 1: suscribirse con MQTT 5
mosquitto_sub -h broker.connectmq.com -p 1883 -i $ID-sub -t "connectmq/demo/$ID/#" -v -V mqttv5
# Terminal 2: publicar un estado retenido y una lectura de telemetría por TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/status" -m "online" -r -q 1
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/telemetry" -m '{"temp": 23.1}'
# Limpiar el retained message
mosquitto_pub -h broker.connectmq.com -p 1883 -i $ID-pub -t "connectmq/demo/$ID/status" -n -r
En Windows o macOS, sustituye --capath /etc/ssl/certs por --cafile apuntando a un paquete de CA en formato PEM. Durante la prueba, comprueba los criterios que puedes observar directamente:
- Latencia: los mensajes deberían aparecer en la terminal 1 casi al instante.
- Retained messages: detén y reinicia el suscriptor; el estado
onlinellega de inmediato. - Last Will: añade
--will-topic "connectmq/demo/$ID/status" --will-payload offlinea un cliente y mátalo; el suscriptor recibeoffline. - Límites: el área pública permite 64 KB por mensaje y 10 mensajes por segundo por cliente; si los superas, recibes reason codes de MQTT 5 en lugar de descartes silenciosos.
Para una evaluación de producción, repite la prueba con un broker privado y las credenciales del portal:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t "#" -v
Empieza con ConnectMQ
La mejor forma de evaluar un broker MQTT para IoT es conectarle tus propios dispositivos. Regístrate en app.connectmq.com: el plan Serverless (Free) no requiere tarjeta de crédito. Crea un broker, copia el usuario, la contraseña y el client ID generados y observa cómo llegan tus primeros mensajes al explorador de topics en tiempo real.
Preguntas frecuentes
¿Cuál es el criterio más importante al elegir un broker MQTT para IoT?
La seguridad y el aislamiento van primero: transporte cifrado, autenticación por dispositivo y separación garantizada respecto a otros inquilinos. Después, comprueba el soporte de MQTT 5 y que los límites se ajusten al tamaño de tu flota.
¿Necesito MQTT 5.0 para un proyecto IoT?
No es estrictamente necesario, porque MQTT 3.1.1 sigue funcionando bien, pero MQTT 5 añade reason codes, intervalos de expiración, suscripciones compartidas y petición/respuesta, que facilitan la operación de sistemas grandes. Elige un broker que admita ambas versiones.
¿ConnectMQ admite Sparkplug B?
Sí. ConnectMQ detecta y decodifica payloads Sparkplug B (Protobuf y JSON) y puede republicarlos en una estructura de topics de Unified Namespace basada en ISA-95.
¿Puedo probar ConnectMQ sin crear una cuenta?
Sí. Conéctate a broker.connectmq.com sin credenciales, con un client ID no vacío y un prefijo de topic único. Recuerda que cualquiera puede leer el área pública.
¿Puedo ejecutar ConnectMQ en mi propia nube o centro de datos?
Sí. Además de los planes Serverless y Dedicated, ConnectMQ ofrece BYOC (brokers en tu propia cuenta cloud, gestionados por ConnectMQ) y Self Managed Enterprise para tu propia infraestructura.
