
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 port1883
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
etPassword
. - 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.