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
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
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.
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 » ?
Ç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.
@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)
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.
Dans les logs il n’y a aucune notion de déco ou quoi que ce soit côté gladys, je penses qu’on dérive un peu du problème d’origine => appareils non controllable via Gladys.
Pour la prochaine fois car maintenant ça me paraît mort, il faut les logs gladys / mqtt / zigbee2mqtt
pareil pour moi plus de données capteur mais Z2Mqtt 8080 accessible sans problèmes, j’ai désactivé le servie puis réactivé et tout est rentré dans l’ordre.
Quand même capricieux des fois ce ziegbee ??