Alternative à Azure IoT Hub : passer à un véritable broker MQTT 3.1.1/5.0

Une alternative à Azure IoT Hub mérite d'être envisagée lorsque votre projet a besoin d'un véritable publish/subscribe entre appareils, applications et services, plutôt que d'une passerelle appareil-vers-cloud. Cet article explique en quoi la prise en charge de MQTT centrée sur les appareils d'IoT Hub diffère d'un broker MQTT 3.1.1/5.0 complet, ce qu'il faut évaluer de chaque côté, et propose un chemin de migration par étapes vers un broker MQTT managé conforme aux standards, qui maintient votre flotte en fonctionnement tout au long du processus.

Ce pour quoi Azure IoT Hub est conçu

Azure IoT Hub est un service managé pour connecter, gérer et faire communiquer des appareils dans Azure. Ses points forts sont orientés flotte : un registre d'identités des appareils, des device twins, des méthodes directes, des messages cloud-vers-appareil et le routage de la télémétrie vers d'autres services Azure. Les appareils peuvent utiliser MQTT, AMQP ou HTTPS, avec une authentification par jeton SAS ou certificat X.509.

Quand vous utilisez MQTT avec IoT Hub, vous travaillez dans son modèle d'appareil. Les appareils publient leur télémétrie sur un topic propre à chaque appareil, comme devices/{device_id}/messages/events/, et reçoivent les messages sur devices/{device_id}/messages/devicebound/#. Les mises à jour de twin et les méthodes directes ont leurs propres topics réservés. Le service est l'interlocuteur de chaque appareil, et non un broker qui relaie des messages entre des clients quelconques.

C'est une conception délibérée pour la gestion des appareils et l'ingestion dans le cloud. Ce n'est simplement pas la même chose qu'un broker MQTT généraliste. Microsoft propose également une capacité de broker MQTT dans Azure Event Grid, destinée aux scénarios publish/subscribe, qui mérite d'être évaluée si vous voulez rester dans Azure. Consultez la documentation actuelle de Microsoft pour connaître les capacités exactes de chaque service.

MQTT centré appareils ou broker MQTT complet

La colonne de gauche l'emporte quand la gestion des appareils et l'intégration Azure priment. Celle de droite l'emporte quand vous voulez une sémantique MQTT standard partout.

Les signes qu'un broker MQTT complet convient mieux

• Les tableaux de bord et applications ont besoin de données en direct. Avec un broker complet, une application web s'abonne via Secure WebSocket sans relais back-end.
• Des appareils ou des machines communiquent entre eux. Un contrôleur abonné au topic d'un capteur est naturel en MQTT et malcommode dans un modèle appareil-vers-cloud.
• Vous construisez un Unified Namespace. Une hiérarchie de topics ISA-95 nécessite un broker dont vous maîtrisez l'arborescence de topics. Voir MQTT Sparkplug B et Unified Namespace.
• Vous voulez un firmware portable. Des topics et une authentification standard rendent les appareils indépendants de tout cloud.
• Vos systèmes s'étendent sur plusieurs clouds ou sites sur site.

Faire correspondre les concepts d'IoT Hub au MQTT standard

Le response topic de MQTT 5 est particulièrement utile pour remplacer les méthodes directes : l'appelant publie une requête avec un response topic, et l'appareil y publie sa réponse.

Ce que vous prenez en charge en quittant IoT Hub

Une comparaison honnête inclut le travail qui vous revient. IoT Hub regroupe un registre d'appareils, le stockage des twins, l'invocation de méthodes et le routage. Avec un simple broker, ces schémas sont à votre charge :

• Inventaire des appareils. Tenez la liste des appareils, de leurs identifiants et de leurs versions de firmware dans votre propre système.
• Conventions d'état. Mettez-vous d'accord sur la forme des payloads d'état rapporté et souhaité, et documentez-la pour que toutes les équipes firmware suivent les mêmes règles.
• Sécurité des commandes. Définissez qui peut publier sur les topics de commande et validez chaque commande sur l'appareil avant d'agir.
• Routage des données. Exploitez et supervisez les abonnés ou les flows qui acheminent les données vers le stockage et l'analytique.

