MQTT

MQTT est disponible en choisissant le protocole mqtt sur une requête WebSocket.

Configuration

Champ	Rôle
URL	L’adresse du courtier (mqtt://, mqtts://, ou WebSocket)
Sujet	Le sujet, porté par le champ Événement
Message	La charge publiée
QoS	0, 1 ou 2 — utilisée à la publication et à l’abonnement
Conserver (retain)	Marque le message comme retenu par le courtier
Identifiant client	Résolu par Handlebars ; généré automatiquement s’il est laissé vide
Utilisateur / Mot de passe	Identifiants du courtier ; le mot de passe accepte une valeur de type Secret
Keepalive	En secondes
S’abonner au sujet	Activé par défaut : à la connexion, Restorm s’abonne au sujet de la requête

Le sujet accepte les {{variables}} — capteurs/{{site}}/{{capteurId}} est un sujet parfaitement valable.

Testament (Last Will and Testament)

Quatre champs déclarent le message que le courtier publiera si votre client disparaît brutalement : sujet, charge, QoS et rétention du testament.

C’est exactement ce qu’il faut pour tester le comportement de votre système face à une déconnexion sale : configurez un testament, coupez la connexion, et vérifiez que l’abonné réagit.

Reconnexion

Le client MQTT se reconnecte automatiquement, avec un plafond de dix tentatives.

Dans un scénario

Connexion MQTT (qui s’abonne au sujet de la requête et émet un événement par message reçu), Publication MQTT (publie, avec la QoS et la rétention de la requête) et Fermeture connexion MQTT. Voir Connexions et flux.

Mode serveur

Restorm sait héberger un courtier MQTT local : un courtier par port, accessible en TCP brut et via une passerelle MQTT-sur-WebSocket. Voir Simuler WebSocket, Socket.IO et MQTT.

Importer depuis AsyncAPI

Un document AsyncAPI dont les canaux utilisent le protocole mqtt produit directement des requêtes MQTT (une par canal, en publication et en abonnement), avec des charges d’exemple construites depuis le schéma des messages. Voir Importer AsyncAPI.