MQTT: qu'est-ce que "Testament" (LWT) et comment ça marche?

3 minutes de lecture

Logo MQTT

Une fois familier le proMQTT tocollo et avec ses principales caractéristiques et objectifs, il est bon de découvrir et de maîtriser un élément sur lequel nous ne nous attardons pas souvent, bien que cela soit particulièrement utile - notamment dans la domotique -.LWT"Ou"Dernière volonté et testament».

Comme le suggère la traduction, ce sont les dernières volontés et testament d'un composant équipé de protocollo MQTT, mais évidemment dans ce cas, il n’ya rien de lugubre: c’est en fait le gestion de l'état des composants en cas de déconnexion im improvvise et pas réussi. non seulement: cette fonctionnalité est utilisée non seulement pour la décès de la composante, mais aussi pour son naissance.

Voyons comment.

Nb Avant prosuite à la lecture est conseillé d'avoir une tête claire c'est quoi MQTT, Son fonctionnelnamento en domotique et le concept de "conserver".

Une question d'états

En domotique (et pas seulement) c'est certainement fondamental connaître l'état de la connexion d'un composant particulier équipé de proMQTT tocollo, à ne pas confondre avec statut opérationnel lié aux caractéristiques proen premier lieu (par exemple, état de fonctionnement de tout relais, capteur, etc.). En usage quotidien, il est en effet possible pour ces composants perdre (temporairement ou non) la connexion au courtier pour:

  • manque de courant (piles épuisées);
  • signal faible Wi-Fi;
  • anomalies dans le firmware / logiciel (redémarrage inattendu)

et d'autres conditions inattendues.

Dans la zone MQTT, nous avons souvent parlé de "messages télémétriques" fournis par les composants domotiques présents dans la maison. Nous pensons trivialement un capteur intelligent équipé de proMQTT tocollo: ce composant délivrera de manière cyclique un message de télémétrie indiquant l’état de fonctionnement lié à prosa fonctionnalité (contenant, par exemple, la température et l'humidité).

Ceux qui collectent ces informations sont généralement d’autres clients MQTT qui, connectés au courtier, souscrivent au sujet des messages télémétriques qui les intéressent; ces clients sont (généralement) HUB personnel (Home Assistant, Homey etc.) qui utilisent les informations ainsi collectées pour les usages ordinaires envisagés pour propremière domotique (visualisation, automatisation, etc.).

Mais ce qui est aussi fondamental, c’est non seulement de recevoir ou d’envoyer des messages depuis et vers des composants MQTT, mais aussi être conscient ou pas si ces composants sont réellement connectés au courtier via le réseau TCP/IP, s'ils sont alors d'exploitation. Comme expliqué ci-dessus, il peut arriver que le lien entre le composant et le courtier "cada", induisant le composant indisponible.

Pour gérer ces cas afin que les clients MQTT n'ignorent pas le statut des composants qui les intéressent, il intervient, appgras, leLWT. En pratique, il s’agit d’un message spécial MQTT (avec conserver toujours mis "vrai") Qui est envoyé aux abonnés en deux moments spécifiques: à la" naissance "et à la" mort "du composant.

Lorsque le composant "est né" (c'est-à-dire lorsqu'il entre sur le réseau LAN), il se connecte par nature au courtier via les coordonnées connues (adresse IP, informations d'identification d'accès) et, lors de la première connexion, communique la charge utile LWT fournie en cas de déconnexion (habituellement "Hors ligne« ). Le courtier "marque" cette charge utile et la met de côté, attendant de l'utiliser - éventuellement - en cas d'échec de la connexion. Un vrai e proprio volontépour ainsi dire.

Une fois la connexion établie, le composant publie également sur le courtier un message MQTT contenant une rubrique de type LWT avec une charge utile l’identifiant. comme opérationnel, ou (généralement) "Magasinez». Immédiatement, tous les clients enregistrés dans le sujet du message LWT le reçoivent et supposent donc que le composant est - pour leappoint - opérant.
Par exemple, dans le cas d’un Sonoff avec la configuration de base, le message MQTT publié après la première connexion sera:

Télé /Sonoff/ LWT en ligne

où le sujet est évidemment "Télé /Sonoff/ LWT"Tant que la charge utile est"Magasinez».

Par la suite, au cas où le composant touché "échouerait" (en raison des causes possibles mentionnées ci-dessus) - au bout d'un certain temps, le courtier ne recevant plus aucun signe de vie de la part du composant - ce dernier retirera la charge utile attendue pour la "chute" (celle précédemment mise de côté) et le publie dans un message LWT, comme:

Télé /Sonoff/ LWT Offline

En conséquence, tous les clients ont souscrit au sujet (également dans ce cas "Télé /Sonoff/ LWT") Sera notifié immédiatement l'état d'indisponibilité du composant.

En pratique, alors que est le composant lui-même informer chacun de son entrée en service, c'est le courtier à la place pour signaler une éventuelle chute et pour informer le réseau de cet événement (à l'aide de la charge utile LWT communiquée par le composant lors de sa "naissance" la dernière fois).

Cela explique pourquoi, par exemple, su Home Assistant configurer un commutateur Sonoff-Tasmota nous utilisons une syntaxe de ce type:

switch:
  - platform: mqtt
    name: "Interruttore"
    state_topic: "stat/Interruttore/RESULT"
    value_template: "{{ value_json.POWER }}"
    command_topic: "cmnd/Interruttore/POWER"
    availability_topic: "tele/Interruttore/LWT"
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"

Comme vous pouvez facilement le constater, sur le terrain "availability_topic"Vient proavant d’indiquer le sujet LWT auquel enregistrer le client de Home Assistant connaître instantanément le statut du composant, avec les charges utiles attendues respectives (pour les deux situations possibles,Magasinez"Et"Hors ligne") À suivre.


Veuillez commenter ci-dessous