Depuis hier soir le démon ne se lance plus. Cela fait suite à une mise à jour il me semble. Tout fonctionnait parfaitement jusqu’à présent et je n’ai touché à rien.
[2023-12-02 09:05:06,490][INFO] Main MainThread set_log_level() : New log level set to: ERROR
[2023-12-02 09:05:06,500][ERROR] JMsg.Snd MainThread send_test() : Callback test Exception (HTTPConnectionPool(host='127.0.0.1', port=8090): Max retries exceeded with url: /plugins/jMQTT/core/php/callback.php?apikey=***&uid=3020:41065 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f6e3e4e4fd0>: Failed to establish a new connection: [Errno 111] Connection refused')))
[2023-12-02 09:05:06,500][CRITICAL] Main MainThread open_comm() : Open Comm : Failed to Open the communication channel to send informations back TO Jeedom
[2023-12-02 09:05:06,995][CRITICAL] Main MainThread open_comm() : Open Comm : Closed the communication channel to get instructions FROM Jeedom
Je précise que mon jeedom est installé en docker sur un Nas Synology.
Une idée ? Je n’ai plus de chauffage et les enfants à gérer, c’est un peu la panique
On dirait oui… Mais je n’ai touché à aucun paramètre côté Jeedom. Je ne vois pas pourquoi ma configuration réseau serait soudainement devenue fautive ! Côté mqtt tout fonctionne, le serveur tourne, les autres appareils sont connectés.
Disons qu’il est assez curieux que cela coïncide avec une mise à jour du plugin. Je suis le seul avec le problème ?
À chaque redémarrage jeedom peut changer son réseau interne. J’en ai déjà vu qui repassaient sur 169.254 par ex (même si en regardant le code du core, je ne vois pas comment c’est possible car cette adresse est justement pas autorisée)
J’ai déterré une ancienne version qui fonctionnait encore, la configuration réseau n’était effectivement pas la même, avec un accès interne réglée sur le container docker plutôt que sur le nas. J’ai fait ce réglage tout refonctionne. Je ne comprends pas, car cela fait plusieurs moi que jeedom tournait sans problème avec ces paramètres. Mais bref. Merci pour ton aide !
Puis-je avoir une capture d’écran de ta page network et de la page de config du plugin jMQTT stp ?
Pour info, il y a des contraintes à utiliser jMQTT en docker :
le réseau Jeedom doit être configuré d’un point de vue utilisateur, donc interne = hostname/ip ET port utilisable depuis le LAN client et externe = hostname/ip ET port utilisable depuis Internet.
apache doit écouter en local (127.0.0.1) en http (et pas systématiquement rediriger vers https),
si apache écoute sur un autre port dans le container et sur le LAN, il faut modifier la configuration spécial Docker dans jMQTT et bien y positionner le port d’écouter d’apache :
Voici pour la config réseau actuelle, maintenant que le démon remarche. A l’origine, l’adresse interne était celle du Nas (192.168.1.10) avec le port du conteneur docker (8090) et l’adresse externe était celle du DDNS Synology. Tout fonctionnait très bien comme cela.
Ok, je vois d’où vient le problème, il faut effectivement que tu personnalises la callback :
Pour Accès interne, remets HTTP 192.168.1.10 8090
Pour Accès externe, remets HTTP « ddns syno » et le port d’écoute sur internet (8090?), si besoin
Dans la config de jMQTT coche juste « URL de Callback du Daemon » et laisse l’url qui est en place.
Et tout devrait rouler
Pour les détails techniques, il n’y a aucune configuration dans Jeedom pour faire la différence entre le port « Interne » LAN et le port « Interne » de apache dans Docker. Le daemon essaye de joindre Jeedom sur 127.0.0.1 sur le port configuré dans « Accès interne », ce qui n’a pas de sens en Docker, d’où l’introduction de ce champ de configuration (cf topic Démon NOK avec la version 2022-07-19 01:01:16). Avec un peu de recul, on sait maintenant détecter correctement une installation en docker, je dois pouvoir choisir le bon port dans le cas d’une installation en docker.
Merci beaucoup ! C’était la panique ce matin au réveil, le chauffage qui tourne à fond, les volets qui ne remontent pas… Au moins je passerai une bonne nuit
Et je te remercie d’avoir prise en considération ce cas technique, tu es bien le seul à avoir proposé cette option. Pour d’autres plugins je dois encore éditer le callback à la main, heureusement c’est moins critique que ce plugin.
