Connecteur MQTT

Principes généraux du MQTT

Le MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie temps réel permettant d’échanger des données par topic avec une approche publier / s’abonner. Un topic est un point (ou un ensemble de points) représentant une donnée (ou un ensemble de données).

Le protocole MQTT est composé de deux types d’entités principaux :

• Le broker MQTT : il collecte et met à disposition les données demandées. Il joue le rôle de serveur.
• Le client MQTT : il peut publier des données vers un broker et s’abonner pour recevoir des données d’un broker. OIBus est un client MQTT.

La connexion au Broker MQTT

Le client MQTT se connecte au broker avec différentes options :

• URL : de la forme mqtt://address:1883. Le port 1883 est le port MQTT par défaut mais peut être différent selon la configuration du broker.
• Authentication : il est possible de spécifier une authentification si le broker l’exige. Pour cela il faut remplir les champs Username et Password.
• Qualité de service (QoS) : qui propose trois options spécifiques au protocole MQTT.


• QoS0 : at most once. Cela signifie que le message est envoyé une fois mais que MQTT ne garantit pas la bonne réception du message. La bonne réception dépendra de la qualité du réseau sous-jacent à MQTT.
• QoS1 : at least once. Cela signifie que le message est envoyé plusieurs fois sous forme de duplicatas jusqu’à ce que le client valide la bonne réception d’au moins un des duplicatas. Dans certains cas, il se peut alors que le client réceptionne plusieurs fois le même message.
• QoS2 : exactly once. Cela signifie que le message est envoyé une seule fois, et une nouvelle tentative d’envoi a lieu après un certain temps jusqu’à ce que le client valide la bonne réception. Il n’y a pas de risque de réceptions multiples dans ce cas.



La QoS1 et la QoS2 permettent des connexions persistantes. Une connexion persistante permet au broker de garder un certain nombre de messages en mémoire (configuré sur le broker) jusqu’à ce que le client se reconnecte en cas de perte de connexion. Les connexions persistantes ne sont pas encore gérées par OIBus.

Le topic

Le broker organise les données par arborescence. En voici un exemple :

France
| -> Paris
      | -> temperatureTank1
      | -> temperatureTank2
| -> Chambery
      | -> temperatureTank1
      | -> temperatureTank2





Il est alors possible de s’abonner à un ensemble de données en renseignant un nœud parent, par exemple France/# ou France/Chambery/#. Il est aussi possible de directement renseigner la donnée finale, par exemple France/Paris/temperatureTank1.

Notions de Points et d’Abonnements

Lors d’un abonnement d’un client MQTT à une donnée sur le broker, le broker envoie les nouvelles valeurs dès qu’elles sont disponibles selon les options de connexion (notamment la QoS). Le scan mode est donc toujours listen. Il s’agit d’un abonnement du client MQTT qui attend que le broker lui envoie de nouvelles valeurs.

Le point id est le nom de la donnée telle que référencée dans l’application cible.

Lors de l’abonnement à un ensemble de points comme avec xxxx/#: le point id est configuré sour la forme yyyy# ce qui donnera des point id par concaténation de yyyy avec le détail du topic.

Par exemple si on s’abonne à un ensemble de points comme France/# et que le point id est configuré comme étant France:#, alors la liste des point id obtenus sera :

France:Paris/temperatureTank1
France:Paris/temperatureTank2
France:Chambery/temperatureTank1
France:Chambery/temperatureTank2




Charge utile MQTT

La charge utile contenue dans les messages envoyés par le broker peut différer d’un broker à l’autre. Le client MQTT OIBus peut s’adapter à cette charge utile grâce à la configuration MQTT payload :

Par exemple, si la charge utile est de la forme :

{
"pointId": "point1",
"value": "666.666",
"timestamp": "2020-02-02 02:02:02",
"quality": "true"
}




Alors la configuration suivante doit être appliquée :

Data array path : Ø
Value path : value
Node id path : Ø
Timestamp path : timestamp
Quality path : quality




Un autre exemple, avec une charge utile de la forme :

"metrics": [
{
"customName": "point1",
"customValue": "666.666",
"customTimestamp": "2020-02-02 02:02:02",
"customQuality": "true"
}
]




Alors la configuration suivante doit être appliquée :

Data array path : metrics
Value path : customValue
Node id path : customName
Timestamp path : customTimestamp
Quality path : customQuality





Pour aller plus loin

Vous pouvez consulter le site web MQTT de l’organisme de standardisation Oasis Open et plus particulièrement le document de Spécification du MQTT.