KLF200 avec led clignotant blanc sans fin, démon plugin NOK erreur ssl_handshake_timeout

Bonjour

Comme dit dans un autre fil de discussion Problème détection bandeau LED pergola, j’ouvre un sujet dédié au problème que je rencontre et pour lequel nous sommes au moins deux à rencontrer (@Theric).
Depuis maintenant presque une semaine, je ne parviens plus à connecter mon Jeedom à mon KLF200 qui pourtant fonctionnait à merveille depuis 1 an (plantage de l’ensemble quasi à la date anniversaire d’achat : Ko depuis le 26.09 et achat le 24.09.2019).
Si je résume :

  • suite à un redémarrage de mon rpi3 hébergeant mon Jeedom gérant mes ouvrants, je n’ai pas réussi à relancer le démon du plugin KLF
  • pour espérer y parvenir, j’ai comme dès fois redémarrer électriquement le KLF200 mais sans succès cette fois ci. Par ailleurs j’ai remarqué qu’au dela des 10mn ou 15mn usuelles post reboot et post hotspot actif sur le KLF, la led qui clignote blanc ne passe pas à blanc fixe mais continue à clignoter sans s’arreter (clignotement de l’ordre de 2 flash par seconde)
    Je précise que :
  • je ping tjs le KLF
  • un telnet sur le port du démon 51200 semble aussi répondre en me disant Connected (la ou un telnet sur un autre port me dit refused)
  • je n’ai pas changé de version du plugin, de jeedom ou de mon OS entre le moment du dernier fonctionnement ok et le ko (j’avais toutefois mis à jour le plugin KLF et relancé les dépendances 2 ou 3j avant le plantage)

l’erreur vu dans le log est la suivante :

[2020-09-30 22:13:47][INFO] : Début d'activation du plugin
[2020-09-30 22:13:48][INFO] : Info sur le démon : {"launchable_message":"","launchable":"nok","state":"nok","log":"nok","auto":0}
[2020-09-30 22:13:48][DEBUG] : Lancement de : /var/www/html/core/class/../../core/php/jeePlugin.php  plugin_id=klf200 function=install callInstallFunction=1
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'

si je résume un peu ma cinématique :

  • KLF en place depuis septembre 2019 pilotant 8 ouvrants Velux (4 fenetres et 4 volets roulants)
  • ajout en novembre ou décembre je ne sais plus exactement de mes 7 ouvrants Somfy IO (via une KLR200 puis recopie complète de la KLR sur le KLF après reset des données pour tout recopier)
  • fonctionnement sans défaut depuis
  • le 20.09 de mémoire, maj plugin KLF avec la dernière version (j’avais celle d’avant sans les commandes On Off de reboot électrique KLF) et après deux relances démon, fonctionnement ok
  • le 26.09 dans la nuit mon rpi3 se plante, il se relance de manière auto via mes scénarios de sup de mes rpi3 (il est supervisé par ma Smart via Jeelink) / après reboot rpi, détection de ko démon et la aussi tentative de relance du démon mais qui échoue et boucle infinie de relance
  • le 26.09 quand je me réveille, je tente de relancer le démon à la main et toujours ko / comme à la maj plugin j’avais eu qques soucis, je relance les dépendances (je crois voir une seulle install notée package « bottle », pas certain) puis relance et tjs ko :frowning:
  • je reboote alors le KLF et le démon reste ko. Je reboote une nouvelle fois mon KLF en voyant que la LED blanche clignote toujours et depuis la LED clignote sans s’arréter
  • je cherche si d’autres sont dans le cas et je tombe sur le sujet cité au début
  • j’ai aussi tenté de restaurer une sauvegarde de mon rpi3 avec l’ancienne version du plugin (restauration qui a fonctionné) => tjs Ko au niveau du démon, même erreur (bon si j’avais mis à jour des dépendances cela ne les avait pas enlevé). Je remets à jour le plugin mais tjs ko

