Fond générique MQTT

Avec MQTT, l'expéditeur et le destinataire ne sont pas conscients l'un de l'autre - le courtier gère la messagerie. Cela permet de séparer les messages dans l'espace, le temps et l'intensité. L'expéditeur peut envoyer à la vitesse qu'il souhaite, et au moment qu'il souhaite. Le récepteur peut recevoir les messages à la vitesse et au moment qu'il souhaite. L'émetteur et le récepteur n'ont pas besoin de se connaître, ni d'avoir une route directe entre eux (comme ce serait le cas avec une ligne téléphonique). MQTT permet de concevoir facilement des configurations de multidiffusion, dans lesquelles un expéditeur peut envoyer des messages à plusieurs récepteurs abonnés.

• Les clients ne savent pas qui a publié le message à l'origine - à moins que cela ne soit clair à partir du sujet (et éventuellement imposé au courtier par des ACL), ou à partir du contenu du message (éventuellement signé avec HMAC).
• MQTT est conçu pour les communications à faible puissance et à faible latence (HMAC, etc.).
• Vous ne pouvez pas obtenir une liste de tous les sujets d'un courtier. Le courtier rejette les messages (et les sujets) auxquels personne n'est abonné (ce qui n'est vrai que si l'indicateur retain n'est pas activé).
• Vous ne savez pas qui s'est abonné à un sujet (utilisez les ACL pour limiter les abonnements des clients non autorisés).

dernières volontés et testament / garder en vie

Les clients peuvent se connecter, publier un message et se déconnecter, ou maintenir une connexion persistante avec le serveur. Dans le cas d'une connexion persistante, les keep-alives seront envoyés. Si le client n'envoie pas de keep-alives dans le délai convenu lors de l'établissement de la connexion, le serveur (broker) peut envoyer un message dit de dernière volonté, que le client a soumis lors de l'établissement de la connexion. Ce message peut être n'importe quoi et peut être publié sur un seul sujet par connexion. Le courtier l'enverra à tous les clients abonnés à ce sujet.

Si le client se déconnecte gracieusement, le testament ne sera pas publié.

Le maintien en vie est particulièrement utile pour les clients mobiles, où la connexion peut être interrompue (par exemple en raison d'un mauvais réseau, de tunnels, etc.).

Voir aussi :

http://www.steves-internet-guide.com/checking-active-mqtt-client-connections/

http://www.steves-internet-guide.com/mqtt-last-will-example/

https://owntracks.org/booklet/tech/mqtt/

Identification du client / Reprise du client

Chaque client qui se connecte à un courtier MQTT doit avoir un identifiant client unique. Les clients qui se connectent avec le même identifiant détruisent la connexion précédente et prennent en charge la nouvelle. Si vous avez deux clients avec le même identifiant, cela peut conduire à un ping-pong de connexions déconnectées.

Messages retenus

Le site dernier Le message retenu dans un sujet est enregistré et transmis à tous les nouveaux abonnés de ce sujet. Ceci peut être utilisé pour communiquer l'état / la configuration / etc. du dispositif.

Vous définissez l'état retenu comme un drapeau par message.

Les messages conservés peuvent être utilisés pour de nombreuses choses intéressantes, par exemple pour faciliter la découverte automatique (voir la suggestion 4 ci-dessous).

Qualité de service / QoS

Il existe trois niveaux de qualité de service, qui déterminent le niveau de surcharge pendant le traitement d'un message. Plus le niveau est élevé, plus la surcharge est importante.

• 0 : aucune garantie
• 1 : le message sera envoyé au moins une fois (doublons possibles)
• 2 : le message sera envoyé exactement une fois (pas de doublons possibles)

La QoS peut être définie par message envoyé au courtier, et pendant l'abonnement. La plus faible des deux valeurs sera utilisée pour la livraison effective du message.

Jetez un coup d'œil à ce document pour plus de détails :

https://www.eclipse.org/paho/files/mqttdoc/MQTTClient/html/qos.html

Sujets

Faits concernant les sujets

Les noms des sujets sont sensibles à la casse et aux chaînes de caractères UTF-8. Il est conseillé de se limiter aux caractères ASCII imprimables pour faciliter le débogage.

Les noms des sujets doivent être composés d'au moins un caractère pour être valides.

/

est déjà un nom de sujet

Le site $SYS Le sujet concerne l'utilisation des courtiers et les statistiques.

Vous avez le choix entre placer les informations dans la structure du sujet ou les placer dans le message. Une structure JSON pour le message vous aidera à l'étendre avec d'autres données.

Considérez qu'à chaque appel au courtier, chaque publication du sujet sera envoyée dans la charge utile du paquet MQTT - essayez donc d'éviter toute longueur inutile.

Tenir compte de l'utilisation des jokers

• # correspond à tout pour une profondeur de niveau arbitraire à partir du niveau actuel (joker à plusieurs niveaux, ne peut être inséré qu'à la fin)
• + correspond à tout ce qui se trouve au niveau actuel (joker à un seul niveau)

Par exemple, si vous disposez de plusieurs capteurs de température, vous pouvez facilement vous abonner aux messages de chacun d'entre eux si vous concevez correctement votre arbre thématique.

Les jokers ne servent qu'à s'abonner, ils ne sont pas autorisés à être publiés.

Vous pouvez vous abonner à tous les sujets en utilisant #

sauf la rubrique $SYS. Utilisez $SYS/# pour vous abonner à toutes les rubriques de $SYS.

Il est possible que l'utilisation de la partie "fonction" avant l'identifiant de l'appareil vous permette de vous abonner plus facilement à certaines chaînes.

Par exemple, si vous définissez vos chemins comme tele/room1/sensorname1 tele/room2/sensorname2 etc. et stat/room1/sensorname1 stat/room1/sensorname2 les abonnements sont possibles sur :

téléphone/#

stat/#

Si vous le faites dans l'autre sens, avec capteur1/stat et capteur2/statetc., vous pouvez utiliser

+/stat

pour s'abonner aux statistiques, mais ne correspondra pas à une profondeur arbitraire comme dans l'exemple précédent. En d'autres termes, le chemin vers votre capteur doit être constitué précisément d'un seul composant.

De cette façon, si vous préfixez l'action, vos parcours seront plus cohérents.

Voir par exemple https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch/

Ne pas

- N'utilisez pas de barre oblique (par exemple, /mytopics ) pour commencer votre arborescence de thèmes - cela ajoute des frais généraux et n'a aucune valeur.

- Ne pas utiliser $SYS comme sujet de départ, ceci est réservé au courtier

- N'utilisez pas d'espaces dans le sujet

- N'utilisez pas de caractères non imprimables dans la rubrique

- utiliser un sujet MQTT pour des messages ayant une signification différente - créer des sujets différents pour eux

Suggestions / Faire

- intégrer l'identifiant du client dans l'arbre des thèmes

- créer des sujets spécifiques pour l'adressage individuel (par exemple, des capteurs), au lieu d'envoyer toutes les valeurs sur un seul sujet. Cela évitera d'envoyer des messages à des destinataires qui n'en ont pas besoin.

- essayez de garder les noms des sujets courts (car ils seront envoyés sur chaque publication et message)

- examiner quelles données devront être envoyées et à quelle fréquence

o Par exemple, envisagez de séparer les métadonnées pour en faire un sujet à part entière et de les publier avec un drapeau "retain".

- séparer les sujets de commande/cmd et d'état pour un dispositif - de cette façon, la communication bidirectionnelle sera possible, et le dispositif ne devra pas filtrer ses propres messages.

- utiliser un message de testament pour indiquer une déconnexion inattendue du client

Envisager la multi-location et le pontage

Avez-vous besoin de prendre en charge plusieurs clients / organisations / applications indépendantes ? Il existe la possibilité d'utiliser, par exemple avec VerneMQ, différents points de montage. Une autre alternative est d'inclure la multi-tenue dans votre arbre de thèmes (en utilisant un préfixe approprié au début de l'arbre de thèmes).

Je préfère la première voie, car elle offre une couche supplémentaire de séparation de l'ACL - et moins d'occasions de "foirer".

En outre, vous pourriez vouloir relier plusieurs courtiers MQTT entre eux, en partageant une partie de leurs arborescences de sujets (telles que définies par leurs ACL).

Consultez ce site https://owntracks.org/booklet/guide/bridge/ pour en savoir plus sur les passerelles.

Envisagez le cryptage

MQTT peut être exécuté sur des réseaux cryptés (par exemple, sur des websockets / TLS cryptés) ou sur des canaux non cryptés. En outre, vous pouvez envisager de chiffrer et/ou de signer la charge utile de vos données.

Tenir compte de la possibilité de découverte

Envisagez d'intégrer des rubriques qui faciliteront la découverte des services et des capacités de vos appareils, par exemple en utilisant des messages conservés.

Tenir compte du retour d'information sur les commandes

Lorsque vous publiez une commande, vous ne disposez pas d'un canal de retour immédiat. Il pourrait donc être utile d'établir une hiérarchie pour un retour d'information spécifique sur des commandes spécifiques - si le dispositif a reçu et a pu exécuter la commande, afin de pouvoir fournir un retour d'information à l'utilisateur.

Un modèle que je pensais appliquer ici consistait à donner des identifiants de commande uniques dans le cadre de la charge utile du message, qui sont référencés dans le canal de retour avec un code d'état.

Considérer les scénarios de multidiffusion

Voulez-vous que plusieurs appareils réagissent à un seul message que vous publiez ? N'oubliez pas que vous ne pouvez pas publier sur des sujets génériques, mais seulement vous y abonner. Dans ce cas, il faut créer des sujets supplémentaires qui permettent aux clients de réagir à des scénarios de multidiffusion. Tous les clients / tous les clients d'un groupe particulier s'abonneront au sujet de multidiffusion et réagiront aux messages.

Si vous combinez cela avec ma suggestion de retour d'information / référence à l'identifiant de commande ci-dessus, une nouvelle exigence d'identifiant de client comme charge utile est introduite sur le canal de retour d'information (générique). Une autre possibilité est de demander aux dispositifs de répondre sur leurs canaux de retour individuels - où l'identifiant du dispositif fait déjà partie du chemin. (C'est-à-dire qu'ils reçoivent une commande sur le chemin de multidiffusion, mais répondent dans leur propre hiérarchie exclusive de sujets de messages).

Tenir compte du trafic et de la confidentialité, des types de capteurs

Si vous exploitez un système commercial, par exemple si vous collectez des données de capteurs pour des utilisateurs, ces derniers voudront peut-être pouvoir contrôler avec précision quelles valeurs de capteurs sont publiées.

En outre, la simple publication automatique de tous les relevés de capteurs augmentera le trafic et la charge sur votre ou vos serveurs.

Par conséquent, le simple fait de pousser toutes les valeurs de capteur disponibles vers votre courtier MQTT n'est peut-être pas le meilleur choix. Une possibilité est de créer un sujet conservé, avec une configuration à laquelle le client peut s'abonner. Lorsque le client se connecte, il reçoit automatiquement la configuration sur le sujet retenu et peut ajuster les valeurs qu'il publie en fonction de la configuration. De plus, il peut réagir aux changements de configuration en réagissant à tous les messages supplémentaires qui arrivent sur ce sujet de configuration.

En outre, il est important de considérer qu'il existe différents types de capteurs. Par exemple, pour un capteur de porte, vous serez intéressé par un changement d'état (fermé ou ouvert), alors que pour un capteur de température, vous voudrez peut-être recevoir des relevés continus. Il est important pour votre conception de prendre en compte le type de valeurs que les abonnés recevront lorsque le client responsable des relevés du capteur se déconnectera. N'oubliez pas que vous ne pouvez établir un testament que sur un seul sujet (pour les dispositifs multicapteurs). Dans le cas d'une déconnexion, les messages conservés pourraient donner une fausse impression (par exemple, que la porte est ouverte alors qu'elle est fermée en réalité, mais qu'elle n'a pas été mise à jour, etc.)

D'autre part, si, par exemple, votre interface web qui contrôle le client n'est connectée qu'après que le client capteur de porte ait été connecté pendant un certain temps, et que vous utilisez des messages non conservés, le message de la dernière mise à jour de l'état de la porte sera manqué ;

Il y a deux possibilités ici :

• demander activement une mise à jour de l'état de la porte (en utilisant, par exemple, votre propre sujet d'obtention)
• utiliser des messages conservés, et utiliser la logique côté client de l'interface web pour écarter la dernière valeur au cas où le client lui-même ne serait pas connecté / le marquer comme périmé

Dans tous les cas, l'utilisateur doit savoir si le relevé d'un capteur est fiable ou s'il peut être incorrect en raison d'un capteur-client déconnecté.

Voir aussi http://www.steves-internet-guide.com/mqtt-sensors-traffic-observations/

• Steve note que le fait de combiner les données de plusieurs capteurs dans une charge utile codée en JSON ne diminue pas le trafic, mais peut même l'augmenter légèrement (par rapport à une charge utile non codée !).

chemin sémantique vs. chemin physique du sujet

les choses significatives pour un humain créent la structure du sujet : ("approche sémantique")

maison/salle de bain/humidité

les chemins des dispositifs (à quels dispositifs les capteurs sont-ils reliés, comment sont-ils adressés ?) créent la structure du sujet : ("approche physique")

pi/00000234898324734/i2c/10/pressure

(les chiffres symbolisant respectivement la série BCM et l'adresse I2C).

republiée

Dans cette idée, vous combinez les deux approches et créez un service supplémentaire qui fait le lien entre les deux mondes.

Voir : https://tinkerman.cat/post/mqtt-topic-naming-convention

Aperçu des suggestions de conception en ligne

Suggestion 1 : Vallée de la framboise

de : https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/

catégorie de dispositif/identification de dispositif/contexte de chargement/différenciateur de chargement

• catégorie de périphérique : par exemple, "pi", "arduino", etc.
• device-id : par exemple, BCM serial
• payload-context : par exemple, température
• différentiateur de charge utile : par exemple avant / arrière (ajoutant un niveau de mesure pour un contexte donné)

Notez la symétrie entre device-category/device-id et payload-context/payload-differentiator (générique-> spécifique ; générique -> spécifique).

Suggestion 2 : Steve

(Par Steve) : http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/

Vous pouvez inclure les éléments suivants dans votre arbre thématique :

• dispositifs de regroupement de sujets de haut niveau
• nom du capteur attribué
• fonction (par exemple, set / status / get / cmd )

L'approche de Steve :

• utiliser le nom du sujet pour un dispositif individuel (par exemple un capteur)
• utiliser les données payload / JSON pour les attributs de ce capteur
• utiliser un sujet distinct pour les données et les commandes

Suggestion 3 : MQTT-Smarthome

Proposition MQTT Smarthome

https://github.com/mqtt-smarthome/mqtt-smarthome

un chemin ressemble à ceci dans cette proposition :

toplevelname/fonction/item

knxgateway1/status/Kitchen/Lights/Front Left

• premier niveau (knxgateway1) = toplevelname, la passerelle concrète à laquelle on s'adresse
• pour plusieurs passerelles similaires, ce nom doit pouvoir être défini afin d'éviter les collisions dans l'espace de noms.
• deuxième niveau (statut) = fonction
• troisième niveau, et autres niveaux -> hiérarchie d'adresses individuelles de la passerelle particulière (item)

Ce qui est intéressant, ce sont les fonctions et leur position. avant les chemins plus profonds (pensez aux jokers pour l'abonnement - de cette façon, vous pouvez vous abonner à tous les rapports d'état des appareils facilement !)

Fonctions disponibles / définies dans cette proposition :

• status - pour obtenir des rapports d'état
• set - pour demander des changements d'état
• get - (facultatif) pour demander activement une mise à jour de l'état (pour les passerelles qui le supportent)
• le résultat de la lecture sera publié sur le site Web de la Commission européenne. statut hiérarchie.

Les hiérarchies ultérieures des différents verbes doivent correspondre les unes aux autres, de sorte que vous vous adressiez au même dispositif/nœud/paramètre.

Il existe une rubrique spéciale "connectée" par passerelle, qui permet au client de définir un message de testament.

toplevelname/connected

des valeurs simples sont définies pour ce sujet :

• 0 = déconnecté du courtier (défini comme dernière volonté)
• 1 = connecté à MQTT, déconnecté du matériel
• 2 = connecté à MQTT et au matériel (entièrement opérationnel)

Notez que la valeur 0 ne fait pas de distinction entre les déconnexions volontaires et les connexions perdues (où les keep-alives ont expiré).

Il existe également des suggestions pour la charge utile :

L'encodage JSON de la charge utile est facultatif.

Dans le cas du codage JSON, la valeur sera toujours dans la clé "val". En outre,

ts : timestamp (horodatage, millisecondes depuis Epoch)

lc : dernier changement de valeur (timestamp, millisecondes depuis Epoch)

Suggestion 4 : Tinkerman

https://tinkerman.cat/post/mqtt-topic-naming-convention

déterminez si vous souhaitez une approche "sémantique" (par exemple, des éléments significatifs pour les humains) ou une approche "physique" (par exemple, les chemins d'accès réels des dispositifs dans lesquels votre système est connecté).

L'approche physique est plus conviviale pour les machines.

(Veuillez noter que la compréhension de Tinkerman et la mienne des points de montage et de leur utilisation diffèrent - pour moi, les points de montage sont des arbres à thème complètement séparés, par exemple pour la multi-location).

Les métadonnées peuvent être encodées sous forme de chemins postfixes.

par exemple

/home/bedroom/temperature -> 21

/home/bedroom/temperature/units -> °C

/home/bedroom/temperature/timestamp -> 2012-12-10T12:47:00+01:00

Remarque : comme il est peu probable que les unités et certaines autres métadonnées changent, elles peuvent être envoyées en tant que sujets conservés.

Une partie intéressante de cette suggestion est également l'agrégation (côté dispositif) :

/home/bedroom/temperature/last -> dernière valeur de température

/home/bedroom/temperature/last/timestamp

/home/bedroom/temperature/last24h/max -> valeur maximale des dernières 24h

/home/bedroom/temperature/last24h/max/timestamp -> horodatage où la température était aussi élevée.

/home/bedroom/temperature/last24h/min

/home/bedroom/temperature/ever/max -> la plus haute température absolue jamais mesurée

Encore une fois, ces valeurs pourraient être définies comme des sujets conservés (spécifiquement "jamais") pour économiser le trafic réseau - le système récepteur pourrait rejeter les valeurs conservées plus anciennes (si le capteur est déconnecté, comme cela devrait être évident par un autre sujet - peut-être défini par le dernier testament et la volonté), ou le système pourrait les montrer comme des valeurs "périmées".

Il s'agit d'une conception intéressante (pour l'agrégation), qui pourrait servir d'inspiration pour permettre ce type de flexibilité.

Suggestion 5 : Convention Homie IoT

https://homieiot.github.io/

Home IoT est axé sur la découvrabilité des nœuds dans le cadre de la domotique IoT. Homie n'utilise pas de messages codés en JSON, il utilise une représentation directe de la charge utile pour chaque nœud. Voir cet exemple :

Homie définit un sous-ensemble strict de caractères que vous êtes autorisé à utiliser pour nommer vos nœuds, car les caractères spéciaux (par exemple, $ et le trait de soulignement _) sont utilisés à des fins particulières.

Il définit des types de données, qui sont publiés en tant que métadonnées (conservées) ("attributs") à $datype de la propriété individuelle (voir ci-dessous pour la définition de la propriété) :

• Chaîne de caractères
• Entier
• Flotteur
• Booléen
• Enum
• Couleur

(notez l'utilisation du $ pour marquer les sujets spéciaux).

La dernière volonté est utilisée pour marquer l'appareil comme perdu :

homie/deviceID/$state -> perdu

Homie définit 6 possibilités États pour l'appareil :

• init -> le dispositif s'est connecté à MQTT mais n'a pas encore publié tous les messages Homie nécessaires.
• prêt -> le dispositif est connecté, et a terminé la configuration - tous les messages nécessaires ont été envoyés.
• déconnecté -> le dispositif s'est déconnecté de manière propre.
• dormir -> auto-descriptif
• perdu -> le dispositif s'est déconnecté de manière inattendue (fixé par les dernières volontés).
• alerte -> le dispositif est connecté, mais quelque chose ne va pas, nécessite une intervention humaine

Homie recommande d'utiliser QoS 1 (car la nature de Homie le rend sûr pour les messages en double).

Une disposition pour extensions est réalisé en utilisant une syntaxe de nom de domaine inversée, par exemple org.mycompany.homie-extension

nœuds et dispositifs

Dans Homie-parlance, un dispositif est l'unité matérielle de base. Par exemple, un Raspberry Pi, une machine à café, une voiture.

A nœud est une unité logique et indépendante du dispositif. Par exemple, une voiture peut avoir un nœud de roues, un nœud de moteur et un nœud de feux.

propriétés représentent les caractéristiques de base du nœud/appareil. Une voiture, par exemple, pourrait avoir une propriété "vitesse" et une propriété "température" pour le nœud moteur. Les propriétés peuvent être conservées et/ou paramétrables.

• retenu + non réglable : par exemple, capteur de température
• retenu + réglable : le nœud peut publier une propriété et recevoir des commandes pour cette propriété (par exemple, la puissance de la lampe).
• non retenu + non réglable : par exemple, une sonnette de porte (événements momentanés)
• non conservé + réglable : le nœud peut recevoir des commandes pour la propriété, par exemple faire du café

attributs :

les attributs sont importants pour l'autodiscovery de Homie, ils sont spécifiés, et commencés par un $ pour indiquer leur signification particulière / éviter les collisions. Ils sont utilisés pour stocker et mettre à jour les métadonnées.

Par exemple, le dispositif publie un message retenu sur

homie/device ID/$nodes

avec une liste de nœuds séparés par des virgules. Pour indiquer qu'un nœud est un tableau (peut être utilisé pour regrouper par exemple les feux avant et arrière d'une voiture), le nom est spécifié avec des parenthèses rectangulaires à la fin, par ex.

lumières[]

Un exemple pour le sous-arbre device id :

Homie spécifie différentes statistiques pour le dispositif, la plupart d'entre elles étant optionnelles (sauf le temps de fonctionnement). Par exemple :

Avec les nœuds, l'autodécouverte est également possible pour les propriétés, en les spécifiant dans l'attribut $properties :

Ainsi, en tant qu'abonné, vous ne devez pas deviner / vous abonner à tous les événements - vous pouvez vous abonner de manière sélective à ceux qui vous intéressent.

Dans Homie, les métadonnées (attributs) sont publiées comme un suffixe au chemin. Par exemple, pour une propriété particulière :

Contrôle dans Homie

Homie est basé sur l'état. Cela signifie que vous n'allumez pas la lumière, mais que vous réglez l'état d'alimentation d'un appareil sur marche.

puis le dispositif met à jour son état d'alimentation pour communiquer que la commande a été exécutée :

Diffusion

L'alerte est un choix arbitraire - la diffusion peut porter sur n'importe quel autre sujet, que les dispositifs peuvent filtrer. Les messages sont diffusés à tous les dispositifs - les dispositifs peuvent réagir s'ils le souhaitent.

C'est la spécification la plus complète que j'ai pu trouver dans mes recherches en ligne. Je trouve personnellement qu'il est très bien conçu.

Lire la suite :

https://homieiot.github.io/specification/

Suggestion 6 : Pistes à suivre

https://owntracks.org/booklet/tech/json/

http://owntracks.org/booklet/guide/topics/

Owntracks est une application Open Source, qui vous permet de suivre votre propre localisation physique, de la partager avec vos amis, etc. La localisation est publiée via HTTP ou MQTT, idéalement à votre propre courtier.

" Il peut également détecter lorsque vous entrez ou quittez une région particulière pour laquelle vous avez défini un point de passage. Les gens l'utilisent, par exemple, pour contrôler un aspect de leur système d'automatisation de la maison. (Tout le monde est parti de la maison ? On peut éteindre les lumières.)"

Si vous voulez en savoir plus sur OwnTracks, allez sur ce site web : https://owntracks.org/booklet/.

A propos de la conception du sujet owntracks :

https://owntracks.org/booklet/guide/topics/

"Les principes qui ont présidé à la conception du système de dénomination des sujets de OwnTracks sont les suivants

• lisibilité humaine
• minimisation du trafic
• contrôle d'accès granulaire

“

Nom du sujet de base (d'autres sont possibles) :

owntracks/peter/iPhone

ici owntracks est un préfixe, pour permettre à d'autres applications sans collisions sur le broker MQTT.

peter est le propriétaire de dispositifs de suivi, et l'iPhone est l'un de ses dispositifs.

les commandes aux appareils sont envoyées sur : owntracks/peter/iPhone/cmd

la sortie des commandes est publiée par exemple dans les noms relatifs des sujets étape, déverser etc.

d'autres sujets sont définis (info, waypoint, événement). Les événements sont publiés, par exemple, lorsqu'un utilisateur entre dans une zone définie.

De cette façon, l'abonnement à owntracks/+/+/event vous permettra de voir (pour les utilisateurs que vous êtes autorisé à voir) quand ils entrent ou quittent une zone définie.

Owntracks publie ses messages au format JSON :

https://owntracks.org/booklet/tech/json/

comme vous pouvez le voir, les fonctions sont après l'appareil.

Puisqu'il y a une "profondeur" fixe pour l'utilisateur/appareil connue à l'avance, l'abonnement à plusieurs utilisateurs et appareils peut être fait en utilisant des caractères génériques :

Dans le JSON, le type du JSON particulier est transmis dans le message :

C'est une bonne idée ! De cette façon, vous pouvez vérifier que votre application comprend correctement l'événement, peut effectuer des contrôles de type, etc.

Les différents éléments sont spécifiés de manière non verbeuse. Cela permet d'économiser du trafic, notamment pour les messages qui seront publiés fréquemment.

Par exemple :

• acc : précision de la localisation rapportée en mètres (sans unité)

de nombreux éléments sont facultatifs.

Il est intéressant de noter que le type d'emplacement est défini pour différents appareils, qui prennent en charge différents éléments.

Un simple message de testament est publié. Il inclut simplement un horodatage tst, auquel le dispositif s'est connecté pour la première fois.

tst est un horodatage d'époque Unix.

Un aspect intéressant de ce type d'événement / type de charge utile est que plusieurs horodatages sont spécifiés :

• wtst : Horodatage de la création du waypoint
• tst : Horodatage auquel l'événement s'est produit.

Un point de passage est un point d'intérêt, par exemple votre garage - si vous entrez ou sortez de votre garage, un événement de transition sera déclenché :

• événement : (entrée|sortie)

Un événement de configuration. Si cette option est activée, les applications acceptent également les messages de configuration à distance.

Cet événement comprend de nombreux éléments possibles, qui sont plus verbeux (par exemple, validatecertificatechain) - c'est judicieux, puisque la configuration peut être stockée en JSON ( ! -> cela peut être transmis comme message MQTT et stocké !), et aussi parce qu'il n'est pas envoyé souvent, la verbosité n'est pas un gros problème, mais plutôt un avantage pour les utilisateurs.

par exemple, une action avec l'option "action" : "dump" déclenchera une publication du message de configuration vers le chemin relatif dump

des sous-paramètres facultatifs peuvent être donnés pour une action, par exemple une période à examiner :

Une autre idée de conception intéressante est que par une certaine variation de ce message cmd, un navigateur peut être ouvert à une certaine URL. Par exemple, si vous entrez dans le garage, un site de contrôle du garage pourrait être ouvert, ...

un tableau d'un type de message différent peut/doit être passé en paramètre ici.

Ce qui est intéressant dans ce message, c'est qu'il comporte également un champ pour une image PNG codée en base64 :

l'idée intéressante ici est qu'une option _créateur peut être transmis, qui identifie l'entité qui a créé ces points de repère.

Notez également que owntracks utilise l'underscore _ pour les paramètres "spéciaux".

En option, tous ces messages peuvent être crypté pour le transport avec une clé symétrique partagée.

La charge utile chiffrée (le message original) se trouvera dans l'élément "data", codé en Base64.

Messages

La charge utile du message est binaire et peut être n'importe quoi, il n'y a aucune exigence que les messages soient valides UTF-8.

Vous pouvez donc également publier des données numériques, par exemple des images, comme charge utile sur certains sujets.

De nombreux tableaux de bord IoT actuels prennent des données encodées en JSON.

En général, il semble y avoir deux écoles de pensée : celle où les messages sont en fait des valeurs brutes et où les métadonnées sont codées dans l'arbre des sujets, et celle où les valeurs sont codées en JSON et où les métadonnées font partie des données utiles.

suggestions

• Utiliser le format JSON pour les données utiles du message
• regrouper les attributs dans des messages, au lieu de créer des sujets individuels pour eux
• inclure :
• données de la charge utile
• identifiant du capteur / dispositif (s'il ne fait pas partie de l'arbre thématique)
• fonction
• horodatage

Ressources intéressantes

Awesome MQTT : Collection de liens relatifs à MQTT :

• https://github.com/hobbyquaker/awesome-mqtt

projets individuels :

twitter-to-mqtt - Un démon python qui utilise l'API Twitter Streaming pour accéder aux tweets et les republier dans un sujet MQTT.

• https://github.com/knolleary/twitter-to-mqtt

fritz2mqtt - Connecter la FRITZ!Box à MQTT.

• https://github.com/akentner/fritz2mqtt

Réf :

• https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/
• https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
• https://homieiot.github.io/
• https://github.com/homieiot/convention
• https://github.com/mqtt-smarthome/mqtt-smarthome
• http://www.steves-internet-guide.com/mqtt/
• http://www.steves-internet-guide.com/understanding-mqtt-topics/
• http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/
• https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch
• https://tinkerman.cat/post/mqtt-topic-naming-convention
• https://github.com/mqtt-smarthome/mqtt-smarthome/blob/master/howtos/homematic.md (montrant le flux avec Node RED)
• https://owntracks.org/booklet/tech/json/

La réédition :

• https://lodge.glasgownet.com/2012/09/23/mqtt-republishing-itch/
• https://github.com/kylegordon/mqtt-republisher

Signal K pour l'utilisation de Marine (comme inspiration possible pour le format JSON) :

• http://signalk.org/specification/1.3.0/doc/signalk.pdf