Comment tester un broker MQTT (en ligne, CLI et code)

Tester un broker MQTT se résume à une seule question : un client peut-il se connecter, publier un message et le recevoir en retour ? Tout le reste — QoS, messages retenus (retained), authentification, latence — repose sur cette boucle. Ce guide la parcourt de trois façons : dans le navigateur, en ligne de commande et dans le code.

Ce qu’il faut vérifier lors du test d’un broker

1. Accessibilité — le nom d’hôte se résout et le port est ouvert (TCP 1883, TLS 8883 ou un port WebSocket). Voir les ports MQTT expliqués.
2. Handshake — le broker répond au CONNECT par un CONNACK réussi. Des identifiants ou un client ID incorrects échouent à cette étape.
3. Aller-retour — un message publié sur un topic est bien livré à un abonné de ce même topic.
4. Les fonctionnalités dont vous dépendez — acquittements QoS 1/2, messages retenus, Last Will, propriétés MQTT 5.
5. Latence et stabilité — la durée de l’aller-retour et la tenue de la connexion au fil des intervalles de keep-alive.

1. Tester un broker MQTT en ligne

Le plus rapide est d’utiliser un client dans le navigateur. Les navigateurs ne parlent MQTT qu’au travers des WebSockets : il vous faut donc l’endpoint wss:// du broker — chaque broker de notre liste de brokers publics l’indique.

1. Ouvrez le client MQTT en ligne et choisissez un broker.
2. Cliquez sur Connect. Un statut vert signifie que le CONNACK est bien revenu.
3. Abonnez-vous à un topic unique comme testmqtt/demo-42/#.
4. Publiez {"hello":"world"} sur testmqtt/demo-42/hello et regardez-le apparaître dans la liste des messages.

Essayez-le dans le client MQTT en ligne

2. Tester en ligne de commande

Les clients Mosquitto sont les outils CLI de référence. Ouvrez deux terminaux — un abonné, un éditeur :

mosquitto_sub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/#' -v

mosquitto_pub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/hello' -m 'hello from the CLI'

Ajoutez -u et -P pour le nom d’utilisateur et le mot de passe, -q 1 pour tester la QoS 1, et --cafile avec le port 8883 pour tester TLS.

3. Tester dans le code

Un petit script est le test le plus reproductible — vous pouvez l’exécuter en CI ou comme health check. Voici un test d’aller-retour avec MQTT.js qui mesure aussi la latence :

import mqtt from 'mqtt';

const topic = `testmqtt/${Math.random().toString(16).slice(2, 8)}/ping`;
const client = mqtt.connect('wss://broker.hivemq.com:8884/mqtt');

client.on('connect', () => {
  client.subscribe(topic, { qos: 1 }, () => {
    const sentAt = Date.now();
    client.publish(topic, String(sentAt), { qos: 1 });
  });
});

client.on('message', (_topic, payload) => {
  console.log(`round trip: ${Date.now() - Number(payload)} ms`);
  client.end();
});

client.on('error', (err) => {
  console.error('connection failed:', err.message);
  process.exit(1);
});

Tester la QoS, les messages retenus et le Last Will

• QoS — publiez en QoS 1 et 2 et vérifiez que le callback de publication se déclenche. Voir les niveaux de QoS MQTT.
• Messages retenus — publiez avec retain, déconnectez-vous, reconnectez-vous et abonnez-vous : la dernière valeur doit arriver immédiatement. Voir les messages retenus.
• Last Will — connectez un client avec un message de testament, coupez-le sans déconnexion propre et vérifiez que les abonnés reçoivent le testament. Voir Last Will and Testament.

Si le test échoue

Un timeout signifie généralement un port bloqué ou un mauvais transport (port TCP depuis un navigateur). Un refus immédiat pointe vers les identifiants, un conflit de client ID ou les ACL. Notre guide des erreurs de connexion MQTT associe chaque code de raison du CONNACK à une solution.

Questions fréquentes