Le topic MQTT

Un topic (message) MQTT est composé de plusieurs éléments, donc voici les principaux :

Le topic

C’est une chaîne, au format UTF-8, que le broker utilise pour identifier et filtrer les messages de chaque client connecté. Le topic est constitué d’un ou de plusieurs niveaux. Chaque niveau de sujet est séparé par une barre oblique (séparateur de niveau de sujet).
Exemple :

maison/rezdechaussee/entree/temperature

Ce topic identifierait une température, mesurée à l’entrée, au rez-de-chaussée de la maison.
Le sujet d’un topic décrit son usage, un client n’a pas besoin de créer le sujet souhaité avant de le publier ou de s’y abonner, et le broker acceptera chaque sujet valide sans aucune initialisation préalable.
Voici d’autres exemples de sujets valables :

Suisse/Berne/St-Imier/Ceff/Ensoleillement
5ff4a2ce-e485-40f4-826c-b1a5d81be9b6/status
France/Paris/TourEiffel/latitude

Un sujet doit contenir au moins 1 caractère et que la chaîne de sujets permet des espaces vides. Les sujets sont sensibles à la casse. Par exemple, maMaison/temperature et MaMaison/temperature sont deux sujets différents. En outre, la barre oblique seule est un sujet valable.

Jokers

Lorsqu’un client s’abonne à un sujet, il peut s’abonner au sujet exact d’un message publié ou il peut utiliser des jokers pour s’abonner à plusieurs sujets simultanément. Un joker ne peut être utilisé que pour s’abonner à des sujets, et non pour publier un message. Il existe deux types de jokersdifférents : simple niveau et multi-niveau.

Niveau simple : +

Comme son nom l’indique, un joker à un niveau remplace un niveau de sujet. Le symbole plus ( + ) est utilisé dans ce cas.
Exemple :

maison/rezdechaussee/+/temperature

Les topics suivants seront transmis :

maison/rezdechaussee/entree/temperature
maison/rezdechaussee/salon/temperature
maison/rezdechaussee/entree/lumiere
maison/premieretage/salon/temperature

Multi-niveau : #

Ce joker permet d’obtenir tous les sujets à partir d’un niveau, il doit être placé en dernier. C’est le symbole plus ( * ) est utilisé dans ce cas.
Exemple :

maison/rezdechaussee/#

Les topics suivants seront transmis :

maison/rezdechaussee/entree/temperature
maison/rezdechaussee/salon/temperature
maison/rezdechaussee/entree/lumiere
maison/premieretage/salon/temperature

Il est possible de n’indiquer que le joker # dans un abonnement, tous les messages du broker seront alors transmis.

Sujets commençant par $

