Alternative à EMQX Cloud : choisir un broker MQTT managé selon les fonctionnalités dont vous avez vraiment besoin

Une alternative à EMQX Cloud ne vaut la peine d'être évaluée qu'une fois que vous savez de quelles fonctionnalités de broker votre projet dépend vraiment. Ce guide vous aide à lister ces exigences, à les associer aux capacités des brokers MQTT managés et à voir dans quels cas un broker léger, avec décodage Sparkplug B et vues ISA-95 intégrés, convient mieux qu'une vaste plateforme de données.

EMQX en contexte

EMQX est un broker MQTT open source largement utilisé, développé par EMQ, réputé pour sa scalabilité horizontale et son large éventail de fonctionnalités, dont un moteur de règles de type SQL et des intégrations de données avec des systèmes externes. EMQX Cloud le propose en service managé sur plusieurs niveaux d'offre. Pour les équipes qui veulent traiter les messages et les router vers des bases de données à l'intérieur même du broker, c'est un véritable atout.

La disponibilité des fonctionnalités peut varier selon les niveaux d'offre et évolue dans le temps : consultez la documentation actuelle d'EMQ pour savoir ce que comprend chaque niveau d'EMQX Cloud avant de comparer. Le même conseil vaut pour chaque éditeur cité dans cet article.

Partez des exigences, pas des listes de fonctionnalités

Les matrices de fonctionnalités récompensent le produit qui a la liste la plus longue. Votre projet, lui, récompense le produit qui fait ce dont vous avez besoin avec le moins de complexité d'exploitation. Notez vos réponses à ces questions avant de regarder le moindre éditeur :

1. Où le traitement des messages aura-t-il lieu ? Dans le broker, dans un service séparé ou dans des outils que vous utilisez déjà, comme Node-RED ou un moteur de traitement de flux ?
2. Qui consomme les données ? Tableaux de bord, historians, systèmes MES ou ERP, applications mobiles ?
3. Quels formats de payload arrivent ? JSON, Protobuf Sparkplug B, valeurs brutes, binaire propriétaire ?
4. Combien de connexions et de messages par seconde prévoyez-vous dans un an ?
5. Quelles fonctionnalités MQTT 5 utilisez-vous ? Abonnements partagés, expiration des messages, alias de topic ?
6. Quel modèle de déploiement est requis ? Mutualisé, dédié, dans votre propre compte cloud ou auto-géré ?
7. Qui le déboguera à 2 heures du matin ? De quels outils aura-t-il besoin pour voir les topics et payloads en direct ?

Associer les besoins aux capacités des brokers

La tendance est claire : si le routage vers des bases de données à l'intérieur du broker est une exigence centrale, une plateforme dotée d'un moteur de règles vous conviendra peut-être mieux. Si votre principale difficulté est de comprendre et d'organiser les données industrielles qui transitent par le broker, un broker doté d'un outillage Sparkplug et ISA-95 intégré peut vous y mener plus vite, avec moins de pièces mobiles.

Pourquoi le décodage Sparkplug B compte pour les équipes industrielles

Les payloads Sparkplug B sont encodés en Protobuf. Tous les brokers les relaient, mais lorsque vous vous abonnez avec un client générique, vous ne voyez que du bruit binaire. Pendant la mise en service et le dépannage, cela ralentit tout le monde. Le décodage intégré à la console du broker permet à un ingénieur de lire directement les noms de métriques, les valeurs et les horodatages.

ConnectMQ va un cran plus loin et republie les données Sparkplug B dans des topics de style ISA-95. Un message publié sur :

spBv1.0/factory1/DDATA/line1/cnc1

est également mis à disposition sur :

connectmq/factory1/production/line1/cnc1/telemetry

Les consommateurs qui ne comprennent pas Sparkplug, comme un simple tableau de bord, peuvent s'abonner au topic lisible. Le guide MQTT Sparkplug B et Unified Namespace explique les concepts sous-jacents.

Intégrer sans moteur de règles

Si vous choisissez un broker léger, les intégrations vivent en dehors de lui, dans des clients MQTT standard. C'est un schéma familier pour de nombreuses équipes, qui garde chaque élément remplaçable. Voici un abonné Python minimal (paho-mqtt 2.x) qui écoute les topics ISA-95 republiés et transmet chaque message à votre propre fonction de stockage :

import json
import ssl
import paho.mqtt.client as mqtt

TOPIC = "connectmq/factory1/production/#"


