Alternativa ao Azure IoT Hub: Migrando para um Broker MQTT 3.1.1/5.0 Completo

Vale a pena considerar uma alternativa ao Azure IoT Hub quando o seu projeto precisa de publish/subscribe de verdade entre dispositivos, aplicações e serviços, e não de um gateway dispositivo-nuvem. Este artigo explica como o suporte a MQTT centrado em dispositivos do IoT Hub difere de um broker MQTT 3.1.1/5.0 completo, o que avaliar de cada lado e um caminho de migração em etapas para um broker padrão que mantém a sua frota funcionando o tempo todo.

Para que o Azure IoT Hub foi projetado

O Azure IoT Hub é um serviço gerenciado para conectar, gerenciar e se comunicar com dispositivos no Azure. Seus pontos fortes são voltados à gestão de frotas: um registro de identidade de dispositivos, device twins, direct methods, mensagens cloud-to-device e roteamento de telemetria para outros serviços do Azure. Os dispositivos podem usar MQTT, AMQP ou HTTPS, com autenticação por token SAS ou certificado X.509.

Ao usar MQTT com o IoT Hub, você trabalha dentro do modelo de dispositivos dele. Os dispositivos publicam telemetria em um topic específico do dispositivo, como devices/{device_id}/messages/events/, e recebem mensagens em devices/{device_id}/messages/devicebound/#. Atualizações de twins e direct methods têm os seus próprios topics reservados. O serviço é a contraparte de cada dispositivo, e não um broker que repassa mensagens entre clientes arbitrários.

Esse é um design deliberado para gestão de dispositivos e ingestão na nuvem. Ele simplesmente não é a mesma coisa que um broker MQTT de uso geral. A Microsoft também oferece um recurso de broker MQTT no Azure Event Grid voltado a cenários de publish/subscribe, que vale a pena avaliar se você quiser permanecer no Azure. Consulte a documentação atual da Microsoft para conhecer as capacidades exatas de cada serviço.

MQTT centrado em dispositivos vs. um broker MQTT completo

A coluna da esquerda vence quando a gestão de dispositivos e a integração com o Azure são o que mais importa. A coluna da direita vence quando você quer a semântica padrão do MQTT em todo lugar.

Sinais de que um broker MQTT completo se encaixa melhor

• Dashboards e aplicativos precisam de dados ao vivo diretamente. Com um broker completo, uma aplicação no navegador assina via Secure WebSocket sem um repasse pelo back-end.
• Dispositivos ou máquinas conversam entre si. Um controlador que assina o topic de um sensor é natural no MQTT e desajeitado em um modelo dispositivo-nuvem.
• Você está construindo um Unified Namespace. Uma hierarquia de topics ISA-95 precisa de um broker em que você seja dono da árvore de topics. Veja MQTT Sparkplug B e Unified Namespace.
• Você quer firmware portável. Topics e autenticação padrão tornam os dispositivos independentes de qualquer nuvem.
• Os seus sistemas estão espalhados por várias nuvens ou sites on-premises, como usinas e centros de distribuição em diferentes estados.

Mapeando conceitos do IoT Hub para MQTT padrão

O response topic do MQTT 5 é especialmente útil para substituir os direct methods: quem chama publica uma requisição com um response topic, e o dispositivo publica a resposta ali.

O que passa para você ao deixar o IoT Hub

Uma comparação justa inclui o trabalho que passa para o seu lado. O IoT Hub reúne registro de dispositivos, armazenamento de twins, invocação de métodos e roteamento. Com um broker simples, esses padrões passam a ser seus:

• Inventário de dispositivos. Mantenha no seu próprio sistema uma lista dos dispositivos, das suas credenciais e das versões de firmware.
• Convenções de estado. Definam o formato dos payloads de estado reportado e desejado e documentem-no para que todas as equipes de firmware sigam as mesmas regras.
• Segurança dos comandos. Defina quem pode publicar nos topics de comando e valide cada comando no dispositivo antes de executá-lo.
• Roteamento de dados. Opere e monitore os assinantes ou fluxos que levam os dados para armazenamento e análise.

Para muitas equipes, essas são tarefas pequenas e bem compreendidas. Para outras, especialmente as que gerenciam frotas muito grandes com provisionamento complexo, a gestão de dispositivos integrada de uma plataforma vale a pena. Decida levando em conta o tamanho da sua frota e a sua equipe.

Exemplo: código do dispositivo depois da migração

Aqui está um sketch para ESP32 com PubSubClient que publica telemetria e escuta comandos em topics definidos por você, conectando-se à ConnectMQ, um broker MQTT gerenciado, via TLS:

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

const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASS = "YOUR_WIFI_PASSWORD";
const char* MQTT_HOST = "broker.connectmq.com";
const int   MQTT_PORT = 8883;
const char* MQTT_USER = "YOUR_USERNAME";
const char* MQTT_PASS = "YOUR_PASSWORD";
const char* CLIENT_ID = "YOUR_CLIENT_ID";

const char* TOPIC_TELEMETRY = "site1/area1/line1/dev42/telemetry";
const char* TOPIC_CMD       = "site1/area1/line1/dev42/cmd";

