Alternativa a Azure IoT Hub: pasar a un broker MQTT 3.1.1/5.0 completo

Merece la pena plantearse una alternativa a Azure IoT Hub cuando tu proyecto necesita una verdadera publicación/suscripción entre dispositivos, aplicaciones y servicios en lugar de un gateway de dispositivo a nube. Este artículo explica en qué se diferencia el soporte MQTT de IoT Hub, centrado en dispositivos, de un broker MQTT 3.1.1/5.0 completo, qué evaluar en cada lado y una ruta de migración por etapas a un broker estándar que mantiene tu flota en marcha durante todo el proceso.

Para qué está diseñado Azure IoT Hub

Azure IoT Hub es un servicio gestionado para conectar, administrar y comunicarse con dispositivos en Azure. Sus puntos fuertes están orientados a la flota: un registro de identidades de dispositivos, device twins, métodos directos, mensajes de la nube al dispositivo y enrutamiento de la telemetría hacia otros servicios de Azure. Los dispositivos pueden usar MQTT, AMQP o HTTPS, con autenticación mediante token SAS o certificado X.509.

Cuando usas MQTT con IoT Hub, trabajas dentro de su modelo de dispositivos. Los dispositivos publican la telemetría en un topic específico del dispositivo, como devices/{device_id}/messages/events/, y reciben mensajes en devices/{device_id}/messages/devicebound/#. Las actualizaciones de twins y los métodos directos tienen sus propios topics reservados. El servicio es la contraparte de cada dispositivo, no un broker que retransmite mensajes entre clientes arbitrarios.

Es un diseño deliberado para la gestión de dispositivos y la ingesta en la nube. Simplemente no es lo mismo que un broker MQTT de propósito general. Microsoft también ofrece una capacidad de broker MQTT en Azure Event Grid orientada a escenarios de publicación/suscripción, que vale la pena evaluar si quieres quedarte dentro de Azure. Consulta la documentación actual de Microsoft para conocer las capacidades exactas de cada servicio.

MQTT centrado en dispositivos vs un broker MQTT completo

La columna de la izquierda gana cuando lo que más importa es la gestión de dispositivos y la integración con Azure. La de la derecha gana cuando quieres semántica MQTT estándar en todas partes.

Señales de que un broker MQTT completo encaja mejor

• Los dashboards y las aplicaciones necesitan datos en vivo directamente. Con un broker completo, una aplicación de navegador se suscribe por Secure WebSocket sin un intermediario en el back end.
• Los dispositivos o las máquinas se comunican entre sí. Que un controlador se suscriba al topic de un sensor es natural en MQTT y forzado en un modelo de dispositivo a nube.
• Estás construyendo un Unified Namespace. Una jerarquía de topics ISA-95 necesita un broker en el que el árbol de topics sea tuyo. Consulta MQTT Sparkplug B y Unified Namespace.
• Quieres un firmware portable. Los topics y la autenticación estándar hacen que los dispositivos no dependan de ninguna nube concreta.
• Tus sistemas abarcan varias nubes o instalaciones on-premises.

Equivalencias entre conceptos de IoT Hub y MQTT estándar

El response topic de MQTT 5 es especialmente útil para sustituir los métodos directos: quien llama publica una petición con un response topic y el dispositivo publica allí su respuesta.

Lo que asumes al dejar IoT Hub

Una comparación justa incluye el trabajo que pasa a tu lado. IoT Hub incluye un registro de dispositivos, almacenamiento de twins, invocación de métodos y enrutamiento. Con un broker sin más, esos patrones son responsabilidad tuya:

• Inventario de dispositivos. Mantén en tu propio sistema una lista de los dispositivos, sus credenciales y sus versiones de firmware.
• Convenciones de estado. Acordad la forma de los payloads de estado notificado y deseado, y documentadla para que todos los equipos de firmware sigan las mismas reglas.
• Seguridad de los comandos. Define quién puede publicar en los topics de comandos y valida cada comando en el dispositivo antes de ejecutarlo.
• Enrutamiento de datos. Ejecuta y monitoriza los suscriptores o flujos que llevan los datos al almacenamiento y la analítica.

