Publicité
10.
PROTOCOLE MQTT
Le LogBox LTE prend en charge le protocole Message Queue Telemetry Transport (MQTT), versions 3.1 et 3.1.1, qui vous permet de publier des
données sur le cloud. Il prend en charge les brokers MQTT suivants : AWS, NOVUS Cloud et les brokers MQTT génériques.
Ce chapitre décrit la structure des données publiées dans le cloud et présente la structure d'envoi de commandes à l'appareil, ainsi que quelques
exemples de messages qui doivent être publiés et reçus, messages qui suivront le format JSON.
10.1 SUJETS DE PUBLICATION ET D'ABONNEMENT
Comme décrit ci-dessous, le LogBox LTE utilise 4 sujets :
Sujet de publication de données périodique et d'événements : utilisé pour publier les données générées sur l'appareil, c'est-à-dire les
•
enregistrements. Il existe 3 types : periodics, digin_events e acc_event.
Sujet de publication d'alarmes : utilisé pour signaler l'apparition d'alarmes pour lesquelles la configuration de publication MQTT est
•
sélectionnée (voir la section
Sujet pour recevoir des commandes : utilisé pour recevoir des commandes. L'appareil s'abonne à ce sujet pour recevoir des commandes et
•
signale l'exécution d'une commande en publiant dans le sujet de confirmation de commande.
Sujet de confirmation de commande : dans ce sujet, l'appareil publie le résultat des commandes exécutées.
•
Des exemples de sujets pour un Broker générique :
10.2 MODÈLE D'ENVOI DE DONNÉES ET D'ÉVÉNEMENTS
La publication des événements et des données générés par l'appareil suit le modèle standard MQTT et utilise un thème défini lors de la configuration.
Le type de données est indiqué dans le JSON du message à travers 3 informations : periodics, digin_events e acc_event.
Pour toutes les données, les horodatages utilisés sont au format Unix timestamp UTC (GMT 0).
10.2.1 DONNÉES PÉRIODIQUES ET ÉVÉNEMENTS
Les données de canal sont publiées périodiquement, en fonction de la configuration de l'appareil. Si des événements surviennent pendant l'intervalle
de publications, ils peuvent être inclus dans la même publication de données périodiques, comme le montre l'exemple ci-dessous.
Les données sont au format JSON et comportent les ensembles clé / valeur suivants :
{
"device":
"LogBox
"periodics": {
"quantity":3,
"timestamps":[1585819219,
"cha1":[-79.5,
"cha2":[-80.3,
"chi1":[25.5,
},
"digin_events": {
"quantity":2,
"timestamps":[1585819250, 1585819334],
"types":["border_up", "border_down"],
"miliseconds":[257, 102]
}
}
Remarques :
Afin de réduire le nombre de publications, les données seront compilées dans une clé unique et la quantité de données sera définie par la clé
•
quantity. En pratique, la première position de timestamp correspond à la première position d'un chdX, ainsi que la deuxième position
de timestamp pour chX, et ainsi de suite. La même logique s'applique aux événements de l'entrée numérique, qui peuvent être présents
dans la même publication.
La valeur de timestamp est l'horodatage au format Unix UTC au moment où la lecture a été effectuée par l'appareil.
•
chX correspond aux informations des canaux au moment de l'horodatage. Si le canal n'est pas activé, il n'apparaîtra pas dans le JSON. Si le
•
canal numérique est en mode Enregistrement des événements, la clé digin_events n'apparaîtra pas dans le JSON si aucun événement
ne se produit pendant l'intervalle. Si le canal est en mode Comptage d'impulsions, la valeur correspondra au débit ou au comptage à ce
moment et sera présente dans la clé periodics.
NOVUS AUTOMATION
MQTT
du chapitre
LOGICIEL DE
SUJET
Sujet pour publier des données périodiques et
des événements
Sujet pour publier des alarmes
Sujet pour recevoir des commandes
Sujet de confirmation de commande
Tableau 6 – Sujets d'un Broker générique
LTE",
1585819279,
-79.5,
-79.7],
-80.1,
-80.2],
25.6,
25.9]
CONFIGURATION).
UTILISATION
NOVUS/device1/records
NOVUS/device1/alarms
NOVUS/device1/command
NOVUS/device1/ack/command
1585819339],
26/80
Publicité
