Node.js Accueil
Chapitres :

Node.js Chapitre 7
Utiliser MQTT pour le temps-réel avec des modules externes :

Dans un projet de type « système » (justement le sujet du cours), plusieurs modules doivent pouvoir interagir entre eux, et ce en temps réel. Pour étendre l’exemple précédemment expliqué, imaginons maintenant plusieurs modules de type Raspberry, chacun d’eux en lien avec des capteurs et des actionneurs. Imaginons également qu’on désire « centraliser » la supervision de tous ces modules, via une application Web unique. Dans un tel schéma d’architecture, la nécessité sera d’établir des liens de communications événementiels de/vers tous ces modules, et de/vers un module central qui ferait office de serveur Web.

Beaucoup de choix technologies pourraient satisfaire ce besoin, dépendamment de beaucoup de critères (connectivité, protocoles, vitesse de communication, etc.). Dans le cas qui nous concerne, on pourrait imaginer une communication entre modules portée par IP (Ethernet ou Wifi), mais qui nous ouvre les portes du temps réel.

Un des choix les plus judicieux pour un cas comme celui-ci est le protocole MQTT : c’est un protocole porté par TCP/IP, facile à mettre en place, du type « publication / souscription ».

Chaque module qui se connecte à ce service a le choix de « souscrire » ou non à un ou plusieurs « canaux » d’informations (sujets). Et il a l’option également d’émettre (« publier ») un message avec un sujet et un corps de message. Les messages sont gérés par un « distributeur de message » (« broker »), un programme qui gèrera toute cette logistique de souscriptions et publications sur le réseau local commun à chaque module et à lui-même. Tout message émis comportera un sujet et ne sera reçu que par ceux qui souscrivent au même sujet (« topic »).

Des librairies « clients » MQTT existent dans la plupart des langages de programmation les plus communs, dont C/C++ et JavaScript. Différents logiciels « broker » MQTT sont disponibles, libres de droits d’usage, pour Windows et Linux.

7.1. Fonctionnement des « topic »

Les sujets des messages « topics » du protocole MQTT suivent une structure hiérarchisée (comme les dossiers sur un disque) et des « wildcards » « + » et « # ».

Exemples :

- Si je souscris au topic « MAISON/SALON », je recevrai uniquement les messages postés avec le même topic.

- Mais si je souscris au topic « MAISON/# », je recevrai les messages postés avec « MAISON/SALON », ou encore « MAISON/CHAMBRE », ou même « MAISON/SALLEDEBAIN/TEMPERATURE ».

- De plus, si je souscris au topic « MAISON/+/TEMPERATURE », je recevrai les messages issus de « MAISON/SALON/TEMPERATURE » ou encore « MAISON/CUISINE/TEMPERATURE », mais pas ceux issus de « MAISON/SALON/HUMIDITE » par exemple.

Plus de détails ici : https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

Ainsi il est essentiel dans un projet basé sur MQTT de bien définir la hiérarchie modulaire avant de commencer.

7.2. Mise en place des outils

Outre l’appartenance de chaque « client » au même réseau sur un même segment LAN, la mise en place du protocole MQTT exige également qu’un programme de type « broker » MQTT soit en cours d’exécution sur une machine également sur ce même réseau. Différents programmes « broker » MQTT existent. Parmi les plus célèbres :

- HiveMQ : gratuit si utilisé de façon limitée, n’existe qu’en ligne (connexion distante).

- Mosquitto : gratuit inconditionnellement. Écrit en C, très léger. Le plus populaire. Disponible pour Windows et Linux sous forme d’exécutif (connexion locale).

- Mosca : écrit en Node.js, moins « généreux » que mosquitto. Connexion locale.

Également, même si ce n’est pas indispensable pour le fonctionnement, on peut désirer s’équiper d’un « client » pour surveiller le trafic MQTT, afin de faciliter le travail de développement et déverminage. Parmi les plus communs, on retiendra :

- MQTT.fx : programme exécutable qui s’installe sur Linux ou Windows.

- MQTTLens : extension pour navigateur Chrome.