J’ai une interrogation sur le fonctionnement de MQTT pour la notion d’équipement online ou offline.
En effet, les équipement ont tous une commande MQTT Online ou LWT. Par contre, si l’équipement passe offline, par définition, il ne communique plus au broker MQTT et donc ne peut pas mettre à jour ces 2 commandes (qui devraient en toute logique rester Online !).
J’ai l’impression d’un autre coté que la commande LWT ne semble pas etre une commande classique, mais malgré mes lectures, impossible de comprendre comment ceci fonctionne.
Du coup, comment fonctionne ces commandes ou comment peut-on savoir que l’équipement est offline ?
Limite si tu le vois plus c’est qu’il est parti donc offline🫣
Plus sérieusement, je te rejoins dans ton interrogation car j’ai le cas justement avec un Shelly 2.5 en shutter dont la clé online varie avec le temps…
C’est une question très sensée : comment est-ce que un équipement peut dire qu’il n’est plus là, quand il n’est plus là ?
Et bien il ne peut pas !
Donc MQTT implémente une méthode qui autorise le Broker a envoyer un message sur un topic quand la connexion mqtt est perdue (LWT) avec l’équipement (client). Quand le client se connecte, il envoie « online » (ou quoi que ce soit d’autre, comme true) sur un topic particulier et informe le Broker de publier pour lui « offline » (ou false ou autre chose) sur ce même topic quand il ne sera plus.
Pour info LWT veut dire « last will and testament ».
Du coup, c’est automatiquement géré ? Comment le broker sait que la commande Online est une commande Online (j’imagine que le seul nom de la commande ne suffit pas ?)
Est-ce ke fait d’integrer cette commande dans « Commande de disponibilité » ?
Alors attention tu mélanges 2 choses : Broker (mosquito) et équipement Broker dans jMQTT.
Regarde la doc j’ai fais un gros effort pour expliquer le MQTT, comment ça marche et ce type de subtilités.
Pour répondre à ta question, c’est une commande du protocole MQTT, pas une commande Jeedom, qui informe mosquito du topic et message à transmettre. Il n’y a rien de plus.
Par contre, dans jMQTT tu peux récupérer ces messages (online/offline) sur un topic dans une commande info binaire et l’utiliser pour refléter l’état de disponibilité de l’équipement, oui.
Oui c’est automatique et le broker le sait pas par magie mais parce que c’est le client qui lui donne l’info pendant la connexion initiale. Cela fait partie du protocole mqtt.
Étant donné que MQTT est souvent utilisé dans des scénarios qui incluent des réseaux non fiables, il est raisonnable de supposer que certains des clients MQTT dans ces scénarios se déconnecteront occasionnellement sans grâce. Une déconnexion désagréable peut se produire en raison d’une perte de connexion, de batteries vides ou de nombreuses autres raisons. Savoir si un client s’est déconnecté correctement (avec un message MQTT DISCONNECT) ou de façon irrégulière (sans message de déconnexion) vous aide à répondre correctement. La fonction Dernières volontés et testament permet aux clients de répondre de manière appropriée aux déconnexions intempestives.
Dans MQTT, vous utilisez la fonctionnalité Last Will and Testament (LWT) pour informer les autres clients d’un client mal déconnecté. Chaque client peut spécifier son dernier message lorsqu’il se connecte à un courtier. Le dernier message testament est un message MQTT normal avec un sujet, un indicateur de message conservé, une QoS et une charge utile. Le courtier stocke le message jusqu’à ce qu’il détecte que le client s’est déconnecté de manière intempestive. En réponse à la déconnexion intempestive, le courtier envoie le message de dernière volonté à tous les clients abonnés au sujet du message de dernière volonté. Si le client se déconnecte correctement avec un message DISCONNECT correct, le courtier ignore le message LWT stocké.
Selon la spécification MQTT 3.1.1, le broker doit distribuer le LWT d’un client dans les situations suivantes :
Le courtier détecte une erreur d’E/S ou une défaillance du réseau.
Le client ne parvient pas à communiquer pendant la période Keep Alive définie.
Le client n’envoie pas de paquet DISCONNECT avant de fermer la connexion réseau.
Le courtier ferme la connexion réseau en raison d’une erreur de protocole.
LWT est un excellent moyen d’informer les autres clients abonnés de la perte inattendue de connexion d’un autre client. Dans des scénarios réels, LWT est souvent combiné avec des messages conservés pour stocker l’état d’un client sur un sujet spécifique. Par exemple, client1 envoie d’abord un message CONNECT au courtier avec un lastWillMessage qui a « Offline » comme charge utile, l’indicateur lastWillRetain défini sur true et le lastWillTopic défini sur client1/status. Ensuite, le client envoie un message PUBLISH avec la charge utile « En ligne » et l’indicateur retenu défini sur vrai au même sujet (client1/status). Tant que client1 reste connecté, les clients nouvellement abonnés à la rubrique client1/statut reçoivent le message retenu « En ligne ». Si le client1 se déconnecte de manière inattendue, le courtier publie le message LWT avec la charge utile « Hors ligne » comme nouveau message retenu. Les clients qui s’abonnent au sujet alors que le client1 est hors ligne reçoivent le message LWT retenu (« Hors ligne ») du courtier. Ce modèle de messages conservés tient les autres clients informés de l’état actuel de client1 sur un sujet spécifique.
Ce qu’il me semble avoir compris (désole si je vulgarise !)), c’est que par défaut, la valeur du topic « online » est à 0 ou Offline coté broker. Cette valeur est enregistrée (retain) et est donc la valeur par défaut.
L’équipement envoie régulièrement, lorsqu’il est en ligne Online ou 1 et donc force la valeur du topic tant qu’il est en ligne. Mais dès lors que l’équipement ne renvoie plus cette valeur Online, le broker rebascule sur la valeur par défaut … soit Offline ou 0 du coup, le client récupère du broker Offline ou 0 et indique donc que l’équipement n’est plus joignable.
Tests fait sur un shelly 1 (topic online) et sur un tasmota (topic LWT), ca fonctionne nickel, délai de bascule de l’ordre de la minute
le lwt au moment du login du client; message qui n’est donc pas publié à ce moment
juste après, le client poste son message « Online »
si le broker perd la connexion avec le client alors le broker postera le message LWT.
Le fait que ces différents messages soient en retain ou pas ne change rien sur le flux (mais évidement ça permet aux autres clients d’avoir l’information a tout moment comme tout message retain)
(Je mets cet émoji car il fait les 10 caractères demandés)