2024-03-02 19:50:04]DEBUG : Starting new HTTP connection (1): 127.0.0.1:443
[2024-03-02 19:50:04]DEBUG : http://127.0.0.1:443 « GET /plugins/zigbee/core/php/jeeZigbee.php?apikey=cleAPI HTTP/1.1 » 400 362
[2024-03-02 19:50:04]ERROR : Fatal error : ‹ AttributeError › object has no attribute ‹ message ›
Bonsoir,
Pourquoi vouloir forcer le port réseau interne sur le 443 ?
TiTidom.
Ne connaissant pas le fonctionnement de jeedom, c’était au cas où il y avait une contrainte pour le port, l’interface web accédée en 443…
Pour moi le réseau n’est pas le problème, le pb de connection n’est qu’une conséquence du fait que le deamon est ko
Habituellement lorsque le pb survient débrancher et rebrancher la clé suffit, mais plus maintenant.
J’ai vérifié l’état des prises qui sont en état, par contre le module sonoff reste froid, il est tiede en fonctionnement normal
Le module serait ko ?
[2024-03-02 19:55:04]DEBUG : http://127.0.0.1:443 « GET /plugins/zigbee/core/php/jeeZigbee.php?apikey=u77xJghw8fhN9dAT2h1qFQ4bGUNCeW1RkGJBKBEmHvehtEBlU5Of8idP1mxVmZH2 HTTP/1.1 » 400 362
Je rêve ou le deamin essaye de se connecter à jeeZigbee ?
Il n’y aurait pas un pb de gestion de migration entre le vieux plugin zigbee et le nouveau ?
Je veux un truc qui fonctionne, l’ancien me conviendrait le temps de pouvoir préparer une migration tranquillement
Re,
Désolé, je n’ai pas précisé, mais je ne disais pas que le soucis venait forcément de ta configuration réseau, mais de manière plus général, cela ne va pas aider.
Je disais cela plus dans le sens : La config du réseau interne, il vaut clairement mieux le laisser en port 80. Passer sur le port « 443 » ne t’apportera que des problèmes, et ce n’est pas ca qui va sécuriser ton accès (le port 443 seul n’apporte rien en terme de sécurité, d’autant plus sur un accès via une ip).
Par contre sur la partie de la configuration réseau « externe », c’est là où il faut configurer la partie sécurité, soit par les DNS jeedom, soit de manière manuelle (à condition de maitriser cette partie là, notamment la partie certificat SSL).
Voilà pour ce petit « hors sujet », mais qui dans tous les cas aidera ton jeedom à mieux fonctionner 
Bonne soirée,
TiTidom.
Un possesseur de la même clé pourrait-il me dire si elle est reconnu sous ce nom « inHeng Electronics USB Single Serial » ?
via lsusb
le deamon semble vouloir accéder à jeedom en 443 mais sans https, apache étant configuré sur la machine pour être utilisable uniquement en https en 443
c’était déjà le cas avant je sais pas si ça à un impact sur le pb ?
comment vérifier que le dongle zigbee est toujours utilisable avant de me lancer dans une migration vers jeezigbee ?
6 minutes max pour faire le test et être fixé.
Désactivez la gestion automatique du démon, cliquez sur stop.
Installez le plugin-z2m (Jeezigbee)
→ https://market.jeedom.com/index.php?v=d&p=market_display&id=4351
Et pour avoir une idée, vous pouvez suivre ceci:
Mqtt manager ne démarre pas
Sun, 03 Mar 2024 15:21:42 GMT body-parser deprecated undefined extended: provide extended option at jeedom/jeedom.js:168:31
[2024-03-03 15:21:43]ERROR : Callback error.Please check your network configuration page : {"message":"Request failed with status code 400","name":"AxiosError","stack":"AxiosError: Request failed with status code 400
at settle (/var/www/html/plugins/mqtt2/resources/mqtt2d/node_modules/axios/dist/node/axios.cjs:1967:12)
at IncomingMessage.handleStreamEnd (/var/www/html/plugins/mqtt2/resources/mqtt2d/node_modules/axios/dist/node/axios.cjs:3066:11)
at IncomingMessage.emit (node:events:529:35)
at endReadableNT (node:internal/streams/readable:1400:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
at Axios.request (/var/www/html/plugins/mqtt2/resources/mqtt2d/node_modules/axios/dist/node/axios.cjs:3877:41)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)","config":{"transitional":{"silentJSONParsing":true,"forcedJSONParsing":true,"clarifyTimeoutError":false},"adapter":["xhr","http"],"transformRequest":[null],"transformResponse":[null],"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"maxBodyLength":-1,"env":{},"headers":{"Accept":"application/json, text/plain, */*","User-Agent":"axios/1.6.7","Accept-Encoding":"gzip, compress, deflate, br"},"method":"get","url":"http://127.0.0.1:443/plugins/mqtt2/core/php/jeeMqtt2.php?apikey=i8iwOqUmfPqaxKNd41WVC5FGMJOdSKjY6cuKS6kDJGkVmuNmirtaCpKdIxDcaDFd"},"code":"ERR_BAD_REQUEST","status":400}
Mais non ce n’est pas le réseau
Bon du coup quoi vérifier dans le réseau ?
De part le fonctionnement du plugin mqtt manager… le pb vient du reseau ou l’erreur reseau est juste une conséquence du fait que le deamon est ko et que du coup personne n’est là pour répondre à la requete ?
comment forcer l’acces interne jeedom en https ?
le pb est que mon serveur est en https mais jeedom essaye de faire une requette en http la meme requete en https effectuée à la main passe
j’ai besoin de rétablir temporairement mon zigbee, je ferai une config propre apres
c’est bien un pb reseau j’ai force jeedom en https et parametre du https en dur à la place de http dans le plugin zigbee et le deamon tourne et voit bien mes modules le controleur zigbee est ok
par contre toute les requete des scenarios et du dashboard au zigbee sont en http et n’aboutissent pas
comment les forcer en https ?
Y en a pour longtemps a chercher dans l’architecture de jeedom, franchement pour une solution réalisée par une équipe de développement on doit pouvoir faire mieux…
Pourquoi rendre jeedom aussi dépendant d’une architecture serveurs http/php ?
Je pense que le serveur http sur 9199 est un serveur implémenté en python et donc indépendant de la config interne jeedom, le pb venait que la config suite à maj jeedom a décapitée l’usage du https et l’appel du script zigbee en php ne pouvait plus se faire
Mais pourquoi rendre un système aussi dépendant d’un serveur web… ?
Pour l’interface web ok, mais le reste du système devrait fonctionner dans un environnement plus dédié et donc robuste à l’environnement de jeedom…
j’ai un warnig sur ssl qui pollue les logs, quelqu’un pourrait me dire où de la requete avec url3 est faite pour que je désactive le warning ?
Ou quelqu’un a t-il des connaissances sur jeedom pour faire un usage moins sauvage du https sans toucher à la config ssl http/https de mon serveur web ?
donc en fait il faudrait que j’autorise le http sur trafic local dans mon apache, comme ça jeedom aurait le champ libre pour faire du http
une objection ?
du coup c’est ce que je fais le deamon est stable par contre le reseau n’est toujours pas reconstitué après 24h c’est normal ?
le reseau est revenu, je pense que le process de maj vers jeedom 4.3.23 a bousillee la config reseau apache custom de ma machine