Je ne comprend pas. J’ai eu ce message d’erreur mais c’était parce que j’avais une version trop récente et non supportée par signalrcore chez moi, le fait de forcer la version de websocket-client à 0.54.0 avait résolu le problème.
Tu as les mêmes versions de modules que moi.
Ton log d’installation des dépendances est identique au mien.
Peux-tu me donner le résultat de la commande /var/www/html/plugins/EaseeCharger/resources/venv/bin/pip list
Je viens de supprimer mon environnement python puis de relancer l’installation des dépendances… je me retrouve avec le même message d’erreur que toi au lancement du daemon.
J’ai donc le même problème mais il était probablement caché par des résidus de tests précédents.
Je dois m’absenter et je ne sais pas si je vais pouvoir avancer ce soir. Je reviens ici dès que j’ai des nouvelles.
La liste des modules semble être la liste des modules installé globalement dans l’os. Le python du plugin ne tourne pas dans cet environnement mais dans une sorte de partition qui se trouve dans le répertoire /ressources/venv du plugin. Cette partition a ses propres modules et n’utilise pas les module de l’os.
J’ai l’impression que tu n’as pas lancé la commande /var/www/html/plugins/EaseeCharger/resources/venv/bin/pip listmais juste pip list
Mais laisse tomber, c’est juste de la théorie. Le plus important est que je pense avoir résolu le problème et que j’ai déployé une nouvelle version. Je te laisse tester.
En gros, je me suis fait avoir par cette remarque sur le site signalrcore · PyPI
J’avais donc forcé l’installation de la version 0.54.0 de websocket-client. Mais il semble que cette remarque n’est plus d’actualité et que cette version de websocket-client provoquait l’installation d’une vieille version de signalrcore.
Maintenant, je me contente de définir que signalrcore 0.9.5 doit être installé et les dépendances inter modules font le reste.
Gardes à l’esprit que les libs dans le venv restent. Donc si la version websocket 0.54 répond au requirements.txt de signalcore, pip n’installera pas une autre même si une plus récente existe.
Ce n’est peut-être pas un problème, je ne sais pas, je ne connais pas signalcore.
Je viens de faire la maj. J’ai relancé les dépendances aussi.
Là le démon a démarré, je surveille dans la journée ce que ça donne !
Merci
Edit: j’ai juste eu une erreur pendant la maj du plugin mais qui a été traitée avec l’installation des dépendances :
2024-11-12 09:09:12 EaseeCharger Aucun script ne correspond à votre type de Linux : /var/www/html/plugins/EaseeCharger/core/class/../../resources/install_#stype#.sh avec #stype# : apt Log EaseeCharger
Ce message vient très probablement du fait que la dernière version renomme le répertoire resources en ressources (en réalité l’un est supprimé et l’autre est créé).
Merci pour ton info.
Dans ce cas, j’ai échappé au piège car jai profité de cette mise à jour pour supprimer le répertoire resourceset en créer un nouveau nommé ressources. en conséquence, le répertoire venvdans resources a été supprimé et l’installation de dépendances en cré un tout beau tout neuf dans ressources.
J’ai coupé temporairement le plugin pour ne pas bloquer mon compte là bas mais j’ai l’impression que mon réseau est floodé par les appels. Y’a pas une tempo?
Le daemon ne fait pas de pull. On passe par du signalr. De ce que j’ai pu comprendre, une conection est établie par le deamon vers le cloud Ease puis le cloud utilise cette connection pour pousser les notifications. Il me semble aussi qu’il y a régulièrement des trames de « ping » pour vérifier que la connection est OK mais ces « ping » sont très léger.
Tu devrais voir dans log du daemon les notification reçues. Je ne sais plus si le niveau de log « info » est suffisant ou s’il faut passer en « debug » pour voir ces infos. Je n’ai pas accès à mon Jeedom pour le vérifier.
Chez moi, je reçois régulièrement des mise à jour de la tension de chacune des phases. Mais je ne pense pas qu’il y a surcharge du réseau. Sinon, mon PI B3 ne tiendrai probablement pas la charge.
J’ai l’historique du pourquoi des requetes dns en boucle :
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd70c57de50>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd6b0b3dca0>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd744160700>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd7443f14f0>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd70c57de20>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd7443f1130>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-13 07:56:59] ERROR : SignalRCoreClient HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate?id=AQrKnUv-g95RcXqOBFND5A (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7fd724509790>: Failed to resolve 'streams.easee.com' ([Errno -3] Temporary failure in name resolution)"))
[2024-11-15 21:55:54] ERROR : EaseeChargerd Fatal error: HTTPSConnectionPool(host='streams.easee.com', port=443): Max retries exceeded with url: /hubs/chargers/negotiate (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)')))
La dernière erreur est celle que j’ai en voulant redémarrer le service.
En insistant il est reparti et pas de nouvelle erreur dans les logs.
Étrange,
Les erreurs du 13 novembre semblent indiquer qu’il y avait un problème de résolution DNS. Ceci n’est certainement pas lié au plugin.
Pour l’erreur du 15 novembre, Je suppose qu’il y avait une info concernant le certificat SSL qui n’était pas d’actualité ou absente. Cette info a probablement été actualisée entre le moment de cette erreur et la vérification du certificat lors de la connection suivante. Le problème peut être lié à une config chez Easee ou aux modules Python qui participent à la connection.
Il me semble difficile d’investiguer plus. Je te propose donc, si tout fonctionne bien pour toi, d’ignorer ces problèmes. On pourra reprendre les choses plus à fond s’ils se reproduisent.