J’ai fait une demande d’info en ligne auprès du SAV Velux lundi 28.09 en début d’après midi pour demander ce que signifie un état du KLF avec une led blanche qui clignote sans fin et un éventuel conseil de dépannage. Pas de réponse à ce jour

Si pas de réponse d’ici fin de semaine et sauf autre idée réçue, je ferai un reset de mes données de KLF et réimporterai mes équipements voire si tjs ko un reset usine du KLF.

A noter que KLF éteint, j’ai exactement la même erreur dans mes logs : en gros allumé ou éteint, le plugin me sort la même erreur ce qui me rassure moyen d’ailleurs sur le fait de n’avoir un souci que côté KLF.

Je suis sur rpi3B+ stretch, Jeedom 4.0.61 et plugin KLF dernière version (j’ai également essayé sur un autre rpi3B+ en Jeedom 4.1.14 stretch => idem)

Évidemment si certains sont tombés dans ce cas et s’en sont sortis, leur retour sera le bienvenu :slight_smile:

Bonjour,

@Ds5, suite a ton retour sur mon post sur la TAHOMA, j’ai investi dans le KLF.

Et pas de bol, je rencontre le même problème avec mon KLF que j’ai reçu le 29/09.
J’ai commencé par y mettre mes 6 ouvrants Velux (3 fenêtres et 3 volets).
Puis installé et configuré le plugin dans Jeedom sans succès.

Je suis en 4.0.61 sur Smart et les dépendances du plugin sont en succès.
Je précise que j’ai bien mis des nom sans espace et caractères spéciaux dans le KLF.
Et mon KLF a été livré en firmware 0.2.0.0.71.0.
Pour info, ce n’est pas mieux avec la version béta du plugin.

Vu que c’est une config toute neuve du KLF je peux le réinitialiser si besoin et reste disponible pour tout autre tests.

En complément d’information, la commande suivante lancé depuis la box Jeedom en SSH :
wget https://192.168.xx.xx:51200 --no-check-certificate

Donne le résultat suivant :
–2020-09-29 21:23:29-- https://192.168.xx.xx:51200/
Connecting to 192.168.xx.xx:51200… connected.
WARNING: The certificate of ‘192.168.xx.xx’ is not trusted.
WARNING: The certificate of ‘192.168.xx.xx’ hasn’t got a known issuer.
The certificate’s owner does not match hostname ‘192.168.xx.xx’
HTTP request sent, awaiting response…

Donc, le KLF répond bien depuis la box Jeedom.

Arf désolé à l’époque j’avais un système tournant sans souci depuis 1 an et tjs mieux selon moi versus les contraintes Tahoma (pour mon usage en tout cas) d’ou ma remarque sur l’autre sujet :frowning:

C’est étonnant quand même que nous soyons un certain nombre à tomber dedans en ce moment. Ca laisse l’impression que si on est dans un mode ou on doit relancer l’install/dépendances ou configurer une première install ça échoue en ce moment, là ou si le système tourne sans maj autre que le code du plugin ca passe… J’ai un vrai doute sur une maj de dépendances sous stretch que j’aurai faite le 19.09 lors de la maj plugin qui soit s’est mal passée soit a mis à niveau un élément en conflit avec un autre. Dans mon cas comme déjà dit j’ai la dernière version officielle de stretch qui date maintenant et sur laquelle je n’ai fait que des majs pour des dépendances de plugins, pas autre chose.

Du coup tout cela ne me rassure guère sur mes chances post reinit du KLF (que je tenterai sans doute ce week-end, avant pas trop le temps). J’aurai préféré constater que le démon ne répondait pas en fait :wink: La KLF éteint ou On, la réponse est la même comme si l’interrogation depuis le plugin ne part pas.