def store(topic, payload):
    # À remplacer par votre historian, votre base de données ou un appel 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()

Remplacez store par une écriture InfluxDB, un POST HTTP vers votre MES ou un message vers votre pipeline de données existant. Node-RED et Telegraf peuvent faire la même chose par configuration plutôt que par code.

Les questions à trancher pendant un essai

• Visibilité des payloads. Connectez une vraie passerelle d'automate ou un vrai nœud edge. Votre équipe peut-elle lire ses données dans la console en quelques minutes ?
• Organisation des topics. Le broker vous aide-t-il à visualiser la hiérarchie de l'usine, ou seulement une liste plate de topics ?
• Effort d'intégration. Combien de temps faut-il pour faire arriver un flux de données dans votre historian ?
• Limites. Que se passe-t-il aux limites de votre plan ? Sur ConnectMQ, le dépassement d'un quota renvoie le reason code MQTT 5 0x97 (quota exceeded), que vos clients peuvent journaliser et traiter.
• Porte de sortie. Pourriez-vous déplacer les appareils ailleurs en ne changeant que les paramètres de connexion ? Voir dépendance fournisseur MQTT.

Pensez aux compétences de l'équipe, pas seulement aux fonctionnalités

Une capacité n'est utile que si votre équipe sait l'exploiter. Un moteur de règles dans le broker est puissant, mais les règles deviennent une partie de votre logique de production et doivent être versionnées, testées et relues comme n'importe quel code. À l'inverse, déporter les intégrations dans des outils externes implique que quelqu'un exploite et supervise ces outils. Aucune des deux approches n'est gratuite.

Demandez-vous qui sera responsable du chemin des données dans deux ans. Des automaticiens à l'aise avec les flows Node-RED préféreront peut-être des intégrations qu'ils peuvent voir et modifier visuellement. Une équipe logicielle disposant déjà d'une pile de traitement de flux préférera peut-être que le broker reste un transport simple et rapide. Une équipe qui n'a ni l'un ni l'autre appréciera peut-être une plateforme plus intégrée. Adapter l'architecture aux personnes qui la maintiendront compte généralement plus que n'importe quelle fonctionnalité d'un tableau comparatif.

Quand un broker léger n'est pas le bon choix

Par souci d'équité : si vous voulez un produit unique qui gère l'ingestion, la transformation, le routage vers de nombreuses bases de données et le traitement de flux, un broker doté d'un moteur de règles et d'intégrations de données vous évitera de construire cette couche. ConnectMQ ne propose ni moteur de règles, ni webhooks, ni bridges natifs vers des bases de données, ni contrôle du clustering du broker. Choisissez en fonction de l'architecture que votre équipe souhaite prendre en charge.

Essayez un broker léger, pensé pour l'industrie

Vous pouvez tester gratuitement le décodage Sparkplug et les vues ISA-95 sur vos propres données. Lancez un broker Serverless gratuit sans carte bancaire, pointez-y un nœud edge ou une passerelle, puis ouvrez l'explorateur de topics en direct et la vue des appareils. Pour un contexte plus large, lisez le guide du broker MQTT cloud, comparez avec notre grille sur l'alternative à HiveMQ Cloud et découvrez ce qu'un broker MQTT managé prend en charge pour vous. Pour de simples essais de protocole sans compte, le serveur MQTT public gratuit broker.connectmq.com est disponible, réservé aux tests et aux prototypes, jamais aux données de production. Plus d'informations sur connectmq.com.

Questions fréquentes

Les clients EMQX peuvent-ils se connecter à ConnectMQ sans modification ?

Les clients qui utilisent MQTT 3.1.1 ou 5.0 standard fonctionnent avec n'importe quel broker conforme. Seuls l'hôte, le port, les identifiants et le client ID changent, sauf si vous dépendez de fonctionnalités propres à l'éditeur.

ConnectMQ dispose-t-il d'un moteur de règles comme EMQX ?

Non. Le traitement et les intégrations sont assurés par des clients MQTT externes comme Node-RED, Telegraf ou vos propres services.

Le décodage Sparkplug B est-il nécessaire pour utiliser Sparkplug ?

Non, n'importe quel broker peut transporter du Sparkplug B. Le décodage dans la console du broker rend simplement les données lisibles par des humains sans outils supplémentaires.

Où vérifier les fonctionnalités actuelles d'EMQX Cloud ?

Consultez la documentation officielle et les pages tarifaires d'EMQ, car les niveaux d'offre, les limites et les fonctionnalités évoluent avec le temps.