Merece la pena evaluar una alternativa a EMQX Cloud solo cuando sabes de qué funciones del broker depende realmente tu proyecto. Esta guía te ayuda a enumerar esos requisitos, relacionarlos con las capacidades que ofrecen los brokers MQTT gestionados y ver dónde un broker ligero con decodificación de Sparkplug B y vistas ISA-95 integradas encaja mejor que una plataforma de datos amplia.
EMQX en contexto
EMQX es un broker MQTT open source muy utilizado, desarrollado por EMQ y conocido por su escalabilidad horizontal y su amplio conjunto de funciones, entre ellas un rule engine de estilo SQL e integraciones de datos con sistemas externos. EMQX Cloud lo ofrece como servicio gestionado en varios niveles. Para los equipos que quieren procesar mensajes y enrutarlos a bases de datos dentro del broker, eso es una ventaja real.
La disponibilidad de funciones puede variar entre niveles y cambia con el tiempo, así que consulta la documentación actual de EMQ para saber qué incluye cada nivel de EMQX Cloud antes de comparar. El mismo consejo se aplica a todos los proveedores de este artículo.
Parte de los requisitos, no de las listas de funciones
Las matrices de funciones premian al producto con la lista más larga. Tu proyecto premia al producto que hace lo que necesitas con la menor complejidad operativa. Responde por escrito a estas preguntas antes de mirar ningún proveedor:
- ¿Dónde se procesarán los mensajes? ¿Dentro del broker, en un servicio aparte o en herramientas que ya utilizas, como Node-RED o un procesador de streams?
- ¿Quién consume los datos? ¿Dashboards, historiadores, sistemas MES o ERP, aplicaciones móviles?
- ¿Qué formatos de payload llegan? ¿JSON, Sparkplug B en Protobuf, valores simples, binario propietario?
- ¿Cuántas conexiones y mensajes por segundo esperas dentro de un año?
- ¿Qué funciones de MQTT 5 utilizas? ¿Suscripciones compartidas, caducidad de mensajes, topic aliases?
- ¿Qué modelo de despliegue se requiere? ¿Compartido, dedicado, en tu propia cuenta cloud o autogestionado?
- ¿Quién lo depurará a las 2 de la madrugada? ¿Qué herramientas necesitará para ver topics y payloads en vivo?
Relacionar necesidades con capacidades del broker
| Tu necesidad | Capacidad que buscar | Qué preguntar a cada proveedor | ConnectMQ |
|---|---|---|---|
| Enrutar datos a bases de datos dentro del broker | Rule engine e integraciones de datos nativas | ¿Qué integraciones hay en cada nivel? | No se ofrece; usa Node-RED, Telegraf o tu propio suscriptor |
| Decodificar Sparkplug B para personas | Herramientas que entienden Sparkplug | ¿La decodificación está integrada en la consola? | Decodifica Sparkplug B (Protobuf/JSON) |
| Vistas de Unified Namespace | Reconocimiento de la jerarquía ISA-95 | ¿Se puede navegar por empresa/planta/área/línea? | Detecta topics ISA-95/UNS; vista de dispositivos por niveles ISA-95 |
| Normalizar Sparkplug en topics legibles | Republicación en una estructura UNS | ¿Es configurable o requiere código propio? | Republica Sparkplug B en topics ISA-95 |
| Alarmas sencillas por umbral | Reglas de alerta sobre valores de topics | ¿Está integrado o es un producto aparte? | Reglas de alerta por umbral con registro de alertas |
| Consumidores con balanceo de carga | Suscripciones compartidas de MQTT 5 | ¿En qué nivel están disponibles? | Serverless de pago y superiores |
| Aislamiento | Clústeres dedicados, BYOC | ¿Se puede cambiar de plan sin cambiar los endpoints? | Dedicated, BYOC, Self Managed Enterprise |
| Aplicaciones de navegador | Secure WebSocket | ¿Puerto y ruta? | 8084, ruta /mqtt |
El patrón es claro: si enrutar a bases de datos dentro del broker es un requisito central, una plataforma con rule engine puede encajarte mejor. Si tu principal problema es entender y organizar los datos industriales que pasan por el broker, un broker con herramientas de Sparkplug e ISA-95 integradas puede llevarte antes al objetivo con menos piezas móviles.
Por qué a los equipos industriales les importa decodificar Sparkplug B
Los payloads Sparkplug B están codificados en Protobuf. Todos los brokers los reenvían, pero cuando te suscribes con un cliente genérico solo ves ruido binario. Durante la puesta en marcha y la resolución de problemas, eso ralentiza a todo el mundo. La decodificación integrada en la consola del broker permite a un ingeniero leer directamente los nombres de las métricas, los valores y las marcas de tiempo.
ConnectMQ va un paso más allá y republica los datos Sparkplug B en topics de estilo ISA-95. Un mensaje en:
spBv1.0/factory1/DDATA/line1/cnc1
también queda disponible en:
connectmq/factory1/production/line1/cnc1/telemetry
Los consumidores que no entienden Sparkplug, como un dashboard sencillo o un gemelo digital 3D de la planta, pueden suscribirse al topic legible. La guía de MQTT Sparkplug B y Unified Namespace explica los conceptos de fondo.
Integrar sin rule engine
Si eliges un broker ligero, las integraciones viven fuera de él, en clientes MQTT estándar. Es un patrón conocido para muchos equipos y mantiene cada pieza sustituible. Aquí tienes un suscriptor mínimo en Python (paho-mqtt 2.x) que escucha los topics ISA-95 republicados y pasa cada mensaje a tu propia función de almacenamiento:
import json
import ssl
import paho.mqtt.client as mqtt
TOPIC = "connectmq/factory1/production/#"
def store(topic, payload):
# Replace with your historian, database or HTTP call
print(f"{topic}: {payload}")
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("Connect failed:", reason_code)
return
client.subscribe(TOPIC, qos=1)
def on_message(client, userdata, msg):
try:
payload = json.loads(msg.payload)
except ValueError:
payload = msg.payload.decode(errors="replace")
store(msg.topic, payload)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Sustituye store por una escritura en InfluxDB, un HTTP POST a tu MES o un mensaje a tu pipeline de datos actual. Node-RED y Telegraf pueden hacer lo mismo con configuración en lugar de código.
Cuestiones que resolver durante la prueba
- Visibilidad de los payloads. Conecta un gateway de PLC o un nodo edge real. ¿Puede tu equipo leer sus datos en la consola en cuestión de minutos?
- Organización de los topics. ¿Te ayuda el broker a ver la jerarquía de la planta o solo muestra una lista plana de topics?
- Esfuerzo de integración. ¿Cuánto se tarda en llevar un flujo de datos a tu historiador?
- Límites. ¿Qué ocurre al llegar al límite de tu plan? En ConnectMQ, superar una cuota devuelve el reason code 0x97 de MQTT 5 (quota exceeded), que tus clientes pueden registrar y gestionar.
- Vía de salida. ¿Podrías llevar los dispositivos a otro sitio cambiando solo los ajustes de conexión? Consulta vendor lock-in en MQTT.
Piensa en las habilidades del equipo, no solo en las funciones
Una capacidad solo es útil si tu equipo puede operarla. Un rule engine dentro del broker es potente, pero las reglas pasan a formar parte de tu lógica de producción y necesitan control de versiones, pruebas y revisión como cualquier otro código. Del mismo modo, llevar las integraciones a herramientas externas significa que alguien tiene que ejecutar y monitorizar esas herramientas. Ningún enfoque es gratis.
Pregúntate quién se ocupará del flujo de datos dentro de dos años. Los ingenieros de automatización que se manejan bien con flujos de Node-RED pueden preferir integraciones que puedan ver y editar visualmente. Un equipo de software con un stack de procesamiento de streams ya existente puede preferir que el broker siga siendo un transporte simple y rápido. Un equipo sin ninguna de las dos cosas puede valorar una plataforma que incluya más. Ajustar la arquitectura a las personas que la mantendrán suele importar más que cualquier función concreta de una tabla comparativa.
Cuándo un broker ligero no es la opción adecuada
Para ser justos con la comparación: si quieres un único producto que se encargue de la ingesta, la transformación, el enrutamiento a muchas bases de datos y el procesamiento de streams, un broker con rule engine e integraciones de datos integradas te ahorrará construir esa capa. ConnectMQ no ofrece rule engine, webhooks, bridges nativos a bases de datos ni controles de clustering del broker. Elige según la arquitectura de la que tu equipo quiera ser responsable.
Prueba un broker ligero y pensado para la industria
Puedes probar gratis la decodificación de Sparkplug y las vistas ISA-95 con tus propios datos. Crea un broker Serverless gratuito sin tarjeta de crédito, apunta a él un nodo edge o un gateway y abre el explorador de topics en vivo y la vista de dispositivos. Para un contexto más amplio, lee la guía de brokers MQTT en la nube, compara con nuestro marco de alternativa a HiveMQ Cloud y descubre de qué se encarga por ti un broker MQTT gestionado. Si quieres una prueba sin registro, el servidor MQTT público gratuito de broker.connectmq.com sirve para pruebas y prototipos, nunca para datos de producción. Más información en connectmq.com.
Preguntas frecuentes
¿Pueden los clientes de EMQX conectarse a ConnectMQ sin cambios?
Los clientes que usan MQTT 3.1.1 o 5.0 estándar funcionan con cualquier broker que cumpla el estándar. Solo cambian el host, el puerto, las credenciales y el client ID, salvo que dependas de funciones propias del proveedor.
¿Tiene ConnectMQ un rule engine como EMQX?
No. El procesamiento y las integraciones los realizan clientes MQTT externos como Node-RED, Telegraf o tus propios servicios.
¿Hace falta decodificar Sparkplug B para usar Sparkplug?
No, cualquier broker puede transportar Sparkplug B. La decodificación en la consola del broker simplemente hace que los datos sean legibles para las personas sin herramientas adicionales.
¿Dónde consulto las funciones actuales de EMQX Cloud?
En la documentación oficial y las páginas de precios de EMQ, porque los niveles, los límites y las funciones cambian con el tiempo.