Il est possible de nommer les sujets MQTT comme bon vous semble, avec une exception : les sujets qui commencent par le symbole $ ont un objectif différent. Ces sujets ne font pas partie de l’abonnement lorsque vous vous abonnez au joker multi-niveaux comme sujet (#). Les sujets commençant par le symbole $ sont réservés aux statistiques internes du broker MQTT. Les clients ne peuvent pas publier de messages sur ces sujets. Pour l’instant, il n’existe pas de normalisation officielle pour ces sujets. Généralement, $SYS/ est utilisé pour toutes les informations suivantes, mais les mises en œuvre des courtiers varient. Le wiki GitHub de MQTT propose une suggestion pour les sujets $SYS. En voici quelques exemples :

$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime

Bonnes pratiques

  • Ne jamais utiliser un slash avant ( / )
    Un slash avant est autorisé, par exemple, /maMaison/rez-de-chaussee/sejour. Cependant, le slash avant introduit un niveau de sujet inutile avec un caractère zéro au début. Le zéro n’apporte aucun avantage et entraîne souvent une certaine confusion.
  • N’utilisez jamais d’espaces dans un sujet
    L’espace est l’ennemi naturel de tout programmeur. Lorsque les choses ne vont pas comme elles le devraient, les espaces rendent la lecture et le débogage des sujets beaucoup plus difficiles. Comme pour slashes, ce n’est pas parce qu’un élément est autorisé qu’il doit être utilisé. L’UTF-8 comporte de nombreux types d’espaces différents, ces caractères peu courants doivent être évités.
  • Gardez le sujet court et concis
    Chaque sujet est inclus dans chaque message dans lequel il est utilisé. Faites en sorte que vos sujets soient aussi courts et concis que possible. Lorsqu’il s’agit de petits appareils, chaque octet compte et la longueur du sujet a un grand impact sur l’utilisation de la bande passante
  • Utilisez uniquement des caractères ASCII, évitez les caractères non imprimables
    Comme les caractères UTF-8 non ASCII s’affichent souvent de manière incorrecte, il est très difficile de trouver des fautes de frappe ou des problèmes liés au jeu de caractères. À moins que cela ne soit absolument nécessaire, évitez l’utilisation de caractères non-ASCII.
  • Intégrer un identifiant unique ou le Client Id dans le sujet
    Il peut être très utile d’inclure l’identifiant unique du client de l’éditeur dans le sujet. L’identifiant unique dans le sujet vous aide à identifier l’expéditeur du message. L’identifiant intégré peut être utilisé pour faire respecter l’autorisation. Seul un client qui a le même identifiant que celui du sujet est autorisé à publier sur ce sujet. Par exemple, un client ayant l’ID client1 est autorisé à publier vers client1/status, mais pas vers client2/status.
  • Ne vous abonnez pas à #
    Parfois, il est nécessaire de s’abonner à tous les messages qui sont transférés par l’intermédiaire du broker. Par exemple, pour conserver tous les messages dans une base de données. Ne vous abonnez pas à tous les messages sur un brokeren utilisant un client MQTT et en vous abonnant à un joker à plusieurs niveaux. Souvent, le client abonné n’est pas en mesure de traiter la charge de messages qui résulte de cette méthode (surtout si vous avez un débit massif).
  • N’oubliez pas l’extensibilité
    Les sujets sont un concept flexible et il n’est pas nécessaire de les préaffecter de quelque manière que ce soit. Toutefois, l’éditeur et l’abonné doivent tous deux être conscients du sujet. Il est important de réfléchir à la manière dont les sujets peuvent être étendus pour permettre de nouvelles fonctionnalités ou de nouveaux produits. Par exemple, si votre solution de maison intelligente ajoute de nouveaux capteurs, il devrait être possible de les ajouter à votre arborescence de thèmes sans modifier toute la hiérarchie des thèmes.
  • Utilisez des thèmes spécifiques, et non des thèmes généraux
    Lorsque vous nommez des sujets, ne les utilisez pas de la même manière que dans une file d’attente. Différenciez vos sujets autant que possible. Par exemple, si vous avez trois capteurs dans votre salon, créez des thèmes pour mamaison/salon/temperature, mamaison/salon/luminosite et mamaison/salon/humidite. N’envoyez pas toutes les valeurs sur mamaison/sejour. L’utilisation d’un seul sujet pour tous les messages est un anti-modèle. Un nommage spécifique vous permet également d’utiliser d’autres caractéristiques du MQTT telles que les messages conservés.

Le payload

Le payload est le contenu du message, ce qui est utile …
Plusieurs formats sont possibles, l’important étant la façon dont les informations sont codées. On retrouve souvent le codage en JSON, mais une valeur binaire, décimale, hexadécimale, une chaîne, un XML sont aussi possibles.
Un autre format proposé est Cayenne, soutenu par myDevices. On trouve notamment des librairies qui formatent Cayenne pour Arduino, même si Cayenne est plus qu’un simple format.

La QOS

Le niveau de qualité de service (QoS) est un accord entre l’expéditeur et le destinataire d’un message qui définit la garantie de livraison du message.
Il existe 3 niveaux de QoS dans MQTT :

  • QOS 0 – Once : Au maximum une fois
    Cette méthode est la plus rapide et ne nécessite qu’un seul message. C’est également le mode de transfert le moins fiable.
    Le message n’est pas stocké chez l’expéditeur et ne fait pas l’objet d’un accusé de réception.
    Le message n’est délivré qu’une seule fois, voire pas du tout.
    Une fois que le message a été envoyé par le client, il est supprimé de la file d’attente des messages sortants.
    Par conséquent, avec ce niveau de QOS, il n’y a pas de possibilité de messages en double.
  • QOS 1 – At Least Once : Au moins une fois (1)
    Ce niveau garantit que le message sera délivré au moins une fois, mais peut être délivré plusieurs fois. La publication avec un QOS 1 nécessite 2 messages.
    L’expéditeur envoie un message et attend un accusé de réception (PUBACK).
    S’il reçoit un accusé de réception, il en informe l’application client et supprime le message de la file d’attente des messages sortants.
    S’il ne reçoit pas d’accusé de réception, il renvoie le message avec le drapeau DUP (Duplicate Flag) activé.
    Le message continuera à être envoyé à intervalles réguliers, jusqu’à ce que l’expéditeur reçoive un accusé de réception.
  • QOS 2 – Only Once : Exactement une fois.
    Ce niveau garantit que le message ne sera délivré qu’une seule fois. C’est la méthode la plus lente car elle nécessite 4 messages.
    1. L’expéditeur envoie un message et attend un accusé de réception (PUBREC)
    2. Le destinataire envoie un message PUBREC
    3. Si l’expéditeur ne reçoit pas d’accusé de réception ( PUBREC ), il renverra le message avec le drapeau DUP activé.
    4. Lorsque l’expéditeur reçoit un message d’accusé de réception PUBREC, il envoie alors un message de libération de message (PUBREL). Le message peut être supprimé de la file d’attente.
    5. Si le destinataire ne reçoit pas le PUBREL, il envoie à nouveau le message PUBREC
    6. Lorsque le destinataire reçoit le message PUBREL, il peut maintenant le transmettre à n’importe quel abonné.
    7. Le destinataire envoie alors une publication complète (PUBCOMP).
    8. Si l’expéditeur ne reçoit pas le message PUBCOMP, il renverra le message PUBREL.
    9. Lorsque l’expéditeur reçoit le message PUBCOMP, le processus est terminé et il peut supprimer le message de la file d’attente des messages sortants, ainsi que l’état du message.

Le QoS peut être abordé dans les deux sens de transmission des messages :

  • La livraison du message du client au broker (publication)
  • La livraison du message du broker à l’abonné (souscription)

Il existe des différences subtiles entre les deux. Le client qui publie le message au broker définit le niveau de qualité de service du message lorsqu’il envoie le message au broker. Le broker transmet ce message aux abonnés en utilisant le niveau de qualité de service que chaque abonné a précisé lors du processus d’abonnement. Si l’abonné définit un niveau de qualité de service inférieur à celui du client éditeur, le broker transmet le message avec la qualité de service la plus faible.

Le retain flag

Normalement, si un broker reçoit d’un client un message sur un sujet et que personne n’est abonné à ce sujet, le message est simplement rejeté par le broker.
Toutefois, le client peut demander au broker de conserver le dernier message sur ce sujet en activant le drapeau de message conservé (retained flag).
Cela peut être très utile, comme par exemple, si vous avez un capteur publiant son statut avec de longs intervalles de temps

Le client_id

L’identifiant du client (ClientId) identifie chaque client MQTT qui se connecte à un broker. Le broker utilise le ClientID pour identifier le client et l’état actuel de ce dernier, cet identifiant doit donc être unique par client et par broker.

Sources :

Laisser un commentaire