J'utilise la bibliothèque EspmqtClient pour Arduino et ESP8266; Mais ma question peut bien être applicable à n'importe quel environnement.
Le client définit un dernier message pour diffusé dans le cas où le client goutte. Toutefois, si le client tombe puis reconnecte immédiatement, je veux supprimer le message.
Comme le client unique est identique, je pensais que ce serait un comportement standard; Mais apparemment pas.
Ainsi, le client tombe et reconnecte. Je reçois les messages de démarrage que le client envoie et puis i obtenez le message "client est mort". Cela n'est pas utile, car il semble que le client soit mort et n'a pas réussi à se reconnecter. Comment puis-je supprimer les messages de dernière fois que les clients se reconnectent avec succès avant que le délai d'attente ne se produise? EDIT: Voici un code simplifié qui démontre le problème: Le problème semble être lié à la chaîne Je cours "Mosquitto MQTT V3.1 Message Broker", et l'abonné ressemble à ceci: < / p> (Service_name) + "/ exemple" Bit. J'ai envisagé que cela créait peut-être un pointeur pendant; Mais s'agissait-il d'être la cause, je m'attendrais à ce que la LWT se produise même avant que le client perdit la connexion.
3 Réponses :
Non, il n'y a aucun moyen de supprimer le dernier volonté et testament (LWT)
Mais si vous êtes sûr que vous utilisez une cliente cohérente, je ne pense pas que cela devrait l'envoyer. Vous avez dit que vous réinitialisez le périphérique, ce qui signifie que le son du courtier est en attente de 1,5 * la maintenance de la maintenance, puis de déconnecter le client. Tant que les périphériques se reconnectent avec le même clientide avant cela ne se produise ou devraient expulser l'ancienne connexion sans tirer la LWT.
Je ne peux pas voir où vous définissez soit le temps d'aliblement de GARDE, soit le clientIide dans le code que vous avez posté, il est donc difficile de dire plus. Je susciterais également la journalisation sur le courtier pour vérifier que le client se connecte avec le même clientide et pour voir s'il s'agit d'expulser le client précédent.
Si votre courtier après la spécification MQTT V3.1.1 détecte que vous avez déconnecté, il est tout à fait correct de publier la LWT. Il n'y a aucun moyen d'arrêter cela.
@HARDILLB suggère que si la connexion a diminué mais que vous n'avez pas été remarquée par le courtier, vous avez jusqu'à maintenir * 1.5 à reconnecter avant l'envoi de la LWT. C'est correct. Cependant, et c'est un grand cependant, vous comptez sur votre perte de connexion, qui ne sont pas reconnus au courtier. Cela pourrait fonctionner parfois, mais ce n'est pas une condition que je voudrais compter sur.
Si cette fonctionnalité est très importante pour vous, vous devriez probablement regarder à l'aide de MQTT V5 à la place. Cela vous donnera la possibilité de définir l'intervalle d'expiration de la session, qui correspond à la quantité de temps pour garder votre session active après la déconnexion avant d'envoyer votre LWT.
Je ne sais pas si l'une des bibliothèques client intégrées MQTT a été mise à jour pour prendre en charge MQTT V5
Dans votre cas spécifique, essayez de passer à Mosquitto 1.6.3 ou plus récent. Il y a un bug avec des prises de contrôle de la session affectant 1.5.Quelque chose à 1.6.2.
Mettez à jour la question avec le code client et la version de Mosquitto que vous utilisez.
Inclure également les détails de l'abonné qui consiste à voir la LWT étant livrée après le message de reconnexion.
Est-il peut-être que le nom de service est considéré comme null à tout moments , en raison d'un pointeur pendling?
3.1 N'EST PAS la version MOSQUITTO, c'est la version du protocole MQTT. La version Mosquitto sera 1.X où X est le plus probable 5 ou 6