Daemon KO au lancement du WebSocket

Bonjour @Mips !

Après quelques recherches, et n’ayant pas trouvé de réponses fonctionnelles, je m’en remets à ce petit ticket concernant ma problématique.
J’ai installé hier le plugin « Gardena-Husqvarna » pour la première fois.

Voici le retour de l’installation des dépendances :

*****************************
Install modules using apt-get
*****************************
Reading package lists...
Building dependency tree...
Reading state information...
python3 is already the newest version (3.11.2-1+b1).
python3-requests is already the newest version (2.28.1+dfsg-1).
python3-pip is already the newest version (23.0.1+dfsg-1).
python3-setuptools is already the newest version (66.1.1-1).
python3-venv is already the newest version (3.11.2-1+b1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
*************************************
Creating python 3 virtual environment
*************************************
Done
*************************************
Install the required python libraries
*************************************
Requirement already satisfied: pip in ./venv/lib/python3.11/site-packages (23.2.1)
Requirement already satisfied: wheel in ./venv/lib/python3.11/site-packages (0.41.2)
Requirement already satisfied: requests>=2.20.0 in ./venv/lib/python3.11/site-packages (from -r requirements.txt (line 1)) (2.31.0)
Requirement already satisfied: oauthlib>=3.2.2 in ./venv/lib/python3.11/site-packages (from -r requirements.txt (line 2)) (3.2.2)
Requirement already satisfied: requests_oauthlib>=1.3.1 in ./venv/lib/python3.11/site-packages (from -r requirements.txt (line 3)) (1.3.1)
Requirement already satisfied: websocket-client~=1.6 in ./venv/lib/python3.11/site-packages (from -r requirements.txt (line 4)) (1.6.2)
Requirement already satisfied: charset-normalizer<4,>=2 in ./venv/lib/python3.11/site-packages (from requests>=2.20.0->-r requirements.txt (line 1)) (3.2.0)
Requirement already satisfied: idna<4,>=2.5 in ./venv/lib/python3.11/site-packages (from requests>=2.20.0->-r requirements.txt (line 1)) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in ./venv/lib/python3.11/site-packages (from requests>=2.20.0->-r requirements.txt (line 1)) (2.0.4)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.11/site-packages (from requests>=2.20.0->-r requirements.txt (line 1)) (2023.7.22)
***************************
*      Install ended      *
***************************

La configuration du plugin est réalisée conformément à la documentation (clé d’application & secret + API Gardena). Le port socket interne est laissé par défaut.

Au lancement du Daemon, plantage sous 2-3 secondes.
Les logs DEBUG sont les suivants :

INFO : Starting daemon
INFO : Log level: debug
DEBUG : Socket port: 55070
DEBUG : PID file: /tmp/jeedom/gardena/deamon.pid
DEBUG : Init request module v2.31.0
DEBUG : token content:
DEBUG : # access_token: *********...
DEBUG : # user_id: *********...

DEBUG : # expires_in: 86399
DEBUG : # expires_at: 1694174088.5484498
DEBUG : # token_type: Bearer
DEBUG : # provider: husqvarna
INFO : Authentication done
INFO : updating locations
DEBUG : opening websocket for location My Garden
ERROR : Exception while starting gardena websocket:Retry.__init__() got an unexpected keyword argument 'method_whitelist'
DEBUG : exception, restarting daemon...
DEBUG : Send to jeedom: {'daemon': 'start'}
DEBUG : ...and calling onFailure
INFO : Shuting down
DEBUG : Removing PID file /tmp/jeedom/gardena/deamon.pid
DEBUG : Exit 0

J’ai vérifié l’intégralité de mon système (machine physique), fait quelques mises à jour (notamment de modules python3).
Voici l’état des modules pip3 actuel :

android-backup==0.2.0
anyio==4.0.0
appdirs==1.4.4
attrs==23.1.0
blinker==1.6.2
bluepy==1.3.0
certifi==2023.7.22
cffi==1.15.1
chardet==5.2.0
charset-normalizer==3.2.0
click==8.1.7
colorama==0.4.6
construct==2.10.68
croniter==1.4.1
cryptography==41.0.3
cupshelpers==1.0
dbus-python==1.3.2
defusedxml==0.7.1
distro==1.8.0
dnspython==2.4.2
enum-compat==0.0.3
enum34==1.1.10
fail2ban==1.0.2
future==0.18.3
gpg==1.18.0
h11==0.14.0
h2==4.1.0
hpack==4.0.0
httpcore==0.17.3
httplib2==0.22.0
httpx==0.24.1
hyperframe==6.0.1
idna==3.4
ifaddr==0.2.0
iotop==0.6
lazr.restfulclient==0.14.5
lazr.uri==1.0.6
libevdev==0.11
Markdown==3.4.4
markdown-it-py==3.0.0
mdurl==0.1.2
micloud==0.6
netifaces==0.11.0
ntpsec==1.2.2
oauthlib==3.2.2
pycairo==1.20.1
pycparser==2.21
pycrypto==2.6.1
pycryptodome==3.18.0
pycups==2.0.1
pycurl==7.45.2
Pygments==2.16.1
PyGObject==3.42.2
pyinotify==0.9.6
PyJWT==2.8.0
pyOpenSSL==23.2.0
pyparsing==3.1.1
pyserial==3.5
PySimpleSOAP==1.16.2
pysmbc==1.0.23
python-apt==2.6.0
python-dateutil==2.8.2
python-debian==0.1.49
python-debianbts==4.0.1
python-miio==0.5.12
pytz==2023.3.post1
pyudev==0.24.1
PyYAML==6.0.1
reportbug==12.0.0
requests==2.31.0
requests-oauthlib==1.3.1
requests-toolbelt==1.0.0
rfc3986==2.0.0
rich==13.5.2
six==1.16.0
sniffio==1.3.0
systemd-python==235
tqdm==4.66.1
tzlocal==5.0.1
urllib3==2.0.4
wadllib==1.3.6
websocket-client==1.6.2
yeelight==0.7.13
zeroconf==0.99.0

Est-ce que le problème a déjà été abordé? Si oui, mes excuses, je ne l’ai pas trouvé (et je file RTFM).
Si non, une idée d’où ça peut provenir?

D’avance merci !

Salut,

Je peux voir la page santé jeedom & une capture de la page de config avec les infos de versions?
le log d’installation est étrange, il ne correspond pas à la dernière version stable :thinking:

tu es sous python 3.11:

  • soit c’est une debian12 => jeedom ne supporte pas encore debian12 (seulement 10 ou 11) et je n’ai pas encore vraiment testé => solution réinstaller debian 11
  • soit python3.11 a été installé par quelqu’un ou quelque chose d’autre => il faut réparer

ceci dit, l’erreur semble arriver avec urllib3 2.0.4; j’ai la version 2.0.2. Entre les deux c’est sensé être que du bugfix sans breaking change…

Merci pour ton retour rapide.

J’étais en D10 encore hier (et le problème de daemon était identique).
J’ai été pris d’une petite folie d’upgrade par contre en effet, et je suis passé à D11 hier soir et D12 ce matin (avant de vérifier la compatibilité Jeedom, surtout avec le passage à PHP 8.3). Bref, petit rollback PHP pour retourner en 7.4 et Jeedom refonctionne.

Ce serveur ne gère pas que Jeedom, et il dispose d’une carte Quadro (qui peut être parfois assez « embêtant » à réinstaller). Du coup, si je peux éviter une réinstallation :smiley:


Vu ton message sur le log d’installation, j’ai supprimé l’intégralité du plugin pour le réinstaller. Voici le nouveau log :

*****************************
Install modules using apt-get
*****************************
Reading package lists...
Building dependency tree...
Reading state information...
python3 is already the newest version (3.11.2-1+b1).
python3-requests is already the newest version (2.28.1+dfsg-1).
python3-pip is already the newest version (23.0.1+dfsg-1).
python3-setuptools is already the newest version (66.1.1-1).
python3-venv is already the newest version (3.11.2-1+b1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
*************************************
Creating python 3 virtual environment
*************************************
Done
*************************************
Install the required python libraries
*************************************
Requirement already satisfied: pip in ./venv/lib/python3.11/site-packages (23.0.1)
Collecting pip
Using cached pip-23.2.1-py3-none-any.whl (2.1 MB)
Collecting wheel
Using cached wheel-0.41.2-py3-none-any.whl (64 kB)
Installing collected packages: wheel, pip
Attempting uninstall: pip
Found existing installation: pip 23.0.1
Uninstalling pip-23.0.1:
Successfully uninstalled pip-23.0.1
Successfully installed pip-23.2.1 wheel-0.41.2
Collecting requests>=2.20.0 (from -r requirements.txt (line 1))
Obtaining dependency information for requests>=2.20.0 from https://files.pythonhosted.org/packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
Using cached requests-2.31.0-py3-none-any.whl.metadata (4.6 kB)
Collecting oauthlib>=3.2.2 (from -r requirements.txt (line 2))
Using cached oauthlib-3.2.2-py3-none-any.whl (151 kB)
Collecting requests_oauthlib>=1.3.1 (from -r requirements.txt (line 3))
Using cached requests_oauthlib-1.3.1-py2.py3-none-any.whl (23 kB)
Collecting websocket-client~=1.6 (from -r requirements.txt (line 4))
Obtaining dependency information for websocket-client~=1.6 from https://files.pythonhosted.org/packages/4b/4a/3176388095e5bae6e6a1fbee66c438809230ae0196e7de4af12c5e75c509/websocket_client-1.6.2-py3-none-any.whl.metadata
Using cached websocket_client-1.6.2-py3-none-any.whl.metadata (7.5 kB)
Collecting charset-normalizer<4,>=2 (from requests>=2.20.0->-r requirements.txt (line 1))
Obtaining dependency information for charset-normalizer<4,>=2 from https://files.pythonhosted.org/packages/bc/85/ef25d4ba14c7653c3020a1c6e1a7413e6791ef36a0ac177efa605fc2c737/charset_normalizer-3.2.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
Using cached charset_normalizer-3.2.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (31 kB)
Collecting idna<4,>=2.5 (from requests>=2.20.0->-r requirements.txt (line 1))
Using cached idna-3.4-py3-none-any.whl (61 kB)
Collecting urllib3<3,>=1.21.1 (from requests>=2.20.0->-r requirements.txt (line 1))
Obtaining dependency information for urllib3<3,>=1.21.1 from https://files.pythonhosted.org/packages/9b/81/62fd61001fa4b9d0df6e31d47ff49cfa9de4af03adecf339c7bc30656b37/urllib3-2.0.4-py3-none-any.whl.metadata
Using cached urllib3-2.0.4-py3-none-any.whl.metadata (6.6 kB)
Collecting certifi>=2017.4.17 (from requests>=2.20.0->-r requirements.txt (line 1))
Obtaining dependency information for certifi>=2017.4.17 from https://files.pythonhosted.org/packages/4c/dd/2234eab22353ffc7d94e8d13177aaa050113286e93e7b40eae01fbf7c3d9/certifi-2023.7.22-py3-none-any.whl.metadata
Using cached certifi-2023.7.22-py3-none-any.whl.metadata (2.2 kB)
Using cached requests-2.31.0-py3-none-any.whl (62 kB)
Using cached websocket_client-1.6.2-py3-none-any.whl (57 kB)
Using cached certifi-2023.7.22-py3-none-any.whl (158 kB)
Using cached charset_normalizer-3.2.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (199 kB)
Using cached urllib3-2.0.4-py3-none-any.whl (123 kB)
Installing collected packages: websocket-client, urllib3, oauthlib, idna, charset-normalizer, certifi, requests, requests_oauthlib
Successfully installed certifi-2023.7.22 charset-normalizer-3.2.0 idna-3.4 oauthlib-3.2.2 requests-2.31.0 requests_oauthlib-1.3.1 urllib3-2.0.4 websocket-client-1.6.2
***************************
*      Install ended      *
***************************

Ainsi que le log du Daemon qui semble inchangé :

0023|[2023-09-07 14:26:43]INFO : Starting daemon
0024|[2023-09-07 14:26:43]INFO : Log level: debug
0025|[2023-09-07 14:26:43]DEBUG : Socket port: 55070
0026|[2023-09-07 14:26:43]DEBUG : PID file: /tmp/jeedom/gardena/deamon.pid
0027|[2023-09-07 14:26:43]DEBUG : Init request module v2.31.0
0028|[2023-09-07 14:26:43]DEBUG : token content:
0029|[2023-09-07 14:26:43]DEBUG : # access_token: ***********...
0030|[2023-09-07 14:26:43]DEBUG : # user_id: **********..
0031|[2023-09-07 14:26:43]DEBUG : # scope: ['sg-integration-api:read', 'iam:read', 'sg-integration-api:write']
0032|[2023-09-07 14:26:43]DEBUG : # expires_in: 86399
0033|[2023-09-07 14:26:43]DEBUG : # expires_at: 1694176002.2225277
0034|[2023-09-07 14:26:43]DEBUG : # token_type: Bearer
0035|[2023-09-07 14:26:43]DEBUG : # provider: husqvarna
0036|[2023-09-07 14:26:43]INFO : Authentication done
0037|[2023-09-07 14:26:43]INFO : updating locations
0038|[2023-09-07 14:26:43]DEBUG : opening websocket for location My Garden
0039|[2023-09-07 14:26:43]ERROR : Exception while starting gardena websocket:Retry.__init__() got an unexpected keyword argument 'method_whitelist'
0040|[2023-09-07 14:26:43]DEBUG : exception, restarting daemon...
0041|[2023-09-07 14:26:43]DEBUG : Send to jeedom: {'daemon': 'start'}
0042|[2023-09-07 14:26:44]DEBUG : ...and calling onFailure
0043|[2023-09-07 14:26:44]INFO : Shuting down
0044|[2023-09-07 14:26:44]DEBUG : Removing PID file /tmp/jeedom/gardena/deamon.pid
0045|[2023-09-07 14:26:44]DEBUG : Exit 0

J’ai réinstallé la version précédente de URLLIB3, sans modifications côté Daemon

pip3 install urllib3==2.0.2

Pour la page santé :

Concernant la page config avec les infos de version, est-ce « Vérification des packages système » dont tu aurais besoin?

j’avoue que je suis perplexe…

mais

no (more) comment…


il faudrait idéalement rollback python en 3.9 (j’ignore comment exactement et si c’est possible)

ca ne sert à rien comme ca car le plugin utilise un venv
il faut toujours utiliser python3 présent dans le dossier resources/venv/bin du plugin;
donc en supposant que tu es dans le dossier du plugin, par exemple:

./resources/venv/bin/python3 -m pip install urllib3==2.0.2

essaye avec la version 2.02 ou avec la version 1.26.15 si ca marche toujours pas (et que cette version existe encore sur cette distrib debian/python)


non, de nouveau ca sert à rien ca puisque ca ne montre que les versions systèmes qui ne sont pas utilisées par le plugin, je parlais du haut de la page config du plugin tout simplement.

chaque ligne du log devrait commencer par la date/heure, hors tu n’as pas ca, c’est ca qui est étrange (mais sans rapport avec le problème)


pas de rapport avec le plugin mais je vois que tu as plugin-blea avec une antenne locale, je t’invite à lire les posts qui parlent des problèmes de blea (et bluepy) sous debian 11 (et donc probablement debian 12)

J’avoue que les MAJ n’étaient pas forcément bienvenues…
Ça me permets de me rappeler de faire des check sur les prérequis des applications hébergées par le serveur.

Pour la date/heure des logs : je l’ai volontairement retiré avec un regex pour que ça soit plus lisible sur le forum. (je la laisse sur les logs de ce message du coup)


Sans rollback de python (tout à fait faisable, il faut « juste » identifier la version à réinstaller pour le gestionnaire de paquets), j’ai suivi ton conseil pour la version d’urllib3 dans le dossier ressources/venv/bin du plugin.
Je l’ai mis en version 2.02 → problème identique.
Je l’ai ensuite mis en version 1.26.15 → problème corrigé.

Le daemon tourne depuis 14:59:27 sans plantages.

J’ai quand même eu une 403 sur l’API et quelques messages d’erreurs :

0094|[2023-09-07 14:57:48]INFO : Websocket connected
0095|[2023-09-07 14:57:48]ERROR : Exception while starting gardena websocket:403 Client Error: Forbidden for url: https://api.smart.gardena.dev/v1/websocket
...
0112|[2023-09-07 14:57:50]DEBUG : Signal 15 caught, exiting...
0113|[2023-09-07 14:57:50]INFO : Shuting down

---

0128|[2023-09-07 14:57:55]INFO : updating locations
0129|[2023-09-07 14:57:55]ERROR : 403:{'Message': 'User is not authorized to access this resource with an explicit deny'}
0130|[2023-09-07 14:57:55]ERROR : Fatal error: {'Message': 'User is not authorized to access this resource with an explicit deny'}
0131|[2023-09-07 14:57:55]INFO : Shuting down

---

0210|[2023-09-07 14:59:49]INFO : Websocket connected
0211|[2023-09-07 14:59:49]ERROR : Websocket error: 'NoneType' object has no attribute 'sock'

Je n’ai qu’un équipement pour le moment.
Je vais déjà tester ça :slight_smile:

En tout cas, merci pour l’assistance (malgré le contexte OS/Versions pas compliant).
Si tu veux que je fasse des tests en local du coup vu les versions, n’hésite pas. Si mes MAJ peuvent être utiles :confused:

oui tout à fait mais j’ignore si le paquet « python3.9 » est présent sur le repo « debian12 », c’est ca que je voulais dire; et si c’est pas le cas, on peut toujours le recompiler mais c’est encore un peu plus complexe; bref…


La 403 c’est une authorization sur les api pas correctement définie coté gardena/husqvarna. à priori ca va pas bien fonctionner derrière

  • soit tout est bon « en apparence » et c’est un problème sporadique qui disparait tout seul lors de l’appel suivant; il doit y avoir un petit soucis de leur coté mais on ne peut rien y faire et ce n’est pas très grave au pire on perd quelques minutes d’info => à priori c’est pas le cas ici
  • soit il faut supprimer et recréer l’application dans le portail husqvarna, ca c’est mal passé la première fois et ca ne se rétablira pas tout seul => c’est un robot husqvarna ou gardena? gardena je pense vu le log
  • soit tu as mal sélectionné les api coté husqvarna/cote jeedom, il faut alligner les deux et ne cocher l’api gardena / husqvarna que si tu as du matos gardena / husqvarna respectivement.

Je viens de vérifier, pas de paquet python3.9 sur les repos officiels Debian12 :slight_smile: : comme ça c’est réglé !


A priori tout est bon et c’était un problème temporaire : je n’ai qu’un Gardena Water Control et il fonctionne bien avec les commandes de ton plugin. Je vais surveiller dans tous les cas vérifier si le daemon plante à nouveau, et si c’est le cas a partir de quel motif.


Est-ce que tu voudra que je teste quelques petites choses depuis ma version « non compliant » pour les prochaines MAJ?
Si non, je pense qu’on peut clôturer (et merci pour l’aide apporté sur cette sollicitation non commune).

A priori non, merci

pas de soucis :+1:

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.