Callback test Error (404): Not Found et Failed to Open the communication channel

Bonjour
Ca fait plusieurs jours que je cherche une solution et je n’arrive pas à démarrer.
J’étais sur un RPI Debian 9, Jeedom 3.X, l’ancine plugin zwave et j’ai tout réinstallé sur une VM le WE dernier et upgradé.

Je suis sous Debian 11, php 7.4.33, Nginx 1.18 sur le port 8180, Jeedom 4.4.12 et j’ai installé les plugins jMQTT, MQTT Manager et Z-Wave JS.
J’ai une installation un peu particulière car j’ai Traefik sur le port 80 qui sert de reverse pour des conteneurs + Nginx (qui n’est pas un conteneur) sur le port 8180.

** Plugin JMQTT
J’ai relancé plusieurs fois les dépendances, voici le log lorsque j’essaie de démarrer le daemon :

==> jMQTTd <==
[2024-10-10 00:46:05,266][INFO] Main            MainThread   set_log_level() : New log level set to: DEBUG
[2024-10-10 00:46:05,266][DEBUG] Main            MainThread         prepare() : Writing PID 486387 to /tmp/jeedom/jMQTT/jmqttd.py.pid
[2024-10-10 00:46:05,267][INFO] Main            MainThread         prepare() : Log level   : debug
[2024-10-10 00:46:05,267][INFO] Main            MainThread         prepare() : Socket port : 0
[2024-10-10 00:46:05,267][INFO] Main            MainThread         prepare() : Callback url: http://127.0.0.1:80/plugins/jMQTT/core/php/callback.php
[2024-10-10 00:46:05,267][INFO] Main            MainThread         prepare() : PID file    : /tmp/jeedom/jMQTT/jmqttd.py.pid
[2024-10-10 00:46:05,267][DEBUG] Main            MainThread         prepare() : Apikey      : aBsCwT1xm0GYe8qfu7asOWfzGbX3d9n8cXbXzIFumR2yQBSJGwgrLt3ZxZU2dCBQ
[2024-10-10 00:46:05,267][DEBUG] JMsg.Rcv        MainThread  receiver_start() : Start requested
[2024-10-10 00:46:05,267][DEBUG] JMsg.Rcv        SockIn            _loopRcv() : Start
[2024-10-10 00:46:05,267][INFO] JMsg.Rcv        MainThread  receiver_start() : Started, listening on [127.0.0.1:37455]
[2024-10-10 00:46:05,271][ERROR] JMsg.Snd        MainThread       send_test() : Callback test Error (404): Not Found
[2024-10-10 00:46:05,271][CRITICAL] Main            MainThread       open_comm() : Open Comm   : Failed to Open the communication channel to send informations back TO Jeedom
[2024-10-10 00:46:05,271][DEBUG] JMsg.Rcv        MainThread   receiver_stop() : Stop requested
[2024-10-10 00:46:05,768][INFO] JMsg.Rcv        SockIn            _loopRcv() : Stopped
[2024-10-10 00:46:05,768][DEBUG] JMsg.Rcv        MainThread   receiver_stop() : Stopped
[2024-10-10 00:46:05,769][CRITICAL] Main            MainThread       open_comm() : Open Comm   : Closed the communication channel to get instructions FROM Jeedom
[2024-10-10 00:46:05,769][INFO] Main            MainThread        shutdown() : Stop jMQTT python daemon
[2024-10-10 00:46:05,769][DEBUG] root            MainThread        <module>() : Exit 0

==> jMQTT <==
[2024-10-10 00:46:15][DEBUG] : Nettoyage du Démon
[2024-10-10 00:46:15][ERROR] : Impossible de lancer le démon jMQTT, vérifiez les logs de jMQTT