S’agissant d’une Smart j’imagine que tu es sous stretch ?
(mon cas aussi, je verrai si j’ai moyen de soit tenter une maj OS (mais bon pas certain que y’ait beaucoup de maj vu que maintenant c pas stretch le nominal) soit mettre buster sur un de mes rpi au cas où). Je ne sais pas trop ce que je pourrai lancer comme commande ou autre sous l’OS afin de vérifier que je n’aurai pas un conflit de ce type.

Autre question même si la je pense que ça ne doit pas être le cas : la led blanche de ton KLF reste-t-elle fixe après une 15aine de minutes ou bien même après 30mn elle continue à clignoter comme après le boot électrique ?
Je suis dans la même version de FW que toi et que tout le monde, yc ceux qui fonctionnent sans problème

Oui, je suis bien sur Stretch depuis un moment.

Et oui, la lumière de mon KLF n’arrête pas de clignoter même après 30mn.
En fait c’est le seul fonctionnement que j’ai pût voir puisque le plugin n’a pour le moment pas fonctionné.

Les dépendances ne se relancent pas sur mise a jour, il faut le forcer.
J’ai une dizaine d’échos d’install sans problème depuis la fin des vacances.
J’ai forcer l’install des d’EPS et pas de soucis.
La les blanche clignote

Hello.
Pour complément dans mes manips :

  • le 19.09 avant plantage donc, j’avais mis à niveau le plugin, tenté la relance démon qui de mémoire avait échoué et relancé les dépendances. Le log des dépendances m’indiquait bien installation terminée (pas vu d’erreur dans le logs). Après cela j’avais relancé le démon et cela avait fonctionné me semble t il à la seconde relance
    compliqué de le garantir car quand ca fonctionne on ne va pas tout vérifier :slight_smile: la led de mon KLF était blanc fixe
  • c’est dans la nuit du 26.09 que l’ensemble a dysfonctionné : le rpi3 a rebooté et le démon ne s’est pas relancé Ok. Le matin après relance du démon 2 fois (et en ayant vu les nombreuses relances en ko après le reboot) je me suis dit que mieux valait que je reboot le KLF
  • et depuis c’est ko et la led clignote sur le boitier sans discontinuer

Donc pour moi mon système était à iso plugin et dépendances lors du ko, je n’avais pas fait de maj à ce moment la mais quelques jours plus tôt. Du coup je ne sais pas si je dois encore relancer les dépendances car déjà fait (même si le plugin me marque une date de dernière relance erronée (a priori)).

Et in fine j’ai fait partie qques jours de ceux qui après maj sont restés ok…

Je ne suis pas certain de comprendre « La les blanche clignote » => tu veux dire que ton KLF qui est opérationnel clignote toi aussi en permanence ?

(c’est nouveau la led quand mm, je vais finir par croire qu’il y a eu une maj du boitier (après boot, donc tant qu’on reboote pas ben pas de maj) et que tout le monde ne l’a pas eu pour ceux dont la led reste fixe :slight_smile: et que cette maj a cassé un truc… mais si des KLF clignotant fonctionnent… :slight_smile: )

edit: au cas où j’ai relancé les dépendances du plugin, le log est ici : klf200_dep.log (3,7 Ko) / sur mon rpi3 en 4.1 ca reste ko pour le démon après avoir rebooté le KLF

Pour info, lorsque je les avais contacté en début d’année, j’avais reçu un message automatique de prise en compte de ma demande dans la journée et ils avaient ensuite mis une grosse semaine (9 jours) avant de me répondre.

Oui ma les clignote, je ne saurais te dire depuis quand.
Avec ton message j’ai pris l’escabeau pour aller voir le klf qui est au dessus du rack et effectivement il clignote, alors que j’ai pas souvenir qu’il faisait ça avant

J’ai toujours le problème a près une réinitialisation aux paramètre d’origine.
Sans ajout d’ouvrants.
J’ai juste activé le WiFi en permanent.

