Démon KLF200 NOK erreur create_connection() ssl_handshake_timeout

Bonjour, installé cet après midi, dépendances OK, mais le démon reste NOK
dans le slogs je vois « create_connection() got an unexpected keyword argument ‹ ssl_handshake_timeout › »
(je suis sur SMART, version strech)

klf200.txt (3,6 Ko)

voici les logs :

[2020-10-28 17:10:19][INFO] : Arrêt du service klf200
[2020-10-28 17:10:19][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py <ip> <password ssid>
[2020-10-28 17:10:19][ERROR] : KLF200 has been restarted after found not responding
Connecting to KLF 200.
Traceback (most recent call last):
  File "/var/www/html/plugins/klf200/resources/klf200d.py", line 233, in <module>
    LOOP.run_until_complete(init_pyvlx_connection(LOOP))
  File "/usr/lib/python3.5/asyncio/base_events.py", line 466, in run_until_complete
    return future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/var/www/html/plugins/klf200/resources/klf200d.py", line 22, in init_pyvlx_connection
    await pyvlx.load_nodes()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/pyvlx.py", line 92, in load_nodes
    await self.nodes.load(node_id)
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/nodes.py", line 70, in load
    await self._load_all_nodes()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/nodes.py", line 86, in _load_all_nodes
    await get_all_nodes_information.do_api_call()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/api_event.py", line 21, in do_api_call
    await self.send_frame()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/api_event.py", line 33, in send_frame
    await self.pyvlx.send_frame(self.request_frame())
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/pyvlx.py", line 82, in send_frame
    await self.connect()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/pyvlx.py", line 46, in connect
    await self.connection.connect()
  File "/usr/local/lib/python3.5/dist-packages/pyvlx/connection.py", line 91, in connect
    ssl_handshake_timeout=5,
TypeError: create_connection() got an unexpected keyword argument 'ssl_handshake_timeout'

EDIT : vu l’autre sujet klf200-avec-led-clignotant-blanc-sans-fin-demon-plugin-nok-erreur-ssl-handshake-timeout qui explique qu’il faut passer en BUSTER pour que le plugin fonctionne, et sur SMART ce n’est pas encore possible ?

Bonjour
J’allais justement renvoyer vers le sujet que j’avais ouvert.
Il n’y a pas de version officielle Smart en buster à ma connaissance pour le moment. Il y a peut-être une facon de forcer la maj mais hors garantie et à mon avis pas trop conseillée (ca peut casser d’autres choses meme si ca rétablit le KLF).
Le mieux en attendant une image buster (qu’on devrait peut-être demander côté support Jeedom SAS) est plutôt de faire comme moi et l’autre personne dans le sujet ci-dessus, à savoir utiliser l’excellent plugin JeedomLink via install du KLF sur un autre Jeedom sous buster (via un rpi comme moi supportant buster, j’en ai installé un autre la récemment ou bien via un NAS proposant Docker ou tout autre solution)

Pas vu d’autres solutions. A noter que dans l’ancien sujet quelqu’un indiquait etre quand mm ok sur Smart stretch avec le KLF mais en utilisant une ancienne version de python, donc voir avec lui si sa config est reportable ailleurs.

Désolé pas mieux :frowning:

1 « J'aime »

oui dans ce message : ici

un certain @arnog23

Oui c’est bien ça.

je lui ai écris un MP. si j’ai compris il utilise une version plus ancienne de Python.
questions :
est-ce c’est possible de le faire juste pour ce plugin ?
quand pourra-t-on faire pour les smart l’upgrade en buster ?

bonjour

même souci que vous ; vous avez des news sur un possible upgrade des smart en buster ?

Bonjour,

Tu veux dire depuis hier? (date à laquelle Ds5 a posté son message) :wink:

Donc non, pas de changement depuis hier, et aucune info officielle à ce sujet.

oups

désolé @Mips, j’avais pas fait attention aux dates tellement j’étais deg que ça ne fonctionne pas.

vous avez une procédure pour monter un PI sous buster en attedant update pour Smart ? ça me permettrait d’utiliser ma klf200 qui a date me sert à rien

merci d’avance !!!

Regarde la documentation officielle et les images pré-installées sur https://images.jeedom.com

Bonsoir,

Comme indiqué dans mon post auquel tu fais référence, je n’ai rien fait de particulier pour que cela fonctionne. J’ai juste indiqué que cela fonctionnait pour moi. En revanche, en relisant les messages, la différence que je vois est que je ne suis pas sur la même plateforme hardware que vous. Je suis sur un NUC avec une VM Debian 9 (sur ESXi) et non sur RPI ou Smart. Donc pas les mêmes versions d’OS.

Hello
A force d’installer des rpi3 (j’en ai 3 dans ma « prod » en plus de ma Smart et un autre en spare si défaut d’un des 3 ou truc à tester hors prod) j’ai fait mon tuto complet qui utilise diverses sources. Je peux te le mettre ici ca devrait te donner les diverses étapes que je juges requises pour installer et optimiser ton rpi3 jeedom.

Voici donc ce que j’ai noté (pour un rpi3b+ avec un disque mSATA au lieu d’une carte SD) :

  1. installer le matériel : rpi dans sa boite, alim sans la brancher, cable réseau
  2. depuis un PC :
  1. démarrer le rpi uniquement avec la carte SD puis réaliser les manipulations pour autoriser le boot USB et éteindre le rpi puis retirer la carte microSD
    (voir les manips dans le lien ci-dessus)

  2. brancher le disque SSD sur un port USB et démarrer le rpi, puis vérifier via ssh qu’on parvient bien à démarrer sur le disque

  3. (si clé ZWave sur le rpi sinon sauter l’étape)
    éteindre le rpi puis brancher la clé ZWave si requise et redémarrer vérifier que le rpi démarre via connexion ssh (clé sur /dev/ttyACM0 ?) si pb de boot après branchement de la clé, booter sans la clé puis brancher la clé « à chaud »

  4. installer Jeedom (voir la doc très bien faite https://doc.jeedom.com/fr_FR/installation/rpi et utiliser la commande de lancement d’install du type " wget -O- …"

pour info exemple de durée d'install chez moi (env 15mn en tout)
- étape 1 21h15 "étape maj OS"
- étape 2 21h18 "étape paquet principal"
- étape 3 21h24 "étape BDD"
- étape 4 21h25 "étape Apache"
- étape 5 21h26 "étape php"
- étape 6 21h29 "étape téléchargement de jeedom"
- étape 7 21h29 "étape personnalisation de jeedom"
- étape 8/9 21h30 "étape configuration de jeedom"/ "étape installation de jeedom"
- étape 10 21h30 "étape post jeedom"
- étape 11 21h30 "étape vérification de jeedom"
 -> fin 21h30)

puis se connecter sur Jeedom via navigateur (admin/admin). Créer le mot de passe admin, l’accès Market. Nommer l’instance de Jeedom via Système/configuration puis redémarrer le système (demandé en fin d’install script jeedom) puis créer un utilisateur Administrateur différent de admin
Se connecter avec le nouveau compte et désactiver le compte défaut « admin » (évite de garder des comptes « défaut »)

  1. une fois Jeedom testé et les comptes créés, en ssh aller modifier le passe « pi » défaut (raspberry)
    pour éviter de conserver des login défaut surtout avant d’ouvrir à l’extérieur (ssh puis passwd)
    en profiter pour régler la locale Time via « sudo raspi-config » ( « 4 Localisation Options ». Ensuite, « I2 Change Timezone ». Puis vous choisissez « Europe » puis « Paris »)

  2. activer la connexion https :

  • avant manip vérifier que https://IPJeedom refuse la connexion
  • effectuer les manipulations décrites ci-dessous une fois sous /etc/apache2 (précéder les commandes de « sudo »)
root@jeedom:/etc/apache2# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  service apache2 restart
root@jeedom:/etc/apache2# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  service apache2 reload
root@jeedom:/etc/apache2# service apache2 reload
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
  • vérifier ensuite que le https répond cette fois
  1. pour l’accès distant (si besoin, si Telegram etc…), si possession Smart, il suffit d’activer le DNS Jeedom dans Système/Configuration/réseau (installer avant ou de mémoire c’est proposé le plugin OpenVpn) et le cas échéant dans la partie Market utilisez le bouton Tester pour forcer la maj des box connues du Market
    Dans un navigateur, aller sur le market et se connecter : aller dans MesBox pour vérifier les instances Jeedom connues et regarder l’état de connectivité.

Une fois l’accès distant ok avec le nom par défaut :
La personnalisation du nom DNS s’effectue dans MesServices
La maj des DNS prend plusieurs minutes (5 ? 10 ?)
Le statut est visible dans le market voire dans la partie Système/Configuration/réseau

  1. en plus à la fin on peut revoir le swap sur des rpi3 comme dit dans des posts du forum jeedom :
sudo nano /etc/dphys-swapfile

Changer la valeur
CONF_SWAPSIZE=100
En :
CONF_SWAPSIZE=1024

Ensuite arrêt propre du Swap
sudo /etc/init.d/dphys-swapfile stop

Et redémarrage
sudo /etc/init.d/dphys-swapfile start

Vérification :
free -m

puis pour le swapiness :
cat /proc/sys/vm/swappiness
Ça donne 60, valeur par défaut (swapp quand il reste moins de 40% de ram. donc sur un PI 3 swapp dès que 600 mo de ram sont utilisées)

Pour modifier le swap
sudo nano /etc/sysctl.conf

ajouter :
vm.swappiness = 10
donc swap quand il reste 10 % de ram

Ensuite un
sudo halt
/ débrancher / rebrancher.
  1. On peut aussi économiser de la CPU et de la température en évitant au rpi de tester en permanence s’il dispose d’une microSD
Demander au Raspberry Pi de ne pas rechercher en permanence une carte MicroSD et ainsi arrêter le clignotement de la LED « ACT »
sudo nano /boot/config.txt

Aller à la fin du fichier et ajouter les 2 lignes suivantes :

# Désactivation de la recherche permanente d'une carte MicroSD (et arrêt de la LED)
dtoverlay=sdtweak,poll_once

Ctrl + o pour sauver
Ctrl + x pour quitter
  1. et enfin on peut suivre la préco d’allocation mémoire pour un rpi sans écran comme mentionné dans la documentation Jeedom
(issu de la doc Jeedom en ligne)
sudo nano /boot/config.txt

Ajoutez et/ou De-commentez (en supprimant le #) et/ou Modifiez les lignes :
gpu_mem=16
disable_l2cache=0
gpu_freq=250

Quittez en sauvegardant : CTRL+X puis Y puis ENTER
Rebootez votre Raspberry Pi

Voila avec tout cela tu dois avoir un rpi parfaitement opérationnel et optimisé, sécurisé au minimum requis et accessible depuis l’extérieur.

Si je simplifie, le KLF ne fonctionne pas sur la STRECH alors qu’elle a la bonne version de PYTHON, et le fait de passer en BUSTER fait que cela fonctionne. or sur la SMART, on n’ a pas d’image d’upgrade en BUSTER, donc coincé.
Je me demande pourquoi le plugin KLF est le seul dans ce cas… a moins qu’il utilise une fonction que les autres plugin n’utilisent pas ? @lunarok ?
Je suis deg aussi et j’hesite à retourner mon KLF (200€)… a moins qu’une date officielle de sortie de l’upgrade buster sur Smart arrive avant la fin de l’année ?
j’invoque le grand maitre,… @Loic ?

Bonjour,
Comme vous le savez on ne JAMAIS de date chez jeedom car si on y arrive pas on fait des decu.

Donc oui il y a un projet sur une nouvelle image buster, après quand ca arrivera je peux pas dire ca peut etre dans 1 semaine comme 1 an.

le plan B d’attente reste ce que je suggérais dans mes autres posts et sujets : investir en gros 70€ dans un rpi3b+ (tjs en vente et suffisant versus rpi4 selon moi) et le mettre en buster puis relier ce rpi3 a la smart en jeelink (excellent plugin !).

Cela permet aussi d’équilibrer votre système sur 2 machines pour ne pas etre monobloc et tout casser lors d’une manip sur une machine. Perso j’ai ma smart en maitre et 3 rpi qui gèrent chacun un sous domaine. Dans le cas de mes ouvrants par ex j’étais bien content de ne devoir casser que la gestion des ouvrants pour résoudre mon souci plutôt que de tout mettre à risque. Et à terme quand je vais basculer mes autres rpi en buster je ne prendrai de risque de coupure que sur 1/3 de mon install à la fois

Après certes c’est un peu de temps et d’argent (en plus du KLF) mais cela permet d’équilibrer le système en charge/risques et le cas échéant ici d’avoir au cas ou une machine buster si autre plugin nécessitant la version dans les semaines à venir.

Bon ce n’est que mon avis suggestion, je peux comprendre que ca soit un peu « lourd » versus une maj de plugin…et ca reste de l’argent à sortir :slight_smile:

1 « J'aime »

@Ds5 je suis d’accord avec toi sur le fond.
Je suis dans l’informatique, et j’ai du mal à accepter « il y a un bug, et pour le résoudre on monte une autre machine où cela fonctionne ». surtout qu’il est probable que d’autres plugin rencontre le même soucis.
je ne dis pas que le bug est dans le plugin :wink: mais @lunarok : n’est il pas possible de debugger pour comprendre ce qui cloche ? je suis prêt à t’aider.
Merci.

pyvlx a été mis à jour en 0.2.17 avec le paramètre « ssl_handshake_timeout » qui semble poser problème.
Mis à jour chez moi, en buster, pas de soucis ca démarre quand meme.

Néanmoins, avant j’étais en 0.2.16 et il n’y avait pas ce paramètre. Apparemment en 0.2.18 ca devrait être supprimé vu le code. Mais le build ne passe pas.

Bref si vous avez le problème vous pouvez essayer :


sudo pip3 install 'pyvlx==0.2.16'

je parlais bien d’un plan B. Sachant que dans mon cas le plan B allait m’intéresser sur d’autres aspects de répartition et d’archi éclatée dans mon système monolithique qui avec le temps gérait trop de choses

et sinon, dans mon contexte pro aussi je rappelle que contournement ne vaut pas correction :wink:

Ayant récupéré une Smart (Recovery fraichement fait Stretch 9.4 / Mise à jour en 4.0.61 et seulement le plugin KLF200 installé en plus des plugins installés par défaut sur la Smart), je viens de faire le test.

Voici ce que cela donne :

# sudo pip3 install 'pyvlx=0.2.16'
Invalid requirement: 'pyvlx=0.2.16'
= is not a valid operator. Did you mean == ?

En remplacant avec le double == comme suggéré :

sudo pip3 install 'pyvlx==0.2.16'
Collecting pyvlx==0.2.16
  Downloading https://files.pythonhosted.org/packages/d4/52/94a3b7ee75057128a444bd7abe1b1b8733e60fbd68972ead679432a72e48/pyvlx-0.2.16.tar.gz
Requirement already satisfied: PyYAML in /usr/local/lib/python3.5/dist-packages (from pyvlx==0.2.16)
Building wheels for collected packages: pyvlx
  Running setup.py bdist_wheel for pyvlx ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-8h6unz6l/pyvlx/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmph72gqmbdpip-wheel- --python-tag cp35:
  /usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'long_description_content_type'
    warnings.warn(msg)
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help
  
  error: invalid command 'bdist_wheel'
  
  ----------------------------------------
  Failed building wheel for pyvlx
  Running setup.py clean for pyvlx
Failed to build pyvlx
Installing collected packages: pyvlx
  Found existing installation: pyvlx 0.2.17
    Uninstalling pyvlx-0.2.17:
      Successfully uninstalled pyvlx-0.2.17
  Running setup.py install for pyvlx ... done
Successfully installed pyvlx-0.2.16

Il y a une erreur mais l’installation se fait quand même.

Le KLF est maintenant trouvé et la connexion se fait mais il y a ensuite une autre erreur « Unable enable house status monitor. »:

[2020-10-30 16:03:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:03:03][DEBUG] : Result
[2020-10-30 16:03:43][INFO] : Arrêt du service klf200
[2020-10-30 16:03:43][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py 192.168.0.118 PASSWORD
[2020-10-30 16:03:43][ERROR] : KLF200 has been restarted after found not responding
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
Traceback (most recent call last):
File "/var/www/html/plugins/klf200/resources/klf200d.py", line 233, in <module>
LOOP.run_until_complete(init_pyvlx_connection(LOOP))
File "/usr/lib/python3.5/asyncio/base_events.py", line 466, in run_until_complete
return future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "/var/www/html/plugins/klf200/resources/klf200d.py", line 22, in init_pyvlx_connection
await pyvlx.load_nodes()
File "/usr/local/lib/python3.5/dist-packages/pyvlx/pyvlx.py", line 85, in load_nodes
await self.nodes.load(node_id)
File "/usr/local/lib/python3.5/dist-packages/pyvlx/nodes.py", line 70, in load
await self._load_all_nodes()
File "/usr/local/lib/python3.5/dist-packages/pyvlx/nodes.py", line 86, in _load_all_nodes
await get_all_nodes_information.do_api_call()
File "/usr/local/lib/python3.5/dist-packages/pyvlx/api_event.py", line 21, in do_api_call
await self.send_frame()
File "/usr/local/lib/python3.5/dist-packages/pyvlx/api_event.py", line 33, in send_frame
await self.pyvlx.send_frame(self.request_frame())
File "/usr/local/lib/python3.5/dist-packages/pyvlx/pyvlx.py", line 75, in send_frame
await house_status_monitor_enable(pyvlx=self)
File "/usr/local/lib/python3.5/dist-packages/pyvlx/house_status_monitor.py", line 57, in house_status_monitor_enable
raise PyVLXException("Unable enable house status monitor.")
pyvlx.exception.PyVLXException: <PyVLXException description="Unable enable house status monitor." />

En revanche, après un redémarrage forcé du KLF, cela semble bon maintenant :

[2020-10-30 16:04:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:04:03][DEBUG] : Result
[2020-10-30 16:04:43][INFO] : Arrêt du service klf200
[2020-10-30 16:04:43][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py 192.168.0.118 PASSWORD
[2020-10-30 16:04:43][ERROR] : KLF200 has been restarted after found not responding
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
[2020-10-30 16:05:03][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:05:03][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:06:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:06:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:07:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:07:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:08:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:08:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:09:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:09:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:10:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:10:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:11:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:11:02][DEBUG] : Result {"result": "ok", "devices": []}
[2020-10-30 16:12:02][DEBUG] : Send http://localhost:9123/devices
[2020-10-30 16:12:02][DEBUG] : Result {"result": "ok", "devices": []}

Et le Démon tourne bien :

Cela fonctionne aussi pour moi
Merci à tous.

Voilà qui pourrait être utile à @slemeur s’il veut laisser tomber son docker