Para muchos equipos son tareas pequeñas y bien conocidas. Para otros, sobre todo los que gestionan flotas muy grandes con aprovisionamiento complejo, merece la pena conservar la gestión de dispositivos integrada de una plataforma. Decide teniendo en cuenta el tamaño de tu flota y tu equipo.

Ejemplo: código del dispositivo tras la migración

Aquí tienes un sketch para ESP32 con PubSubClient que publica telemetría y escucha comandos en topics que defines tú, conectándose a ConnectMQ por 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);
  // For production, pin the ISRG Root X1 CA with 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);
  }
}

setInsecure() es solo para una primera prueba. En producción, carga el certificado raíz de Let's Encrypt con setCACert() para que el dispositivo verifique el broker. El tutorial de ESP32 con MQTT trata en detalle la gestión de certificados.

Una ruta de migración por etapas

1. Diseña el árbol de topics. Decide una jerarquía como empresa/planta/área/línea/dispositivo y separa los topics de telemetría, estado y comandos.
2. Tiende un puente con los datos existentes. Ejecuta un pequeño servicio que lea de tus consumidores actuales de IoT Hub (por ejemplo, el endpoint de eventos integrado) y republique en los topics del nuevo broker. Los nuevos dashboards pueden usar el broker de inmediato.
3. Sustituye las rutas. Recrea cada ruta de Azure como un suscriptor externo, un flujo de Node-RED o una salida de Telegraf que escriba en el mismo destino.
4. Traslada un grupo piloto. Actualiza el firmware o la configuración del gateway de unos pocos dispositivos. Comprueba el comportamiento de reconexión y los límites del plan; en ConnectMQ, los clientes MQTT 5 reciben el reason code 0x97 si se supera una cuota.
5. Despliega por oleadas y mantén lista la configuración anterior hasta que cada oleada sea estable.

Solución de problemas tras el cambio

• El dispositivo se conecta y se desconecta cada pocos segundos. Dos dispositivos comparten un mismo client ID. Da a cada dispositivo sus propias credenciales y su propio client ID.
• El servicio de back end no ve datos. Revisa el filtro de suscripción. Un filtro site1/+/telemetry no coincide con site1/area1/line1/dev42/telemetry; usa site1/# o el número correcto de niveles +.
• Los comandos llegan dos veces. Con QoS 1, los duplicados son posibles por diseño. Incluye un ID de comando e ignora las repeticiones. La guía de niveles de QoS de MQTT explica por qué.
• Aparece un estado antiguo tras reiniciar. Los retained messages persisten hasta que se sustituyen o se borran. Publica un payload retenido vacío para borrar uno.

Prueba un broker MQTT completo

Puedes explorar el modelo de publicación/suscripción antes de cambiar ningún dispositivo. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0 completos. Crea un broker Serverless gratuito sin tarjeta de crédito, conecta un dispositivo de prueba y un cliente de navegador y observa los mensajes en el explorador de topics en vivo. Para una primera prueba sin registro, el servidor MQTT público gratuito de broker.connectmq.com sirve para prototipos, nunca para datos de producción. Para un contexto más amplio, lee la guía del broker MQTT en la nube, compara con el artículo sobre la alternativa a AWS IoT Core y repasa qué hace un broker MQTT. Más información en connectmq.com.

Preguntas frecuentes

¿Es Azure IoT Hub un broker MQTT?

IoT Hub admite MQTT para la comunicación con dispositivos, pero dentro de un modelo de dispositivo a nube con topics reservados. No está diseñado como un broker de publicación/suscripción general entre clientes arbitrarios.

¿Cómo sustituyo los device twins con MQTT estándar?

Usa retained messages en topics de estado notificado y deseado. Los nuevos suscriptores reciben de inmediato el último estado conocido.

¿Puedo seguir usando servicios de Azure tras pasar a otro broker?

Sí. Un suscriptor externo o un flujo de Node-RED puede reenviar datos del broker a cualquier servicio de Azure a través de sus API habituales.

¿Dónde consulto las capacidades MQTT actuales de IoT Hub?

En la documentación oficial de Azure IoT Hub de Microsoft, que describe las funciones MQTT admitidas y los límites de la versión actual.