Houla l’idée n’était pas de se mettre en danger sur un escabeau juste pour une LED :slight_smile:
C’est curieux ce changement de comportement à iso Firmware (enfin je pense car la version semble tjs la même depuis belle lurette). Comme si après un reboot le KLF avait changé de mode de fonctionnement de la LED… pour un équipement qui tourne en local c bizarre. Ca expliquerait aussi que certains voient clignoter d’autres pas. Pour ma part tant que je ne l’avais pas rebooté (et ca faisait pas mal de temps, en gros depuis une coupure EDF lors d’un orage il ya plusieurs semaines), la led était fixe.
Et comme tt le monde ne reboote pas en mm temps.

je verrai si semaine prochaine j’ai des news/infos de Velux (@arnog23 vu pour le délai de réponse)

Bon bref fausse piste pour moi alors côté KLF a priori :frowning:

ce que semble aussi confirmer @slemeur puisque une réinit ne change visiblement pas son constat.

Pour ma part je me suis listé ceci comme test même si vu nos échanges j’ai un peu peur de ne pas m’en sortir car rien ne parait en défaut que ca soit KLF ou plugin :

  • commencer par vérifier que je suis tjs ko après reboot rpi, reboot KLF, et relance démon

  • si ko, agir en premier sur le KLF :

    • refaire la config : effacer toutes les données puis recopier le KLR200 et tester
    • si ko reinit usine du KLF puis reparamétrer le DHCP, recopier le KLR200 et tester
  • si manips KLF ko :

    • sur mon rpi3 bkp :
      1. réinstaller pi OS stretch + Jeedom + plugin KLF uniquement et tester
      2. installer pi OS buster + Jeedom + plugin KLF uniquement et tester

l’idée étant d’éliminer une cause OS…

Et sinon, si je reprends mon cas, je me demande si au fur et à mesure des reboots de Jeedom et/ou KLF d’autres qui étaient ok ne vont pas devenir ko avec un prb n’intervenant qu’après des redémarrages. Si quelqu’un a déjà rebooté en étant en dernière version plugin et avec un KLF blanc fixe a un retour je suis preneur.

Bigre suis pas convaincu de m’en sortir vite là contrairement à d’habitude ou on cerne assez vite et à plusieurs un prb commun.

Question vraiment bete mais l’erreur du log ne nous apprend rien j’imagine sur une plus probable cause à creuser ? histoire ensuite d’aller vérifier dans des logs OS ou autres commandes le point semblant défaillant ?

J’ai bien fait une réinit d’usine sur le KLF.
Je ne pense donc pas qu’il soit en cause.

@Ds5, le DHCP était sélectionné par défaut après la réinit.

Je verrais ce WE si je peux tester sur mon Synology un Docker de Jeedom clean.
Ca fait longtemps que je n’ai pas joué avec.

ok vu pour DHCP. Du coup je ne me souviens plus trop de la nuance entre effacer les données et reinit usine (a moins que ca ne me remette le FW usine mais j’en doute). Bref je vais essayer de tester ce week-end en espérant avoir assez de temps.
Si ce n’est pas coté KLF j’ai assez peu d’idée en vrai la… Pour mon cas perso en tout cas la source du passage en ko se situe entre le reboot de mon rpi et/ou le reboot de mon KLF puisqu’avant à iso version tout était ok

Si tu as raspberry en rab, tu peux essayer d’installer home assistant et l’intégration velux « pour voir ». Si ça passe comme ça, le souci est plus probablement côté jeedom, si ça ne passe pas le souci est plus probablement côté KLF. C’est sans doute un peu lourd à faire, mais, quand on est coincé, faut passer aux solutions extrêmes :slight_smile:

C’est la même lib utilise

Certes mais si c’est l’install sur jeedom qui est vérolée d’une manière ou d’une autre, ca permet d’être (à peu près) sûr du côté (jeedom ou klf) qui serait la source du problème.