WiFiClientSecure net;
PubSubClient mqtt(net);

void onMessage(char* topic, byte* payload, unsigned int length) {
  String msg;
  for (unsigned int i = 0; i < length; i++) msg += (char)payload[i];
  Serial.printf("Command on %s: %s\n", topic, msg.c_str());
}

void connectMqtt() {
  while (!mqtt.connected()) {
    Serial.print("Connecting to MQTT... ");
    if (mqtt.connect(CLIENT_ID, MQTT_USER, MQTT_PASS)) {
      Serial.println("connected");
      mqtt.subscribe(TOPIC_CMD, 1);
    } else {
      Serial.printf("failed, state=%d\n", mqtt.state());
      delay(5000);
    }
  }
}

void setup() {
  Serial.begin(115200);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) delay(500);
  // Em produção, fixe a CA ISRG Root X1 com net.setCACert(...)
  net.setInsecure();
  mqtt.setServer(MQTT_HOST, MQTT_PORT);
  mqtt.setCallback(onMessage);
}

void loop() {
  if (!mqtt.connected()) connectMqtt();
  mqtt.loop();

  static unsigned long last = 0;
  if (millis() - last > 10000) {
    last = millis();
    char payload[64];
    snprintf(payload, sizeof(payload), "{\"temp\":%.1f}", 20.0 + random(0, 50) / 10.0);
    mqtt.publish(TOPIC_TELEMETRY, payload);
  }
}

O setInsecure() serve apenas para um primeiro teste. Em produção, carregue o certificado raiz da Let's Encrypt com setCACert() para que o dispositivo verifique o broker. O tutorial de MQTT com ESP32 aborda o tratamento de certificados em detalhes.

Um caminho de migração em etapas

1. Projete a árvore de topics. Defina uma hierarquia como empresa/site/área/linha/dispositivo e separe os topics de telemetria, estado e comando.
2. Faça a bridge dos dados existentes. Rode um pequeno serviço que leia dos seus consumidores atuais do IoT Hub (por exemplo, o endpoint de eventos integrado) e republique nos topics do novo broker. Novos dashboards podem usar o broker imediatamente.
3. Substitua as rotas. Recrie cada rota do Azure como um assinante externo, um fluxo do Node-RED ou um output do Telegraf que grave no mesmo destino.
4. Migre um grupo piloto. Atualize o firmware ou a configuração do gateway de um punhado de dispositivos. Verifique o comportamento de reconexão e os limites do plano; na ConnectMQ, clientes MQTT 5 recebem o reason code 0x97 se uma cota for excedida.
5. Faça o rollout em ondas e mantenha a configuração anterior pronta até que cada onda esteja estável.

Solução de problemas depois da troca

• O dispositivo conecta e desconecta a cada poucos segundos. Dois dispositivos compartilham o mesmo client ID. Dê a cada dispositivo as suas próprias credenciais e o seu próprio client ID.
• O serviço de back-end não vê dados. Verifique o filtro da assinatura. Um filtro site1/+/telemetry não corresponde a site1/area1/line1/dev42/telemetry; use site1/# ou o número correto de níveis +.
• Os comandos chegam duas vezes. Com QoS 1, duplicatas são possíveis por design. Inclua um ID de comando e ignore as repetições. O guia de níveis de QoS do MQTT explica por quê.
• Um estado antigo aparece após o reinício. Retained messages persistem até serem substituídas ou apagadas. Publique um payload retido vazio para apagar uma.

Experimente um broker MQTT completo

Você pode explorar o modelo publish/subscribe antes de mudar qualquer dispositivo. Crie um broker Serverless gratuito, sem cartão de crédito, conecte um dispositivo de teste e um cliente no navegador e acompanhe as mensagens no explorador de topics ao vivo. Para um primeiro contato sem cadastro, o servidor MQTT público (gratuito) em broker.connectmq.com serve para testes e protótipos, nunca para dados de produção. Para um contexto mais amplo, leia o guia de broker MQTT na nuvem, compare com o artigo sobre a alternativa ao AWS IoT Core e revise o que um broker MQTT faz. Saiba mais em connectmq.com.

Perguntas frequentes

O Azure IoT Hub é um broker MQTT?

O IoT Hub suporta MQTT para comunicação com dispositivos, mas dentro de um modelo dispositivo-nuvem com topics reservados. Ele não foi projetado como um broker publish/subscribe genérico entre clientes arbitrários.

Como substituo os device twins por MQTT padrão?

Use retained messages em topics de estado reportado e desejado. Novos assinantes recebem imediatamente o último estado conhecido.

Posso continuar usando serviços do Azure depois de migrar para outro broker?

Sim. Um assinante externo ou um fluxo do Node-RED pode encaminhar dados do broker para qualquer serviço do Azure por meio das APIs normais dele.

Onde verifico as capacidades MQTT atuais do IoT Hub?

Use a documentação oficial do Azure IoT Hub da Microsoft, que descreve os recursos e limites de MQTT suportados na versão atual.