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 
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é 
Je vois si je peux tester ce week-end (ca va dépendre de mes enfants en terme de temps dispo )
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.
Les échanges ci-dessus semblant plus localiser le souci côté rpi Jeedom, je viens de réinstaller complètement en fin de journée mon rpi3 de backup. J’ai remis stretch et Jeedom 4.0.61 (sans l’accès externe vu la nature de mon test).
J’ai ensuite installé un seul plugin sur ce Jeedom, celui du KLF, lancé les dépendances qui semblent ok (log klf200_dep.log (4,2 Ko) )
Ensuite j’ai tenté de lancer le démon après avoir renseigné l’IP du KLF et le mot de passe mais hélas pour moi je n’ai aucun changement par rapport à avant idem en tentant un reboot KLF
Je ne sais pas si je ferai mieux de resetter les données du KLF ou si je tente d’installer un OS buster (ce qui n’est pas trop logique puisque en stretch j’étais parvenu un temps à tout faire fonctionner).
J’ai dans mon esprit en tout cas éliminé une cause de corruption de disque puisque en réinstallant tout proprement et sans erreur je reste hélas ko
Je pense in fine :
- tenter avec buster sans modifier le KLF
- si ko remettre stretch et resetter le KLF
une fois que j’aurai fait tout cela je serai complètement à sec d’idée
c’est vraiment décevant surtout quand je sais ce que permet le KLF qaund il tourne avec Jeedom…ct top, faut juste pas tomber en ko car le dépannage est bien compliqué pour trouver ce qui cloche. Je finis même par me dire que la cause est peut-être là où je ne la cherche pas ie ni Jeedom ni KLF mais dans ce cas où se cache-t-elle ? Les essais de @slemeur me laisseraient quand mm penser que non. C pour cela que je pense au reset de données (car c’est à ce jour la seule nuance avec ce que je viens de faire)
Hello. In fine je viens de mettre Buster sur mon rpi3 de backup. Idem ensuite install uniquement du plugin KLF (puis des dépendances Ok klf200_dep_buster.log (3,7 Ko) ) puis reboot de mon KLF, et ensuite saisie de mon IP/passe, sauvegarde de cette config plugin => le démon tente de se lancer et … BINGO !
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
A noter aussi un autre élément perturbant : lors de l’établissement correct de la connexion KLF, la led est repassée de suite blanc fixe !.. Comme si la reconnexion Ok avait restauré un truc côté KLF.
Durant l’installation de buster et dans les dépendances, j’ai vu que j’étais passé cette fois comme @slemeur en python 3.7. Est-ce la l’explication ?
J’avoue que je n’en sais rien toujours est-il que la connexion semble s’être établie. Le scan m’a détecté mes ouvrants en 5s et j’ai repris la main dessus normalement (je viens de tester un seul ouvrant mais bon). Il me reste encore un peu de boulot maintenant car tous mes Jeelink sont morts et mon design aussi mais cela c’est juste un peu de temps, pas très compliqué.
@lunarok je ne sais pas du tout dire au dela de ma description initiale ce qui a déclenché le ko, en revanche il semble comme le suggérait @slemeur qu’il y ait peut-être un truc autour de la version de python puisque à matériel strictement identique j’étais en ko sur mon rpi3 stretch et ok en buster. Certes je ne m’explique pas avoir été ok un temps, sauf si cela tient jusqu’au reboot soit du jeedom soit du KLF. La LED clignotante reste aussi pour moi un signe d’anomalie potentielle (dans mon cas…!)
Bref je ferai qques tests quand même de bonne tenue après reboot soit du rpi soit du KLF, ce sera pour plus tard il commence à se faire tard
J’ai tenté l’installation du µPython 3.7 sur ma PROD.
Et, c’était prévisible, ça a cassé mon jeedom.
Du coup j’ai réinstallé ma Smart avec la dernière image officielle disponible.
Après avoir tout réinstallé et mis à jour la connexion au KLF est toujours KO.
Et avec les dernières images officielle, ma Smart est en Stretch alors que ma VM est en Buster.
C’est dommage de ne pas avoir les mêmes versions de disponible sur le site de Jeedom.
On en arrive donc au fait que le KLF ne serait plus compatible avec Jeedom sur base Stretch.
Est-il possible d’installer une version antérieur du plugin KLF et dans ce cas comment ?
Même si j’ai plutôt l’impression que le problème est dans le module SSL de Python.
Sinon, est-il possible de passer la Smart sur Buster et dans ce cas aussi comment ?
La lib utilisée est bien indiquée compatible python 3.5 (la version dispo en stretch)
Quand on installe buster on est de base en python 3.7
Par contre, il y a pas mal de soucis qui se produisent autour de python sur stretch mais sur des installs « existantes », comme si certains plugins se marchent dessus ou pète des sous couches python
Donc plus que « buster », la solution est peut être que vous testez un jeedom « propre » sur lequel il y a pas de sauvegarde et pas de plugins perturbants
Après pour info, stretch est bientot non supportée, donc quand on peut etre en buster c’est mieux
Hello.
- Concernant le test d’un Jeedom « propre » sous stretch avec le seul plugin KLF, je l’avais tenté en premier (cf KLF200 avec led clignotant blanc sans fin, démon plugin NOK erreur ssl_handshake_timeout - #21 par Ds5)
=> c le ko de reinstall stretch qui m’a fait tenter de réinstaller tout en buster.
Je ne m’explique pas avoir donc été ok un temps avant mon crash dans la même conf…
- Pour répondre à @slemeur lorsque sur mon rpi au départ j’ai restauré une sauvegarde contenant une version juste avant la dernière du plugin, j’étais toujours ko. Donc pas certain qu’une ancienne version de plugin soit ok.
Après c’est étonnant qu’on ne soit pas plus à constater un souci, à moins que je sois à la traine 
et que quasi tout le monde ait basculé de stretch à buster vu en effet le côté obsolète de la version. En revanche si c’est « facile » sous rpi, pour le moment sur Smart je ne sait pas faire. Dans mon cas, pas grave, ma Smart me sert d’aggrégateur de mes 3 rpi via Jeelink. Je peux donc revoir la partie automatismes ouvrants sans risquer de casser un autre domaine de mon install domotique (ct le but de l’éclatement de mon système mono smart en 4 Jeedom)
Et quant à la LED du KLF… Bizarre que de ton côté @lunarok ca reste ok avec le clignotement, je pensais vraiment que c’était un signe.
Bref dans mon cas je vois comment me solutionner (je dois juste vérifier que les qques plugins peu nombreux sur mon rpi « ouvrants » sont tous ok buster), la solution n’étant pas forcément la même pour @slemeur sauf à garder sa VM (avec jeelink pkoi pas) ou à ajouter un rpi comme moi ou réussir à basculer la Smart en buster (je ne maitrise pas la disponibilité d’une image officielle).
Salut,
Pour info, de mon côté je suis toujours sous Stretch (pas encore eu le temps de passer sous Buster) avec une version de Python 2.7.13 par défaut (la version 3.5.3 est aussi présente mais pas utilisée par défaut), dernière version du plugin KLF et pas de soucis de mon côté.
Bonjour @Ds5,
J’ai fait comme tu as dit avec la VM toujours active et lié à mon Jeedom principal via JeeLink.
Ca fonctionne très bien.
En attendant une évolution sur mon Jeedom de Prod (MAJ d’un plugin, de Jeedom ou mieux la disponibilité de Buster sur Smart).
Hésite pas à laisser un ticket au support pour Buster sur Smart.
Stretch n’est déjà plus supporté, sauf en LTS
https://wiki.debian.org/LTS
Cooool ! je suis bien content pour toi car j’avoue que je me trouvais pas très malin de t’avoir conseillé le KLF et que ca soit direct ko pour toi (sans parler que je me vantais d’etre 12 mois nikel pour etre planté qques jours après )
A noter que je compte refaire un petit post de solution pour que ce sujet soit proprement fermé, j’attendais aussi que tu mentionnes que tu avais ta solution même si temporaire (ou pas, Jeelink c’est quand mm top pour équilibrer un système multi domaine ou résoudre un cas précis comme ici sans craindre de tout casser le reste).
Me voila rassuré, désolé pour la mise en oeuvre laborieuse ; je pense toutefois que si pas déjà fait tu verras que le KLF répond quand même super bien à ce qu’on attend de lui, de même que le plugin.
Comme conseillé par @lunarok, il serait bon qu’on pose la question de buster sur Smart en effet. Moi qui venait enfin de me décider en avril à passer de jessie/v3 à stretch/v4, je pense que je vais devoir refaire bientôt
Sinon par inadvertance, j’ai débranché mon KLF durant plusieurs heures (pour mes tests je l’avais mis ailleurs et j’ai éteint toute une multiprise) et au rebranchement, je n’ai eu qu’à relancer mon démon KLF et c’était ok. Je confirme une nouvelle fois que dès que j’ai eu le retour du plugin connexion Ok, la led du KLF a stoppé de clignoter dans la minute (quand bien même je n’étais pas forcément encore sorti du mode access point). Bizarre ca
Merci en tout cas à tous ceux ayant bien participé à ce sujet, on se sent moins seul :
Pour résumer la solution mise en oeuvre au cours des échanges ci-dessus et grâce notamment aux tests de @slemeur en plus des miens :
- la résolution est passée par un Jeedom sous OS buster / python 3.7
(la réinstall complète en restant en stretch même en ne mettant que le plugin KLF a échoué)
Une fois fait, la reconnexion s’établie sans erreur ssl handshake / le clignotement de la LED est stoppé net
Si faisable sur rpi ou dans des VM, cela ne peut s’appliquer à date sur Smart car pas d’image buster officielle disponible
Je clos donc le sujet. Merci à tous ceux ayant aidé à résoudre et nous aiguiller vers une solution
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.