Hello merci pour ces idées de debug. Je dispose de mon rpi3 « bancal » mais qui tourne quand mm a priori correctement sur tout le reste et d’un autre rpi que je comptais utiliser en le reformattant pour d’ailleurs à terme qu’il remplace le premier qui plante trop souvent et du départ avait des ports USB qui semblaient moins bons que mes deux autres, pourtant strictement identiques et équipé d’un même disque mSATA et du même boitier.

Je regarde ce que c’est que Home Assistant je ne connais pas. Mes Rpi sont en aveugles, en OS lite donc que ssh (pas d’écran ou clavier). Même si mes automatisqmes ouvrants me manquent, ca reste utilisable au quotidien donc j’essaie de prendre un peu de temps pour piger. Qui plus est ca peut servir à d’autres. Car si je réinstalle tout et que c’est ok, niveau capitalisation sur le bug ou capacité à aider @slemeur par ex ce sera limité :frowning:

Je vois si je peux tester ce week-end (ca va dépendre de mes enfants en terme de temps dispo :slight_smile: )

edi : Hassistant étant une image à claquer sur une SD ou un disque (à la place de mon Jeedom), je ne ferai pt etre cela qu’à la fin si je débloque un de mes deux rpi3. Sauf si évidemment en débloquant un je débloque l’autre

Bon pas des masses de temps de dispo. Ce soir non plus… Toutefois j’ai juste fait un truc dans la config plugin : au lieu de laisser la bonne IP locale du KLF, j’en ai volontairement mis une mauvaise (type 192.168.1.99)

Cela donne alors exactement le même résultat qu’avec l’IP correcte. Je me dis donc que l’erreur me semble plutôt côté de mon Jeedom global (OS, Jeedom, plugin etc) car de ce que je vois ici le KLF n’est pas contacté, l’erreur arrive avant non ?

Finalement j’ai fait le test sur la VM Jeedom dans VirtualBox.
Et après quelques déboires, ça fonctionne dans cette VM.
Et il y a toujours le même problème sur mon Jeedom de prod.

Je problème est donc côté Jeedom et non côté KLF.
Et maintenant la LED du KLF est fixe.

Je précise qu’il faut au moins un périphérique configuré dans le KLF pour que la connexion se fasse.
Ce n’est pas une bonne idée de réinitialiser le KLF car après il faut réinitialiser tous les périphériques.

Est-ce que le plugin sur ton jeedom prod est tjs actif en même temps que l’autre ok dans la VM ?

Et ca rejoins ce que je mettais sur la partie en défaut localisée plus côté Jeedom global. A un moment je me disais que tant que j’aurai un jeedom actif sur le KLF et ko ca le ferait pt etre planter donc généralement je désactive les plugins avant de tester un truc.

Reste aussi de ce que tu dis que la LED redevient fixe ce qui me laisse aussi perplexe à iso FW du KLF : pour certains ca clignote ko (mon cas), pour d’autres ca clignote mais ca reste ok (ou alors après un reboot ca va planter comme moi) et pour d’autres c’est fixe et ok (comme moi durant 12 mois !)

Autre question : quand tu dis la réinit KLF nécessite de réinitialiser tous les périphérqiues, tu parles d’aller agir directement sur les ouvrants IO (ie les volets et leur Télécommande) ou au niveau des équipemnts dans Jeedom ? (la dernière fois que j’avais voulu recopier ma KLR j’avis juste fait effacer les données et pas le reset usine ce qui avait suffit sans aucune manip sur mes ouvrants heureusement)

Oui, j’ai laissé le plugin actif dans mes 2 Jeedom.
Il s’agit de la réinitialisation sur les moteurs d’ouverture et de volet dans mon cas.
Mais je n’ai que des télécommandes KLL300 alors que toi tu as une KLR200.

Dans la VM le module Python3 est en 3.7.3-1
Sur ma Prod le module Python3 est en 3.5.3-1

Est toi aussi tu semble être en Python3 3.5 d’après ton log.

Il faudrait donc tester le passage vers le Python3 3.7
Mais je ne suis pas encore assez caller pour le faire sans aide.