Só vale a pena avaliar uma alternativa ao EMQX Cloud depois de saber de quais recursos do broker o seu projeto realmente depende. Este guia ajuda você a listar esses requisitos, associá-los às capacidades que os brokers MQTT gerenciados oferecem e ver onde um broker enxuto, com decodificação de Sparkplug B e visões ISA-95 integradas, se encaixa melhor do que uma plataforma de dados ampla.
O EMQX em contexto
O EMQX é um broker MQTT open source amplamente usado, da EMQ, conhecido pela escalabilidade horizontal e por um conjunto amplo de recursos, incluindo um rule engine no estilo SQL e integrações de dados com sistemas externos. O EMQX Cloud o empacota como serviço gerenciado em vários níveis. Para equipes que querem processamento de mensagens e roteamento para bancos de dados dentro do broker, essa é uma força genuína.
A disponibilidade de recursos pode variar entre os níveis e muda com o tempo, então consulte a documentação atual da EMQ sobre o que cada nível do EMQX Cloud inclui antes de comparar. O mesmo conselho vale para todos os fornecedores citados neste artigo.
Comece pelos requisitos, não pelas listas de recursos
Matrizes de recursos premiam o produto com a lista mais longa. O seu projeto premia o produto que faz o que você precisa com a menor complexidade operacional. Anote as respostas a estas perguntas antes de olhar qualquer fornecedor:
- Onde o processamento das mensagens vai acontecer? Dentro do broker, em um serviço separado ou em ferramentas que você já usa, como Node-RED ou um processador de streams?
- Quem consome os dados? Dashboards, historians, sistemas MES ou ERP, aplicativos móveis, um gêmeo digital da planta?
- Quais formatos de payload chegam? JSON, Sparkplug B em Protobuf, valores simples, binário proprietário?
- Quantas conexões e mensagens por segundo você espera daqui a um ano?
- Quais recursos do MQTT 5 você usa? Shared subscriptions, message expiry, topic aliases?
- Qual modelo de implantação é necessário? Compartilhado, dedicado, na sua própria conta de nuvem ou autogerenciado?
- Quem vai depurar às 2 da manhã? De quais ferramentas essa pessoa vai precisar para ver topics e payloads ao vivo?
Associando necessidades às capacidades do broker
| Sua necessidade | Capacidade a procurar | Perguntas para cada fornecedor | ConnectMQ |
|---|---|---|---|
| Rotear dados para bancos de dados dentro do broker | Rule engine e integrações de dados nativas | Quais integrações estão em qual nível? | Não oferecido; use Node-RED, Telegraf ou seu próprio assinante |
| Decodificar Sparkplug B para pessoas | Ferramentas que entendem Sparkplug | A decodificação está integrada ao console? | Decodifica Sparkplug B (Protobuf/JSON) |
| Visões de Unified Namespace | Reconhecimento da hierarquia ISA-95 | Dá para navegar por empresa/site/área/linha? | Detecta topics ISA-95/UNS; visão de dispositivos por níveis ISA-95 |
| Normalizar Sparkplug em topics legíveis | Republicação em uma estrutura UNS | É configurável ou exige código próprio? | Republica Sparkplug B em topics ISA-95 |
| Alarmes simples por limite | Regras de alerta sobre valores de topics | É integrado ou um produto separado? | Regras de alerta por limite com log de alertas |
| Consumidores com balanceamento de carga | Shared subscriptions do MQTT 5 | Disponível em qual nível? | Serverless pago e acima |
| Isolamento | Clusters dedicados, BYOC | Dá para fazer upgrade sem mudar os endpoints? | Dedicated, BYOC, Self Managed Enterprise |
| Aplicações no navegador | Secure WebSocket | Porta e caminho? | 8084, caminho /mqtt |
O padrão é claro: se o roteamento para bancos de dados dentro do broker for um requisito central, uma plataforma com rule engine pode atender melhor. Se a sua principal dor for entender e organizar os dados industriais que passam pelo broker, um broker com ferramentas de Sparkplug e ISA-95 integradas pode levar você lá mais rápido e com menos peças móveis.
Por que equipes industriais se importam com a decodificação de Sparkplug B
Os payloads Sparkplug B são codificados em Protobuf. Todo broker os encaminha, mas, quando você assina com um cliente genérico, vê apenas ruído binário. Durante o comissionamento e a solução de problemas, isso atrasa todo mundo. A decodificação integrada ao console do broker permite que um engenheiro leia diretamente nomes de métricas, valores e timestamps.
A ConnectMQ vai um passo além e republica os dados Sparkplug B em topics no estilo ISA-95. Uma mensagem em:
spBv1.0/factory1/DDATA/line1/cnc1
também fica disponível em:
connectmq/factory1/production/line1/cnc1/telemetry
Consumidores que não entendem Sparkplug, como um dashboard simples, podem assinar o topic legível. O guia de MQTT Sparkplug B e Unified Namespace explica os conceitos por trás.
Integrando sem um rule engine
Se você escolher um broker enxuto, as integrações ficam fora dele, em clientes MQTT padrão. Esse é um padrão familiar para muitas equipes e mantém cada parte substituível. Aqui está um assinante Python mínimo (paho-mqtt 2.x) que escuta os topics ISA-95 republicados e entrega cada mensagem à sua própria função de armazenamento:
import json
import ssl
import paho.mqtt.client as mqtt
TOPIC = "connectmq/factory1/production/#"
def store(topic, payload):
# Substitua pelo seu historian, banco de dados ou chamada HTTP
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()
Troque store por uma gravação no InfluxDB, um HTTP POST para o seu MES ou uma mensagem para o seu pipeline de dados existente. O Node-RED e o Telegraf podem fazer o mesmo com configuração em vez de código.
Perguntas para resolver durante um teste
- Visibilidade dos payloads. Conecte um gateway de CLP ou um edge node real, por exemplo de uma linha em uma planta de Joinville ou de Manaus. A sua equipe consegue ler os dados dele no console em poucos minutos?
- Organização dos topics. O broker ajuda você a enxergar a hierarquia da fábrica ou mostra apenas uma lista plana de topics?
- Esforço de integração. Quanto tempo leva para levar um fluxo de dados até o seu historian?
- Limites. O que acontece no limite do seu plano? Na ConnectMQ, exceder uma cota retorna o reason code 0x97 do MQTT 5 (quota exceeded), que os seus clientes podem registrar e tratar.
- Caminho de saída. Daria para levar os dispositivos para outro lugar mudando apenas as configurações de conexão? Veja vendor lock-in em MQTT.
Pense nas habilidades da equipe, não só nos recursos
Uma capacidade só é útil se a sua equipe conseguir operá-la. Um rule engine dentro do broker é poderoso, mas as regras passam a fazer parte da sua lógica de produção e precisam de versionamento, testes e revisão como qualquer outro código. Da mesma forma, levar as integrações para ferramentas externas significa que alguém precisa operar e monitorar essas ferramentas. Nenhuma das abordagens sai de graça.
Pergunte quem será o responsável pelo caminho dos dados daqui a dois anos. Engenheiros de automação à vontade com fluxos do Node-RED podem preferir integrações que conseguem ver e editar visualmente. Uma equipe de software com uma stack de processamento de streams já existente pode preferir que o broker continue sendo um transporte simples e rápido. Uma equipe sem nenhuma das duas pode valorizar uma plataforma que reúna mais coisas. Ajustar a arquitetura às pessoas que vão mantê-la costuma importar mais do que qualquer recurso isolado em um quadro comparativo.
Quando um broker enxuto não é a escolha certa
Para ser justo com a comparação: se você quer um único produto que cuide de ingestão, transformação, roteamento para muitos bancos de dados e processamento de streams, um broker com rule engine e integrações de dados integrados vai poupar você de construir essa camada. A ConnectMQ não oferece rule engine, webhooks, bridges nativas para bancos de dados nem controles de clustering do broker. Escolha com base na arquitetura que a sua equipe quer manter.
Experimente um broker enxuto e voltado à indústria
Você pode testar a decodificação de Sparkplug e as visões ISA-95 com os seus próprios dados sem custo. Inicie um broker Serverless gratuito, sem cartão de crédito, aponte um edge node ou gateway para ele e abra o explorador de topics ao vivo e a visão de dispositivos. Para um contexto mais amplo, leia o guia de broker MQTT na nuvem, compare com o nosso método de alternativa ao HiveMQ Cloud e saiba do que um broker MQTT gerenciado cuida por você. Para um teste rápido sem cadastro, use o servidor MQTT público (gratuito), que serve para testes e protótipos, não para dados de produção. Mais em connectmq.com.
Perguntas frequentes
Clientes do EMQX conseguem se conectar à ConnectMQ sem alterações?
Clientes que usam MQTT 3.1.1 ou 5.0 padrão funcionam com qualquer broker compatível. Só mudam host, porta, credenciais e client ID, a menos que você dependa de recursos específicos do fornecedor.
A ConnectMQ tem um rule engine como o EMQX?
Não. O processamento e as integrações são feitos por clientes MQTT externos, como Node-RED, Telegraf ou os seus próprios serviços.
A decodificação de Sparkplug B é necessária para usar Sparkplug?
Não, qualquer broker consegue transportar Sparkplug B. A decodificação no console do broker apenas torna os dados legíveis para as pessoas sem ferramentas extras.
Onde verifico os recursos atuais do EMQX Cloud?
Use a documentação oficial e as páginas de preços da EMQ, porque níveis, limites e recursos mudam com o tempo.