Mosquitto est installé par [MQTT Manager](http://192.168.10.7:8180/index.php?v=d&p=plugin&id=mqtt2) (mqtt2).

╰─# netstat -lptan | grep mosq
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      485363/mosquitto
tcp        0      0 0.0.0.0:8883            0.0.0.0:*               LISTEN      485363/mosquitto
tcp6       0      0 :::1883                 :::*                    LISTEN      485363/mosquitto
tcp6       0      0 :::8883                 :::*                    LISTEN      485363/mosquitto

╰─# telnet localhost 8883
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^CConnection closed by foreign host.

MQTT Manager est également KO (normal je pense si le précédent est aussi KO)
Je suis en mode local, port 8883. Le champ Authentification m’intrigue, je ne sais pas quoi renseigner.

Merci pour votre aide.

PS :

[http://127.0.0.1:80/plugins/jMQTT/core/php/callback.php](http://127.0.0.1/plugins/jMQTT/core/php/callback.php) > 

J’ai l’impression qu’il y a un probleme avec le port.

Bonjour,

Les logs dans un Texte préformaté sinon c’est illisible.

Il manque la page santé jeedom, à fournir systématiquement. On y verra probablement que votre config réseau interne est KO donc à corriger (config jeedom).

Un peu étrange de faire ça sur la même vm…
Vous ne devriez pas faire des trucs bizarre si vous ne comprenez pas. Jeedom dans sa vm devrait être seul et tourner sur le port 80.

Bonsoir

C’est pas que je ne comprends pas puisque j’ai d’autres VM sur d’autres serveurs Proxmox qui font du Docker/Traefik avec Nginx sur un autre port que le 80 et ca fonctionne très bien. J’ai fait comme ca car je pensais utiliser un conteneur Jeedom mais j’ai lu que ce n’était pas conseillé, donc j’y vais par étape (passage a Debian 11, de Jeedom v3 a Jeedom v4, je dois changer de plugin pour le zwave, passer par jMQTT,…) et quand ce sera stabilisé, j’essaierai le conteneur ou je ferais un rollback.

Voici la santé et la conf réseau.


et

Entre temps, hier soir je me suis dit que j’allais redémarrer la VM, et pour une fois, je ne l’ai pas rebooté en SSH mais en passant par Jeedom (Système / Redémarrage) et je me retrouve avec un autre bug : Un message qui m’indique que « Jeedom n’est pas démarré », impossible de redémarrer les démons. :frowning: j’ai fait une verification générale et une vérification de la Bdd et tout est pourtant OK.

Vous réinstallez x fois Traefik ?? Il n’en faut qu’un seul pour votre infra. En tout cas pas un par service.

En tout cas ça semble être votre config à ce niveau qui est incorrecte

Via navigateur vous tombez sur quoi?

Hello @petitsurfeur,

Ton installation est très particulière et à la limite ne pas être pas supportée.
Le serveur web doit écouter sur le port 80 à l’intéreur du container, afin que les daemon puissent s’y connecter.
Je ne pense pas que ton problème soit lié à jMQTT mais à ton installation.

jMQTT propose néanmoins un paramètre de config global pour le port d’écoute de Jeedom :

Je t’invite à y utiliser l’url http://127.0.0.1:8180/plugins/jMQTT/core/php/callback.php
et à configurer ton ngnix pour ne pas rediriger les requêtes sur 127.0.0.1 vers HTTPS.

Bad

@Bad Merci pour ton retour.

Le serveur web doit écouter sur le port 80 à l’intéreur du container.

Je pense qu’il y a une confusion car ni Jeedom, ni JMQTT, ni Nginx ne sont sous Docker. Traefik sert de Reverse Proxy. Donc je ne pense pas devoir configurer l’URL du callback, si ?

Et pour la configuration, je me connecte a Jeedom pour le moment en http://192.168.X.X:8180. donc je passe Traefik
Le telnet sur Mosquitto fonctionne.
Par contre, je m’interroge sur "Le champ Authentification m’intrigue, je ne sais pas quoi renseigner.

Ok, du coup pas de container, ok. Mais pourquoi alors ne pas écouter sur le port 80 ?

De l’exterieur, le container Traefik sert de Reverse Proxy et écoute sur les ports 80/443 et redirige soit vers les autres containers, soit vers le port 8180 de Nginx pour les applis Web non conteneurisés.
En local, je peux acceder à Jeedom directement sur le port 8180, sans passer par Traefik. C’est pour ca que je ne pense pas que Docker/Traefik soit le problème.

Qu’est-ce que je peux faire pour identifier l’origine du problème ?

Traefik est sur la même machine/instance que Nginx/Jeedom ?

Oui tout est sur la même VM (sous Proxmox), Traefik est un container qui écoute sur les ports 80/443. C’est lui qui gère les certificats SSL des containers et sites Web servis par Nginx (qui n’est pas un container et qui écoute sur le 8180)

C’est une usine à gaz ton système, si déjà tu as proxmox, pourquoi ne pas faire une VM à côté pour Jeedom ?

Comment tu veux garder un système propre et facilement upgradable avec autant de spécificités sur la même machine ?

Je serais toi, j’installerai un simple Jeedom en VM ou LXC à côté et ferait pointer mon Traefik dessus. Jeedom serait alors un système clos, plus facile à maintenir et mettre à jour.

Je ne suis même pas sûr que Jeedom supporte encore nginx.

En tout cas ce, n’est pas un dysfonctionnement sur jMQTT.

Bad

@Bad

C’est une usine à gaz ton système, si déjà tu as proxmox, pourquoi ne pas faire une VM à côté pour Jeedom ?

C’est ce que j’avais jusqu’à maintenant sur 1 de mes proxmox mais ca fait 2 VM à maintenir, des ressources gaspillées,… Entre temps, j’ai testé sur un autre Proxmox du Docker et du Nginx et ca se passait très bien.

Sur ce 3eme Proxmox, j’ai donc décidé d’installer 1 Proxmox et migrer ce que j’avais sur un vieux RPI (Debian 9, Jeedom 3), je me doutais qu’il y aurait du taf, cela ne m’a jamais empêché d’arriver à mes fins.

En terme d’usine à gaz, j’avais bien pire et cela fonctionnait puisque j’avais fini par valider le fonctionnement avec un routeur 4G et 1 Reverse Proxy sur un serveur distant avec Traefik, ce qui complique bien plus le fonctionnement et j’avais obtenu ce que je voulais.

Donc je ne voyais pas de raison de ne pas installer Jeedom sur la meme VM. J’ai l’habitude des défis

Je ne suis même pas sûr que Jeedom supporte encore nginx.

Alors là, c’est le coup de grace ! :slight_smile: Si le produit progresse dans la regression, je vais avoir du mal à convaincre et à me faire « l’avocat du diable ». Ca fait 10-15 ans que j’utilise Jeedom et que je vis très bien avec les contraintes (Debian 9 obligatoire jusqu’à peu, toujours Php7.4, je passe en Jeedom v4 et les plugins sont obsoletes, …), Le plugin Alexa qui ne fonctionne plus depuis des semaines sur mon autre Jeedom. J’ai toujours résolu ou trouvé un contournement. Mais là, ca fait un peu beaucoup quand même :frowning:

En tout cas ce n’est pas un dysfonctionnement sur jMQTT.

Je n’en suis pas sûr, on a focalisé l’échange sur Docker/Traefik alors que ca n’avait pas de sens puisque j’ai le problème en direct, j’ai juste eu « l’outrecuidance » de ne pas utiliser le port 80, et Apache2. Et maintenant je suis dans l’impasse, je ne peux plus relancer les démons parce que
image.

Donc si t’es d’accord pour mettre de côté le fait que j’utilise Docker/Traefik sur le meme serveur et que cela ne parasite en rien Jeedom, qui fonctionne sur un Nginx non dockerisé mais sur un port différent, on pourra essayer d’avancer.

Peut-etre qu’installer un Jeedom vierge et restaurer un backup 3.X avec les anciens plugins etait une erreur ? (je n’avais pas le choix, le Jeedom 3 était dans les choux après une MaJ)

Bah chaque système a ses contraintes.

Tu vas pas essayer d’installer MySQL sur un Arduino, ChatGPT dans une Ti89 ou mettre un moteur de 2cv dans une Lamborghini, à part pour le challenge technique, si ?

Jeedom 4.4 en diy, c’est Debian 11, Apache, MariaDB et des versions en Docker sont supportées.
Mais le système est conçu pour être super facile à maintenir quand on garde l’OS dans les clous. D’ailleurs, le système de backup ne permet pas de sauver tout l’OS, juste les données de Jeedom et fonctionne bien en partant du principe que l’OS respect les postulats de base.

Tu peux modifier le port du callback dans la source de jMQTT si tu le souhaites, mais tu auras certainement à le faire dans tous les autres plugins utilisant des callbacks.

Bad

Aucune issue possible, mon Jeedom est bloqué
image
Je vais recréer une VM et repartir d’une page blanche.
Merci pour vos retours.