Pour de nombreuses équipes, ce sont des tâches modestes et bien maîtrisées. Pour d'autres, notamment celles qui gèrent de très grandes flottes avec un provisioning complexe, la gestion des appareils intégrée d'une plateforme vaut la peine d'être conservée. Décidez en tenant compte de la taille de votre flotte et de votre équipe.

Exemple : le code de l'appareil après la migration

Voici un sketch ESP32 utilisant PubSubClient qui publie de la télémétrie et écoute les commandes sur des topics que vous définissez, en se connectant à ConnectMQ en 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);
  // En production, épinglez la CA ISRG Root X1 avec 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() ne sert qu'à un premier test. En production, chargez le certificat racine Let's Encrypt avec setCACert() pour que l'appareil vérifie le broker. Le tutoriel ESP32 MQTT détaille la gestion des certificats.

Un chemin de migration par étapes

1. Concevoir l'arborescence de topics. Choisissez une hiérarchie comme entreprise/site/zone/ligne/appareil et séparez les topics de télémétrie, d'état et de commande.
2. Relayer les données existantes. Exécutez un petit service qui lit depuis vos consommateurs IoT Hub actuels (par exemple l'endpoint d'événements intégré) et republie vers les topics du nouveau broker. Les nouveaux tableaux de bord peuvent utiliser le broker immédiatement.
3. Remplacer les routes. Recréez chaque route Azure sous la forme d'un abonné externe, d'un flow Node-RED ou d'une sortie Telegraf qui écrit vers la même destination.
4. Déplacer un groupe pilote. Mettez à jour le firmware ou la configuration de la passerelle pour une poignée d'appareils. Vérifiez le comportement de reconnexion et les limites du plan ; sur ConnectMQ, les clients MQTT 5 reçoivent le reason code 0x97 en cas de dépassement de quota.
5. Déployer par vagues en gardant la configuration précédente prête jusqu'à ce que chaque vague soit stable.

Dépannage après la bascule

• L'appareil se connecte puis se déconnecte toutes les quelques secondes. Deux appareils partagent un même client ID. Donnez à chaque appareil ses propres identifiants et son propre client ID.
• Le service back-end ne voit aucune donnée. Vérifiez le filtre d'abonnement. Un filtre site1/+/telemetry ne correspond pas à site1/area1/line1/dev42/telemetry ; utilisez site1/# ou le bon nombre de niveaux +.
• Les commandes arrivent en double. En QoS 1, les doublons sont possibles par conception. Incluez un identifiant de commande et ignorez les répétitions. Le guide des niveaux de QoS MQTT explique pourquoi.
• Un ancien état réapparaît après un redémarrage. Les retained messages persistent jusqu'à ce qu'ils soient remplacés ou effacés. Publiez un payload retenu vide pour en effacer un.

Essayez un broker MQTT complet

Vous pouvez explorer le modèle publish/subscribe avant de modifier le moindre appareil. Créez un broker Serverless gratuit sans carte bancaire, connectez un appareil de test et un client navigateur, et regardez les messages dans l'explorateur de topics en direct. Pour de premiers essais sans compte, le serveur MQTT public gratuit broker.connectmq.com convient aussi, mais uniquement pour des tests et des prototypes, jamais pour des données de production. Pour un contexte plus large, lisez le guide du broker MQTT dans le cloud, comparez avec l'article sur l'alternative à AWS IoT Core et revoyez le rôle d'un broker MQTT. Plus d'informations sur connectmq.com.

Questions fréquentes

Azure IoT Hub est-il un broker MQTT ?

IoT Hub prend en charge MQTT pour la communication avec les appareils, mais dans un modèle appareil-vers-cloud avec des topics réservés. Il n'est pas conçu comme un broker publish/subscribe généraliste entre des clients quelconques.

Comment remplacer les device twins par du MQTT standard ?

Utilisez des retained messages sur des topics d'état rapporté et souhaité. Les nouveaux abonnés reçoivent immédiatement le dernier état connu.

Puis-je continuer à utiliser les services Azure après être passé à un autre broker ?

Oui. Un abonné externe ou un flow Node-RED peut transférer les données du broker vers n'importe quel service Azure via ses API habituelles.

Où vérifier les capacités MQTT actuelles d'IoT Hub ?

Consultez la documentation officielle d'Azure IoT Hub de Microsoft, qui décrit les fonctionnalités MQTT prises en charge et les limites de la version actuelle.