Salut @pierre-gilles
Je viens de mettre à jour vers la v4.17.0 et je constate des erreurs du Zigbee2MQTT.
C’est surement en lien, je n’arrive plus à controler mes périphériques Zigbee depuis la mise à jour, mais l’interface de Gladys fonctionne.
Je confirme :
- Zigbee2MQTT fonctionnel via l’interface web dédié (port 8080)
- Controle via Gladys KO
Salut, j’ai l’impression que l’erreur dit simplement que Gladys reçoit une valeur de zigbee2mqtt, mais que celle-ci n’est pas gérée par Gladys.
Peux-tu essayer de mettre à jour ton device depuis la page « Découverte Zigbee » du service Zigbee2Mqtt ?
J’ai vérifié, il n’y avait pas de maj de device zigbee dans les parametres du service.
Je viens de voir ta solution… c’est tout de même gênant que ce soit si peu stable…
N’hésite pas à donner d’autres logs / info si des problèmes d’instabilité reviennent.
Plus on a d’info, plus on peut tenter un correctif.
Pour info, la v4.17.0 ne touche pas au Zigbee2mqtt, donc tu as du tomber dans un bug lié au restart de Gladys, ou au restart d’un des 2 containers nécessaires à cette intégration.
Il aurait fallu les logs complètes pour voir ce qui s’est passé, la prochaine fois pense à les garder 
C’est quoi le meilleur moyen de récupérer ça ?
Que je le sache pour la prochaine fois…
Moi je ferais :
docker logs gladys &> gladys_logs.txt
Ça fait beauuuucoup de logs, mais ça marche en effet.
Par contre, MQTT a été mis à jour hier chez moi… Peut-être un lien?
Est-ce que Zigbee2mqtt réagit bien au redémarrage du container MQTT ? De Gladys ?
Si quelqu’un arrive à avoir un exemple reproductible
J’ai vu que j’étais en 4.17.0 ce matin… première chose que je fais : j’ouvre mes volets (z2m) et aucun problème chez moi
1 « J'aime »
Hello,
Chez moi, le service semble avoir redémarré correctement (tout est démarré d’après le menu configuration de l’intégration).
Cependant, plus aucun de mes devices de l’intégration n’est mis à jour depuis le redémarrage suite MAJ Gladys. Je regarde en rentrant ce soir les logs pour alimenter la discussion.
@AlexTrovato Si jamais Gladys redémarre, et que le container MQTT n’est pas disponible, est-ce que Gladys est capable de s’y reconnecter plus tard quand le container MQTT est dispo ?
Je me répond à moi même, j’ai l’impression en lisant que le code et la doc de MQTT.js, si jamais la connection se fait pas dans les 30 premières secondes, c’est mort
Côté intégration Zigbee2mqtt dans Gladys:
(Source: Gladys/connect.js at master · GladysAssistant/Gladys · GitHub )
Côté doc MQTT.js:
Doc: mqtt - npm
Dans certain cas, en cas de mise à jour de MQTT juste après la mise à jour de Gladys (ce qui est logique, Watchtower fait tout en série au même moment), et bien si la mise à jour prend plus de 30 secondes (largement possible si la connection internet de l’utilisateur est pas folle), l’utilisateur n’aura plus Zigbee2mqtt de dispo
A tester en réel, mais je pense que c’est ça qui arrive.
@AlexTrovato t’en penses quoi ?
A mon avis, il faut qu’on ait une vrai stratégie de reconnection même avant la première connexion au cas ou ça foire, faudrait voir si il y a pas une façon recommandée de faire avec cette lib, pour re-essayer toutes les 15 secondes « ad vitaam » ?
1 « J'aime »
Ça me paraît bizarre quand même, vu l’ordre de WatchTower. Le redémarrage de ces containers (mosquito et zigbee2mqtt) est quasiment instantané, le download est censé être fait avant.
Watchtower will pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially.
1 « J'aime »
Sinon y’a peut être un paramètre type delai pour la mise à jour des container par watchtower ?
@cicoub13 Effectivement ! Mais bon, je pense quand même qu’on a un trou dans la raquette de ce niveau là, c’est chaud que l’intégration sache pas retomber sur ces pattes si un container est indisponible pendant 30 secondes (pour la 1ère connection)
1 « J'aime »
Sachant que j’ai des équipements zigbee « pollueurs » en quantité de données, ça pourrait parfois impliquer un redémarrage plus lent en cas de mise à jour Z2M ?
Quoi qu’il en soit, c’est vrai que l’intégration devrait tenter régulièrement une reconnexion. On est pas à l’abri d’un délai, d’un utilisateur qui fait une manip au mauvais moment, etc.