md
Fin des déconnexions de Tasmota/ESP8266 avec Mosquitto MQTT
2019-11-08
<-Home Automation Servers on Raspbian Buster Lite --

Plusieurs utilisateurs de dispositifs ESP8266 ont remarqué de nombreuses déconnexions inexpliquées avec le serveur MQTT. En résumé, la source du problème n'est pas dans Tasmota, ni dans la bibliothèque Arduino Client for MQTT (PubSubClient), et ni dans le serveur MQTT Eclipse Mosquitto. À mon avis, le problème réside dans le code Wi-Fi du noyau ESP8266 pour Arduino. Si vous utilisez Tasmota, passez à la version 6.7.1 et les déconnexions injustifiées des clients du serveur MQTT devraient disparaître. Si vous compilez votre propre micrologiciel, utilisez la version 2.5.3 du noyau Arduino ESP8266. Pour l'installer dans l'EDI Arduino, utilisez l'URL suivante

https://github.com/Jason2866/Arduino/releases/download/2.5.3/package_esp8266com_index.json

dans le champ URL de gestionnaire de cartes supplémentaires (Menu: Fichier/Préférences/Paramètres ou raccourci clavier Ctrl,).

Le récit qui suit où je raconte comment j'ai rencontré le problème pour ensuite réaliser qu'il existait une solution simple devrait être absolument fascinant.

Après avoir installé le courtier Mosquitto MQTT sur le Raspberry Pi 3 B, qui hébergera désormais notre système domotique, j’ai parcouru son fichier journal. Il contenait de nombreux messages sur les erreurs de socket et les déconnexions. Voici un court échantillon de ce que j'ai trouvé.

woopi@goldserver:~ $ sudo tail -f /var/log/mosquitto/mosquitto.log ... 1572128560: New client connected from 192.168.1.108 as DVES_6F028F (c1, k10, u'DVES_USER'). 1572128624: Socket error on client DVES_6F028F, disconnecting. 1572128625: New connection from 192.168.1.108 on port 1883. 1572128625: New client connected from 192.168.1.108 as DVES_6F028F (c1, k10, u'DVES_USER'). 1572128641: New connection from 192.168.1.45 on port 1883. 1572128641: New client connected from 192.168.1.22 as mosqpub|16971-goldserver (c1, k60). 1572128641: Client mosqpub|16971-goldserver disconnected. ...

Il existe une tâche cron sur le serveur qui publie un court message MQTT toutes les deux minutes. Une connexion MQTT avec un client qui publie un message ne dure que le temps nécessaire pour envoyer le message au courtier. Par conséquent, la dernière paire d'opérations de connexion et de déconnexion dans le journal ne pose pas de problème.

Les autres déconnexions étaient inattendues. Celles-ci provenaient évidemment de périphériques ESP8266, principalement de commutateurs Wi-Fi Itead Sonoff Basic. Tous ceux-ci exécutent une version assez récente de l'excellent micrologiciel Tasmota. Je dois admettre que cette rafale de déconnexions était plutôt déconcertante, mais cela ne semblait pas avoir d'impact sur les performances du système domotique. Néanmoins, je voulais trouver la cause et une solution si possible.

Ainsi, depuis quelques semaines, je cherche sur le Web des informations sur ce sujet. Il s’est avéré que c’était un autre de ces problèmes bien connus dont j'ignorais l'existence. Je devrais regarder les fichiers journaux plus souvent.

Certains membres de la communauté Home Assistant blâmaient Tasmota et ont décidé d'utiliser un logiciel embarqué différent qui leur permettait de supprimer le serveur MQTT. Je ne pensais pas qu'il était probable que Tasmota soit la source du problème, car le dispositif ayant le plus de problèmes de déconnexions était mon ferme-porte de garage automatique construit sur un Itead SV avec mon propre micrologiciel. Le SV était-il en jeu? Probablement pas parce qu’il y avait autant de déconnexions lors de l’exécution du micrologiciel sur un Wemos (maintenant Lolin) D1 mini. Alors que mon micrologiciel « calque » de près une ancienne version de Tasmota, les parties de connexion et de reconnexion MQTT sont presque un copier-coller du code exemple inclus avec la bibliothèque PubSubClient. Pour ajouter au mystère, mon moniteur de routeur, qui est essentiellement un Itead Sonoff Basic, ne se déconnectait que rarement du serveur MQTT, même s'il possède les mêmes fonctions de connexion et de reconnexion MQTT que celles utilisées dans le ferme-porte du garage.

Certains ont blâmé la bibilothèque PubSubClient, mais les discussions dans la partie issues du GitHub Tasmota semblaient rejeter cette hypothèse. Il y avait des mentions du signal keepalive, que Tasmota gère, mais que mon micrologiciel ne faisait pas. J'ai donc mis en place un deuxième serveur MQTT sur un autre Raspberry Pi et j'ai expérimenté avec diverses valeurs du paramètre en utilisant un D1 mini. Je n'ai réalisé aucun progrès.

Toujours dans les issues de Tasmota, on retrouve des discussions au sujet des diverses versions du noyau ESP8266 pour Arduino. Je me suis souvenu d’avoir ignoré la version 2.4.x, passant directement de la version 2.3.0 à la version 2.5.2 en raison de problèmes avec les versions intermédiaires. Peut-être que je devrais réessayer l'ancien noyau? Lorsque j'ai consulté le Wiki de Tasmota pour plus d'informations, j'ai remarqué que la version 6.7.1 de Tasmota était disponible et qu'elle serait « basée sur la version pré-2.6.0 du noyau ESP8266 pour Arduino en raison de problèmes de sécurité et de stabilité » ( supported from ESP8266/Arduino library Core version pre-2.6.0 due to reported security and stability issues on previous Core version.. De plus, je ne pouvais plus trouver la page Wiki contenant des informations sur les problèmes avec le serveur MQTT. C'est là que j'ai pigé.

Hier, j'ai modifié mon expérience hier. Il y avait un Sonoff Basic R3 de rechange sur lequel j'ai téléversé Tasmota 6.7.1. J'ai recompilé le micrologiciel de mon ferme-porte de garage automatique à l'aide de la version 2.5.3 du noyau ESP8266 pour Arduino que j'ai ensuite téléversé sur un Lolin (Wemos) D1 mini. Les deux dispositifs ont ensuite été connectés au deuxième serveur MQTT fonctionnant sur un Raspberry Pi 3 B. Son système d'exploitation est la dernière édition de Rasbian Buster Lite (septembre 2019). Le serveur MQTT est mosquitto version 1.5.7-1 obtenu du référentiel Raspbian. Il n'y a pas eu une seule erreur de socket ni de déconnexion avec le serveur MQTT depuis le début de cette expérience il y a plus de 12 heures.

Les solutions à un problème nécessitant uniquement une mise à niveau sont tout simplement les meilleures.

<-Home Automation Servers on Raspbian Buster Lite --