Scaleway IoT Hub - À la découverte des Topics MQTT

L'Internet des objets, ou IoT, est un concept regroupant les objets connectés et un vaste écosystème de services pour ces objets afin de les transformer en appareils intelligents.

Prenons l'exemple d'un ordinateur connecté à Internet sans moteur de recherche, e-mails, e-shops, streaming vidéo, etc. - il n'aura pas beaucoup de valeur. Il en va de même pour les appareils connectés. Pour rendre des appareils de la vie de tous les jours intelligents, tels que des appareils electroménager, des ampoules, des réfrigérateurs, des étiquettes d'expédition, des voitures ou même des villes entières, il est nécessaire de les connecter à des services de haute qualité. C'est dans ce contexte que l'IoT Hub a été développé, pour donner de la valeur à ces objets et aux services associés.

Scaleway IoT Hub est donc une nouvelle brique de l'écosystème Scaleway Elements : un PaaS qui créé le lien entre les appareils et les services connectés, permettant une communication sécurisée d'objet à object et de l'objet au cloud. En utilisant une architecture Publish/Subscribe, le service garantit une livraison flexible des messages vers de nombreuses destinations. y compris vers des cibles n'utilisant pas les modèles « Publish/Subscribe » tels que les bases de données, le stockage objet ou toute API REST.

L'IoT Hub est considéré comme un broker (courtier en français) de messages managé. Ses principales caractéristiques comprennent :

• Une architecture Publish/Subscribe
• L'utilisation du protocole MQTT, avec ou sans TLS, avec ou sans WebSockets
• L'authentification mutuelle est disponible sur les connexions TLS
• Une haute disponibilité et évolutivité
• Des routes vers des services ne suivant pas le modèle Publish/Subscribe
• Des connexions entrante venant de plusieurs autres réseaux IoT tels que SigFox ou LoRa
• Des données d'utilisation détaillées par Hub et Objet

L'IoT Hub utilise le protocole MQTT. Ce protocole de transfert de données est aujourd’hui devenu un standard dans la communication des objets connectés. Ce protocole de communication a été inventé par deux ingénieurs – Andy Standford-Clark (IBM) et Arlen Nipper (Eurotech) en 1999 pour connecter des oléoducs à des réseaux satellitaires peu fiables. Ils souhaitaient à l’époque concevoir un protocole léger, peu gourmand en bande passante et avec plusieurs niveaux de service (QoS). Ces besoins sont aujourd’hui identiques à ceux des objets connectés, ce qui a valu le succès de ce protocole rendu public en 2011 et devenu un standard en 2013.

Architecture Client/Serveur traditionnelle versus architecture Publish/Subscribe

Dans une architecture client/serveur traditionnelle, comme HTTP par exemple, le client doit savoir quel serveur héberge le service requis, s'y connecter, envoyer une requête et enfin recevoir une réponse. Les serveurs sont définis selon les services qu'ils fournissent. Par exemple, les serveurs Web fournissent des sites Web, les serveurs de messagerie fournissent des e-mails, les serveurs de fichiers fournissent des fichiers informatiques, etc. Ce modèle est bien adapté pour les communications many-to-one (quand plusieurs clients se connectent à un même serveur), mais beaucoup moins dans les cas des relations many-to-many (plusieurs clients interagissent avec plusieurs services).

L'architecture publish/subscribe offre une approche différente : elle décorrèle le "publisher" (le client envoyant un message) des "subscribers" ou abonnés (un ou plusieurs clients recevant le message). Aucune connexion directe n'est établie entre le publisher et le subscriber. Ils n'ont même pas besoin de savoir que l'autre existe. Les messages sont publiés sur un troisième composant, appelé broker ou courtier, qui consiste à transmettre les messages des publishers aux subscribers en se basant sur des topics (ou sujets en français). Un topic décrit les données contenues dans le message (par exemple : météo à Paris, France) afin que les abonnés puissent choisir les messages à recevoir en fonction du service qu'ils fournissent.

Les brokers permettent des opérations plug and play, les publishers et les subscribers peuvent rejoindre et quitter les brokers à tout moment. Ceci est particulièrement pertinent pour les appareils alimentés par batterie et qui ont besoin de se mettre en veille pour économiser leur énergie.

Présentation de MQTT

MQTT est l'une des nombreuses implémentations Publish/Subscribe. Ce protocol est particulièrement léger par rapport aux systèmes de message queue traditionnels :

