Du coup dans les logs rien d’anormal. Jusque que la scène ne fonctionnait pas à cause de la déconnexion du broker MQTT.
2025-02-15T18:24:49+0100 <warn> scene.executeActions.js:37 (executeAction) ServiceNotConfiguredError: MQTT is not configured.
at ZwaveJSUIHandler.publish (/src/server/services/zwavejs-ui/lib/zwaveJSUI.publish.js:12:11)
at ZwaveJSUIHandler.setValue (/src/server/services/zwavejs-ui/lib/zwaveJSUI.setValue.js:97:10)
at DeviceManager.setValue (/src/server/lib/device/device.setValue.js:21:24)
at Object.device.set-value (/src/server/lib/scene/scene.actions.js:66:24)
at executeAction (/src/server/lib/scene/scene.executeActions.js:32:35)
at /src/server/lib/scene/scene.executeActions.js:66:13
at tryCatcher (/src/server/node_modules/bluebird/js/release/util.js:16:23)
at MappingPromiseArray._promiseFulfilled (/src/server/node_modules/bluebird/js/release/map.js:68:38)
at MappingPromiseArray.PromiseArray._iterate (/src/server/node_modules/bluebird/js/release/promise_array.js:115:31)
at MappingPromiseArray.init (/src/server/node_modules/bluebird/js/release/promise_array.js:79:10)
at MappingPromiseArray._asyncInit (/src/server/node_modules/bluebird/js/release/map.js:37:10)
at _drainQueueStep (/src/server/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/src/server/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/src/server/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues (/src/server/node_modules/bluebird/js/release/async.js:15:14)
at processImmediate (node:internal/timers:476:21)
J’ai regardé mon container mqtt et il s’était mis à jour 16 plus tôt.
Du coup, j’ai essayé en arrêtant le containeur manuellement et j’ai eu le phénomène. Donc si Gladys perd la connexion suite arrêt du container, mise à jour… Gladys ne se reconnecte pas automatiquement.
Je n’avais pas fait attention que j’avait pris la version latest. Je vais bloqué pour qu’il ny ai pu de mise à jour automatique sur ce container.
Ouf, et bof je ne suis pas le seul.
Mon docker MQTT externe s’est mis à jour hier soir chez moi (2.0.20 à 2.0.20) et la connexion n’est pas repartie seule.
Mais c’est un autre problème qui survient en fait car j’ai aussi zwaveJS qui ne redémarre pas, et je m’en suis aperçu ce soir.
Pour faire repartir le tout, j’ai dû aller dans la config de l’intégration MQTT et sauvegarder, puis dans la confg de zwaveJS et sauvegarder aussi.
Je précise que mon HA et jeedom n’ont pas eu de soucis et continuer bien sagement à envoyer les données vers MQTT.
Autre point, j’ai un appareil MQTT pour récupérer des infos envoyées par jeedom (téléinfo principalement) et des fonctionnalités qui écoutent des topics personnalisés. Et malheureusement aucune donnée des topics personnalisés ne remontaient.
J’ai dû modifier une valeur dans une des fonctionnalités et sauvegarder pour que tout reparte à la normale.
Je suis dispo si besoin de creuser plus en détail et debugguer le bouzin, il faudra juste me guider pour les infos à récupérer.
Dans le cas de Z-WaveJS, est-ce que vous êtes capable de reproduire le bug à la main ? Si tu redémarre le container Mosquitto, est-ce que la déconnexion se produit ou est-ce que c’est uniquement si c’est une mise à jour ?
Je veux bien que tu créé un sujet spécifique pour ne pas qu’on s’embrouille, c’est déjà un sujet compliqué ici
Oui je peux reproduire si j’arrête le container manuellement avec la commande docker stop … et si je le démarre ensuite avec la commande docker start …
Je crois voir ce qui se passe, @Terdious avait déjà remarqué ça, mais il y avait tout simplement du code dans l’implémentation actuelle qui déconnectait Gladys en cas de perte de connexion…
J’ai retiré toute cette partie, et en ai profité pour migrer à MQTT.js 5 qui est entièrement re-écrit en TypeScript et normalement plus stable.
J’ai fais des tests, et ça marche beaucoup mieux !
