Relier vos capteurs et machines MQTT à votre logiciel métier

Comment un logiciel métier reçoit-il des données MQTT ?

Un logiciel métier reçoit des données MQTT en s'abonnant à un broker, et non en appelant l'API d'un éditeur. L'équipement publie (capteur, automate, passerelle), le broker redistribue, les abonnés consomment : le capteur ignore votre logiciel, et votre logiciel ignore l'adresse du capteur. Il n'y a pas de webhook au sens habituel, puisque le broker transmet chaque message dès sa publication ; et le logiciel peut à son tour publier une consigne sur un topic auquel l'automate est abonné.

Ces règles figurent dans la page de manuel mqtt(7) d'Eclipse Mosquitto, broker libre qui implémente les versions 5.0, 3.1.1 et 3.1 du protocole.

Ce que le protocole garantit, et ce qu'il faut construire autour

MQTT garantit l'acheminement selon le niveau de qualité de service choisi, mais ne fixe ni le format des données ni leur conservation. La spécification MQTT 5.0 d'OASIS et la documentation de Mosquitto décrivent ces mécanismes :

MQTT 5.0 ajoute des codes de raison (0x86 pour un mot de passe refusé, 0x87 pour un accès non autorisé) et des propriétés utilisateur. Le contenu reste libre hors topics réservés, rappelle AWS IoT Core, dont le moteur de règles analyse par des requêtes SQL les messages au format JSON. La spécification Sparkplug de la fondation Eclipse (version 3.0 du 21 octobre 2022) normalise l'espace de noms des topics, le format des messages et l'état des sessions, pour la supervision (SCADA) et les IHM : utile quand plusieurs fournisseurs de capteurs cohabitent.

Comment authentifier les équipements et le logiciel ?

Un client MQTT s'authentifie à la connexion : identifiant et mot de passe dans le paquet CONNECT, certificat client TLS, ou, en MQTT 5.0, authentification étendue par le paquet AUTH. Les droits se règlent ensuite topic par topic.

• Chiffrement. Chez Mosquitto, le TLS s'active avec un certificat et une clé serveur ; require_certificate impose un certificat à chaque client, et use_identity_as_username reprend son nom commun comme identifiant.
• Accès anonyme. Selon la page de manuel mosquitto.conf, allow_anonymous vaut false par défaut dès qu'un listener est déclaré.
• Droits par topic. Une liste de contrôle d'accès, ou le plugin Dynamic Security, borne ce que chaque compte publie ou lit : une sonde de température n'a pas à publier de consigne machine.
• Broker géré. AWS IoT Core rejette les connexions sans extension TLS SNI.

Le port 1883, sans chiffrement, est celui de Mosquitto par défaut. Il se tolère sur un réseau d'usine cloisonné ; dès que les messages traversent Internet, le TLS devient la règle.

Quelles limites publiées selon le broker choisi ?

Selon la spécification, la longueur restante d'un paquet MQTT peut atteindre 268 435 455 octets : les vraies bornes viennent donc du broker.

Pour un premier essai, le projet Mosquitto exploite le serveur public test.mosquitto.org (1883 en clair, 8883 en TLS). Ses données sont publiques et il ne convient pas à la production : la recette se fait sur un broker privé.

Quatre flux MQTT à brancher sur un logiciel de gestion

1. Le compteur de la presse alimente l'ordre de fabrication. L'automate publie chaque minute, en QoS 1, les pièces bonnes et les rebuts. Le service retrouve l'ordre de fabrication en cours sur la presse et met à jour son avancement. La traçabilité de production repose sur ces enregistrements horodatés.
2. La chambre froide prévient avant la perte. Une sonde publie la température toutes les 30 secondes en QoS 0 ; le logiciel garde une valeur par minute et alerte quand le seuil est dépassé dix minutes de suite.
3. Le testament signale la machine muette. Si un équipement disparaît sans se déconnecter, le broker publie « hors ligne » et le tableau de bord passe la machine en arrêt non justifié, au lieu d'afficher sa dernière cadence.
4. La recette descend vers la ligne. Le logiciel publie la recette du prochain lot ; l'automate confirme sur un topic d'acquittement, et faute de confirmation dans les deux minutes, l'opérateur est alerté.

Doublons, coupures, données personnelles : où se cachent les pannes ?

• Les doublons du QoS 1. Chaque message porte un identifiant créé par l'équipement (numéro de séquence), et le service écarte ce qu'il a déjà enregistré.
• L'heure de la mesure. La mesure est horodatée à la source, pas à la réception.
• La valeur retenue périmée. Un message retenu peut décrire une machine arrêtée depuis une semaine : le service compare son horodatage à l'heure courante avant de l'afficher comme état actuel.
• La file qui déborde. Si le logiciel s'arrête une nuit, les messages s'accumulent jusqu'au plafond du broker, qui se dimensionne et se surveille.
• Le topic fourre-tout. Le plan de nommage (site, ligne, machine, mesure) est fixé au cadrage et versionné avec le code.
• Les données personnelles. La position d'un véhicule ou le badge d'un opérateur relèvent du RGPD, détaillé dans notre guide RGPD et logiciel métier.

D'après la documentation de Mosquitto, les statistiques du broker (hiérarchie $SYS) ne sont pas reçues par un abonnement à « # » : il faut s'abonner à $SYS/# pour superviser le flux.

Passerelle, plateforme IoT ou service développé : que choisir ?

• Vos machines parlent déjà un protocole industriel. Si l'automate expose ses données en OPC UA ou en Modbus, une passerelle du marché peut les republier en MQTT, ou le logiciel peut les lire directement : voir nos pages OPC UA et Modbus.
• Une supervision existe. Relier la gestion à la supervision plutôt qu'à chaque capteur reste souvent plus simple, comme expliqué dans relier automates et supervision à l'ERP.
• Des centaines d'objets dispersés. Un broker géré comme AWS IoT Core apporte la montée en charge et la gestion des certificats, en contrepartie de quotas.

Le développement prend l'avantage quand les messages doivent devenir des données de gestion : rapprochement avec un ordre de fabrication, un client ou un contrat, règles d'alerte propres à votre métier, historique exploitable.

Ce que YMHB Web installe et vous remet

YMHB Web relie MQTT au logiciel métier par un service d'ingestion en Node.js qui s'abonne aux topics, déduplique les messages et les range dans une base PostgreSQL. Le cadrage recense les équipements et ce qu'ils publient ; le chiffrage en forfait global suit, puis la construction flux par flux sur un broker de recette.

• Broker, comptes, certificats et droits par topic sont créés sur votre infrastructure ou votre compte cloud, à votre nom.
• Le plan des topics et le format des messages sont documentés pour tout automaticien ou prestataire.
• Une alerte part quand un équipement se tait trop longtemps ou qu'une file grossit.
• Le code source vous appartient au paiement intégral.

YMHB Web programme aussi automates et IHM en interne, utile quand il faut modifier ce que publie l'équipement : voir automates, IHM et supervision.