Dans une message queue (file d'attente de messages en français), les "queues" doivent être créées et nommées avant de pouvoir les utiliser. Il ne sera donc possible de publier ou de consommer des messages que sur des files d'attente pré-créées. La grande différence avec MQTT est que cette restriction n'existe pas. Dès lors, n'importe quel client peut utiliser n'importe quel topic sans configuration préalable.

Les messages d'une "message queue" sont stockés jusqu'à ce qu'un client les récupère. Chaque message reste dans la file d'attente jusqu'à ce qu'il soit traité. Il n'est pas possible qu'un message ne soit pas traité, cela reste néanmoins possible dans MQTT si aucun client ne s'abonne à un topic.

Aussi, l’usage typique d’une message queue est de répartir les messages aux différents souscripteurs. Avec MQTT, bien que cela soit possible, l’utilisation classique est de faire suivre tous les messages à tous les souscripteurs.

Enfin, notre IoT Hub dispose aussi d'une fonctionnalité de filtrage des topics si vous souhaitez appliquer un contrôle d'accès aux topics par périphérique.

Introduction aux topics

Sur IoT Hub, les expéditeurs et les récepteurs identifieront les messages par un nom décrivant leur contenu : le topic (rubrique ou sujet en français).

Le terme topic dans MQTT fait référence à une chaîne de caractère simple que le broker utilise pour faire suivre des messages aux abonnés. Les topics peuvent être constituées d'un ou plusieurs niveaux (topic levels), chacun d'eux séparés par une barre oblique - référencée comme séparateur de niveau (topic level separator). Un topic peut être, par exemple, fr/paris/weather/temperature pour la température à Paris, France.

Les topics sont sensibles à la casse et doivent contenir au moins un caractère. Cela signifie que FR/Paris/Meteo/Temperature fait référence à un sujet différent de fr/paris/meteo/temperature.

D'autres exemples valables pour des topics pourraient être :

• compute/instance/f97d95cd-b349-4bee-9ac8-92e12542d4e9/status
• myhome/first-floor/bedroom/temperature
• Bavaria/Munich/Marienplatz

Compte tenu de l'exemple précédent, un publisher pourrait être une station météorologique qui diffuse la météo actuelle de Paris à IoT Hub, le courtier. Deux abonnés sont connectés au broker: une base de données (pour conserver un historique des données météorologiques) et un affichage en temps réel. IoT Hub s'occupe de remettre une copie du message publié à chaque abonné. Les éditeurs et les abonnés n'ont pas besoin de se connaître.

Travailler avec des Wildcards

Un autre avantage de MQTT est que vous pouvez vous abonner à des catégories d’informations sans connaître à l’avance la liste des topics sur lesquels des messages seront publiés.

Au lieu de s'abonner au topic exact d'un message publié, il est possible d'utiliser des caractères génériques (wildcards) pour s'abonner à plusieurs topics simultanément.
Deux types de wildcards existent single-level (à un niveau) et multi-level (à plusieurs niveaux). Ils ne peuvent être utilisés que pour s'abonner à des topics, il n'est pas possible de publier un message en utilisant des wildcards.

Single-Level Wildcards

Une single-level wildcard (un caractère générique de niveau unique) remplace, comme son nom l'indique, un niveau de topic. Le symbole plus (+) représente une wildcard single-level (de niveau unique) dans une rubrique :

Par exemple, vous pouvez vous abonner au sujet fr/+/weather/temperature pour recevoir les prévisions météo pour toutes les villes de France. Lorsque vous ajoutez une nouvelle station météorologique en France, votre abonné recevra automatiquement les informations qu'il publie.

Multi-Level Wildcards

Une multi-level wildcards (un caractère générique à plusieurs niveaux) s'étend sur de nombreux niveaux de sujets. Il est représenté par un symbole dièse (#) dans le topic. Il est nécessaire de positionner la wildcard multi-level comme dernier caractère du topic :

L'appareil recevra tous les messages d'une rubrique commençant par le motif avant la wildcard, par exemple :

• fr/paris/weather/temperature
• fr/paris/weather/humidity
• fr/paris/weather/airquality/city
• fr/paris/weather/airquality/subway

Topic Prefix

MQTT introduit un préfixe de topic spécial : le signe $.

Les applications ne sont pas autorisées à publier sur des topics commençant par un $. Ceux-ci sont réservés à l'usage du broker. Les topics commençant par $ ignorent alors les wildcards.

Résumé

Maintenant, vous connaissez les principes sous-jacents aux topics, pour plus d'informations sur les sujets MQTT, lisez notre documentation et essayez l'IoT Hub !