KLF200 ne repond plus aux commandes

Tags: #<Tag:0x00007f3854c49af8>

Bonjour @Lunarok,

Je fais suite au message de @ds5 ici car mon KLF est aussi parfois capricieux.

Ci dessous les logs et le détail de ce qu’il s’est passé ce matin.

  1. Première Demande d’ouverture => KO
  2. Deuxième Demande d’ouverture => KO
  3. Redémarrage du daemon => OK mais la connection avec le KLF ne semble pas s’établir
  4. Troisième Demande d’ouverture => KO
  5. Redémarrage électrique du KLF
  6. Quatrième Demande d’ouverture => KO
  7. Redémarrage du daemon => OK
  8. Cinquième Demande d’ouverture =| OK

Je précise que le KLF était bien toujours joignable au niveau réseau.

[2020-01-25 09:34:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:34:17][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:34:17][DEBUG] : Update ChambreVolet at 99%
################################################### Première Demande d'ouverture ###################################################
[2020-01-25 09:34:31][DEBUG] : Action /set/0/0
[2020-01-25 09:34:31][DEBUG] : Send http://localhost:9123/set/0/0
Connecting to KLF 200.
Connecting to KLF 200.
Connecting to KLF 200.
[2020-01-25 09:34:56][DEBUG] : Result
[2020-01-25 09:35:18][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:35:18][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:35:18][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:36:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:36:17][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:36:17][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:37:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:37:17][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:37:17][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:38:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:38:17][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:38:17][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:39:16][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:39:16][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:39:16][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:40:18][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:40:18][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:40:18][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:41:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:41:17][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:41:17][DEBUG] : Update ChambreVolet at 99%
################################################### Deuxième Demande d'ouverture ###################################################
[2020-01-25 09:41:29][DEBUG] : Action /set/0/0
[2020-01-25 09:41:29][DEBUG] : Send http://localhost:9123/set/0/0
Connecting to KLF 200.
Connecting to KLF 200.
Connecting to KLF 200.
[2020-01-25 09:41:54][DEBUG] : Result
[2020-01-25 09:42:16][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:42:16][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
[2020-01-25 09:42:16][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:42:40][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:42:40][DEBUG] : Result {"devices": [{"type": "RollerShutter", "name": "ChambreVolet", "id": 0, "position": 99}], "result": "ok"}
################################################### Redémarrage du daemon ###################################################
======== Running on http://localhost:9123 ========
(Press CTRL+C to quit)
[2020-01-25 09:42:40][INFO] : Arrêt du service klf200
Task exception was never retrieved
future: <Task finished coro=<Heartbeat.loop() done, defined at /usr/local/lib/python3.5/dist-packages/pyvlx/heartbeat.py:37> exception=PyVLXException('Unable to send get state.',)>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "/usr/local/lib/python3.5/dist-packages/pyvlx/heartbeat.py", line 45, in loop
await self.pulse()
File "/usr/local/lib/python3.5/dist-packages/pyvlx/heartbeat.py", line 64, in pulse
raise PyVLXException("Unable to send get state.")
pyvlx.exception.PyVLXException: <PyVLXException description="Unable to send get state." />
[2020-01-25 09:42:41][INFO] : Arrêt du service klf200
[2020-01-25 09:42:41][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py 192.168.0.200 pqc4aKnpSf
Connecting to KLF 200.
[2020-01-25 09:43:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:43:18][DEBUG] : Result
################################################### Troisième Demande d'ouverture ###################################################
[2020-01-25 09:43:23][DEBUG] : Action /set/0/0
[2020-01-25 09:43:23][DEBUG] : Send http://localhost:9123/set/0/0
[2020-01-25 09:43:24][DEBUG] : Result
Connecting to KLF 200.
[2020-01-25 09:44:18][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:44:19][DEBUG] : Result
[2020-01-25 09:45:18][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:45:19][DEBUG] : Result
################################################### Redémarrage électrique du KLF et quatrième Demande d'ouverture ###################################################
[2020-01-25 09:45:21][DEBUG] : Action /set/0/0
[2020-01-25 09:45:21][DEBUG] : Send http://localhost:9123/set/0/0
[2020-01-25 09:45:22][DEBUG] : Result
[2020-01-25 09:45:58][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:45:58][INFO] : Arrêt du service klf200
[2020-01-25 09:45:59][DEBUG] : Result
################################################### Redémarrage du daemon ###################################################
[2020-01-25 09:46:00][INFO] : Arrêt du service klf200
[2020-01-25 09:46:00][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py ##IP_KLF## ##Password_KLF##
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
[2020-01-25 09:46:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:46:17][DEBUG] : Result {"result": "ok", "devices": [{"name": "ChambreVolet", "id": 0, "type": "RollerShutter"}]}
[2020-01-25 09:46:17][DEBUG] : Update ChambreVolet at %
################################################### Cinquième Demande d'ouverture ###################################################
[2020-01-25 09:47:12][DEBUG] : Action /set/0/0
[2020-01-25 09:47:12][DEBUG] : Send http://localhost:9123/set/0/0
[2020-01-25 09:47:12][DEBUG] : Result {"result": "ok", "position": "UNKNOWN", "device": 0}
[2020-01-25 09:47:16][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:47:16][DEBUG] : Result {"result": "ok", "devices": [{"name": "ChambreVolet", "id": 0, "position": 99, "type": "RollerShutter"}]}
[2020-01-25 09:47:16][DEBUG] : Update ChambreVolet at 99%
[2020-01-25 09:48:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-25 09:48:17][DEBUG] : Result {"result": "ok", "devices": [{"name": "ChambreVolet", "id": 0, "position": 0, "type": "RollerShutter"}]}
[2020-01-25 09:48:17][DEBUG] : Update ChambreVolet at 0%

Je viens de voir qu’il y avait une mise à jour de disponible qui date du 16/01, je vais donc la faire de ce pas.

Celle ci détecte elle les erreurs de connexions dans le démon pour pouvoir agir en automatique dessus comme tu l’as évoqué dans les échanges avec @ds5 ?

Néanmoins, comme tu l’as évoqué, le redémarrage du daemon seul ne semble pas suffire. Il a fallu que je le redémarre électriquement puis redémarrer le daemon pour que cela fonctionne.

Y a t-il moyen de voir de plus prêt (en collectant des logs sur le KLF) ce qui ce passe côté KLF car le soucis semble venir du boitier ?

En attendant, y aurait-il moyen de détecter le problème afin d’éxécuter un scenario qui redémarrerait électriquement le KLF puis le daemon ? Le KLF étant toujours joignable au niveau réseau, on ne peut pas s’appuyer la dessus pour lancer le scenario …

Sinon, je vais planifié ce reboot et redémarrage du daemon de façon régulière mais bon …

Merci

Citation
En attendant, y aurait-il moyen de détecter le problème afin d’éxécuter un scenario qui redémarrerait électriquement le KLF puis le daemon ? Le KLF étant toujours joignable au niveau réseau, on ne peut pas s’appuyer la dessus pour lancer le scenario …

Bonjour
Pour ma part lorsque j’avais un souci comme celui décrit dans le sujet que j’avais créé, je voyais à chaque fois dans le log du plugin KLF (en mode normal, pas besoin du mode debug) le terme “Failed to connect to localhost port 9123: Connection refused”. Dans les logs ci-dessus, je ne suis pas certain que ca soit le même symptôme. Ce que j’ai fait de mon côté c’est alors ceci :

  • mise du KLF sur une prise pilotée (un shelly plug S acheté exprès, car pas trop cher et suffisant)
  • création d’un scénario qui examine le log du plugin KLF et recherche si le terme ci-dessus est présent
  • si oui envoi d’un Telegram

Vu que depuis que j’ai codé cette détection je ne suis plus tombé dans un cas de ko :slight_smile: je n’ai pas cherché à automatiser la relance… en me disant que je ne le ferai que si c’était trop souvent. Pour le Off/On de la prise c’est facile à programmer, pour la relance du démon soit il faut passer par un bloc de code qui utilisera des commandes de manipulation directe des plugins (exemple ici https://forum.jeedom.com/viewtopic.php?t=43663) soit dans mon cas vu que le KLF est sur un jeedom relié à mon jeedom principal, pour éviter un code, je peux utiliser les commandes natives de contrôle du plugin Jeelink permettant d’agir sur tout démon d’un Jeedom lié une fois que par exemple mon Jeedom secondaire positionne la détection de ko à 1 et que le scénario sur mon Jeedom principal se déclenche sur passage à 1 de cette détection.

Tu n’as plus le cas ? Car perso j’ai un peu le même retour :slight_smile:

J’étais sur Shelly plug, et depuis que jiai mis a propre le rack avec le smart pdu … Plus rien, plus eu besoin de redémarrer le klf j’ai plus de plantage.
En gros depuis un mois, plus de soucis. Je me demandais si le klf se met tout seul a jour en firmware

Au cas où et je ne prétends pas avoir fait le meilleur code ou scénario de la planète :slight_smile: :

scénario : “KLF200 ctl connexion ok”
programmation : 7 * * * * (ttes les heures mais à 7 de chaque heure pour éviter le cronhourly et le cron5)

scenarioKLF

note : ne pas tenir compte du bloc Action vide dans la capture, c’est une mauvaise manip pendant la capture écran et la ligne est inutile et absente de mon scénario :slight_smile:

Hello. En effet pas eu de nouveau plantage avéré avec ce log “connection refused”. J’avais du posté cela vers mi décembre et depuis pas revu. Je ne sais pas dire si le KLF a changé de version de FW, je n’ai pas noté la version à l’époque. Pas souvenir dans l’IHM KLF d’avoir vu un truc de maj auto.

Dans mes manips/changement à moi depuis mon post de décembre :

  • sur le KLF j’ai ajouté la prise pilotée (me suis trompé d’ailleurs j’ai mis un Wallplug Fibaro pour etre tjs ok même avec le Wifi off dans la maison + éviter un souci de portée Wifi car le KLF est au second étage et la box au rdc). La Shelly est partie remplacer le wallplug Fibaro du rdc :slight_smile: J’ai quand mm rebooté une fois le KLF début janvier pour intégrer mes volets Somfy en plus des Velux et tout gérer sur le KLF en local.
  • Sur le jeedom associé, je n’ai pas fait de manip particulière hormis les maj plugin KLF et ai juste déplacer le rpi3 concerné sur une autre prise de courant car je pense qu’il a une alim sensible qui parfois le faisait planter (le disque mSATA se mettait à clignoter sans s’arreter et le jeedom était ko, obligation de reboot). Depuis cette manip il est plus stable. Est-ce que un plantage avant aurait altéré un truc avec le KLF… j’en doute

Bref je ne sais pas mais tant mieux car le KLF est stable pour le moment. Dans le log je vois “Software version 0.2.0.0.71.0, hardware 6”. Si c’est la version du KLF je ne pense pas avoir changé depuis ma première installation mais bon

Bonjour,

En effet, je n’ai pas le message “Failed to connect to localhost port 9123: Connection refused” dans mes logs.

Dans mon cas,quand cela ne fonctionne pas, j’ai juste le message “Connecting to KLF 200”, alors que lorsque cela fonctionne, j’ai ce même message “Connecting to KLF 200” mais suivi du message “Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14”.

Je n’ai pas pensé à faire un netstat au moment ou j’ai eu le problème pour voir si la connection TCP était toujours établie.

En revanche, j’ai testé la chose suivante aujourd’hui :

J’ai fait un netstat (plusieurs fois de suite) pour vérifier l’état de la connexion => Aucune connexion établie
J’ai demandé la fermeture du volet et je vois bien une connection TCP qui s’établie établie entre Jeedom et le KLF sur le port 51200.

root@jeedom:~# netstat | grep ##ip_KLF##
tcp        0      0 ##IP_Jeedom##:36750     ##ip_KLF##:51200     ESTABLISHED

Et cette connexion disparaît au bout d’un certain temps. Il faudrait que je vérifie le temps exacte.

Peut être que je n’ai pas bien compris comment fonctionne le plugin mais d’après ce que je peux voir, le daemon du plugin tourne en local sur le port 9123 “Send http://localhost:9123/devices” puis une connexion est faite sur le port 51200 vers le KLF qui est en écoute sur ce port. Est-ce bien cela ?

Du coup, je me demande comment la vérification du statut du volet toutes les minutes fonctionne ?

On voit dans les logs toutes les minutes un refresh du statut :

[2020-01-26 20:25:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-26 20:25:17][DEBUG] : Result {"result": "ok", "devices": [{"type": "RollerShutter", "id": 0, "position": 99, "name": "ChambreVolet"}]}
[2020-01-26 20:25:17][DEBUG] : Update ChambreVolet at 99%

Mais comment cela est -il possible si la connexion vers le KLF200 n’est pas établie ?

Du coup, j’ai testé en envoyant une commande directement depuis la télécommande et le statut n’est pas remonté vers Jeedom. Mais bon, le test n’est peut être pas valide comme la commande est envoyée directement au Kux sans passer par le KLF200, ca peut paraître normal.

Je vais me baser sur ton bloc code pour essayer de détecter le message “Connecting to KLF 200” non suivi du message “Connecting to KLF 200” mais suivi du message “Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14” et pour le redémarrage du daemon, je le ferai avec Jeelink.

Tu peux utiliser Jeelink en local sur ton Jeedom “Master”. Du coup, tu peux gérer tout les daemon directement via des commandes.

Je suis tombé sur ce post ou l’auteur de PyVLX indique que le KLF ne peut gérer que 2 connexions maximum et qu’au bout d’un certains nombre de tentative, les connexions ne sont plus possibles à cause du Handshake SSL qui tombe en timeout. Peut être que nous tombons sur ce ce cas. @Lunarok, un avis ?

Velux KLF200 interface connection issues

Concernant les mises à jour du firmware, je ne vois rien non plus pour le faire en automatique dans l’interface du KLF. D’après la version de mes logs, je dois être en 3.14 et la release notes donne ceci :

KLF_ReleaseNotes

Hello
Si le symptome de KO parfois ressemble à ce que j’avais (et que la je n’ai pas revu depuis mi décembre), il faut bien noter la facon de s’en sortir : d’abord reboot KLF puis relance demon. Dans la premier post, les étapes 3 et 4 KO sont du coup dans mon expérience “normales” car faites avant reboot KLF puis relance démon.
Autre point, et je m’étais d’ailleurs posé cette question au départ, mais une action sur n’importe quelle commande Velux modifie l’état du volet que le KLF récupèrera et que le plugin sera aussi en mesure de récupérer (au bémol de la minute avant maj ce qui reste très court et un maxi vu qu’on actionne pas toujours le volet pile aux minutes pleines :slight_smile: ). Donc l’envoi d’une commande depuis une télécommande doit être visible depuis le plugin.

Au final ca tombe en ko souvent ou c’est une fois toutes les semaines ? 2 semaines ? plus ?
Et sinon oui en effet on peut “automatiser” une relance KLF + démon.

PS: Vu la remarque sur le jeelink sur lui même, merci. Je reste toutefois sur une action depuis mon Jeedom principal et non le Jeedom “volets” car le principal voit tous les équipements (dont prises pilotées) mais pas le jeedom “volets” (mes prises ainsi que d’autres équipements “énergie” sont gérés par un 3è Jeedom, j’ai éclaté en 3 Jeedom mes équipements + un 4è principal qui assure le controle et visu de tout)

Reste qyue je ne réponds pas à ton prb de fond :slight_smile: sur pourquoi le KLF semble ko par moment, et que le symptome reste différent du mien. Désolé

Hello,

J’ai de nouveau eu le cas ce matin

[2020-01-29 09:47:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-29 09:47:17][DEBUG] : Result {"result": "ok", "devices": [{"type": "RollerShutter", "id": 0, "position": 99, "name": "ChambreVolet"}]}
[2020-01-29 09:47:17][DEBUG] : Update ChambreVolet at 99%
[2020-01-29 09:47:49][DEBUG] : Action /set/0/0
[2020-01-29 09:47:49][DEBUG] : Send http://localhost:9123/set/0/0
Connecting to KLF 200.
Connecting to KLF 200.
Connecting to KLF 200.
[2020-01-29 09:48:14][DEBUG] : Result
[2020-01-29 09:48:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-29 09:48:17][DEBUG] : Result {"result": "ok", "devices": [{"type": "RollerShutter", "id": 0, "position": 99, "name": "ChambreVolet"}]}
[2020-01-29 09:48:17][DEBUG] : Update ChambreVolet at 99%

Cette fois ci, j’ai regardé rapidement et il y avait 3 connexions dont 2 en “TIME_WAIT”

root@jeedom:~# netstat | grep 192.168.0.200
tcp        0      0 192.168.0.130:49412     192.168.0.200:51200     TIME_WAIT
tcp        0      0 192.168.0.130:49948     192.168.0.200:51200     ESTABLISHED
tcp        0      0 192.168.0.130:49644     192.168.0.200:51200     TIME_WAIT

Cette fois-ci, j’ai “juste” redémarrer le KLF (sans redémarrer le Daemon) et c’est reparti.

[2020-01-29 10:07:37][DEBUG] : Action /set/0/0
[2020-01-29 10:07:37][DEBUG] : Send http://localhost:9123/set/0/0
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
[2020-01-29 10:07:42][DEBUG] : Result {"result": "ok", "device": 0, "position": "99 %"}
[2020-01-29 10:08:17][DEBUG] : Send http://localhost:9123/devices
[2020-01-29 10:08:17][DEBUG] : Result {"result": "ok", "devices": [{"type": "RollerShutter", "id": 0, "position": 99, "name": "ChambreVolet"}]}
[2020-01-29 10:08:17][DEBUG] : Update ChambreVolet at 99%
root@jeedom:~# netstat | grep 192.168.0.200
tcp        0      0 192.168.0.130:60302     192.168.0.200:51200     ESTABLISHED

Il semblerait que je ne sois pas le seul a avoir ce genre de soucis : https://community.home-assistant.io/t/velux-component-for-klf-200-doesnt-support-the-new-api-with-firmware-2-0-0-71/75641/83

J’ai l’impression que le KLF ne ferme pas correctement certaines de ces connexions …

C’est bizarre car nous avons je pense tous la même version… Personnellement j’ai aussi fait un reinit du klf afin de plus facilement inclure mes Somfy. C’est peu être ce qui aurait pu aidé à stabiliser la klf qui depuis semble stable… À noter que le reinit klf sur laquelle j’avais 8 ouvrants velux n’a pas nécessité de refaire les équipements dans jeedom, juste ajouté les Somfy ! Maintenant comme déjà dit, je n’étais pas tombé sur le même symptôme exactement. A voir quand même si le reinit aiderait. Ça reste très expérimental ma suggestion sans théorie derrière démontrant l’intérêt…

Même si je n’y crois pas trop, j’ai changé le câble et je l’ai connecté sur un autre switch.

Si cela se reproduit trop souvent, j’envisagerai en effet de lui faire un reset.

Je suis retourné regarder les docs du KLF sur le site velux https://www.velux.com/api/klf200 et je n’avais pas vu qu’il proposait des scripts de demo https://velcdn.azureedge.net/~/media/com/api/klf200/demo.zip

Dans leur readme, ils indiquent qu’il faut utiliser la version 3.7 de python.

De mon côté, je suis en V4 sur Stretch avec un python en version 3.5.3

@Ds5 sur quel version de Jeedom, d’OS et python tournes-tu ?

@lunarok, y a t-il une version minimal pour Python pour le plugin ?

Bonjour
J’utilise un Jeedom v4 sur un rpi3 pour piloter la partie ouvrants de ma solution domotique. Il est relié via Jeelink à ma Smart (en v3 elle). Le plugin est sur le rpi3 sous stretch et en v4 (dernière version stable). Il ne tourne pas de ttes manière en jessie le plugin (oui je sais il est grand temps que j’upgrade ma smart :slight_smile: mais pour cela j’ai tout éclaté en 4 Jeedom pour ne pas planter quoi que ce soir durant la migration Smart).

Donc ça donne :

  • rpi3 sous stretch (version du 8.04.2019) : Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux [9.11]
  • php 7.0.33-0+deb9u5 (d’après la page santé Jeedom)
  • python 2.7.13… python3 3.5.3 (en faisant pyhton --version sous putty)
  • Jeedom v4.0.38

Voilou

Bonjour,

Merci pour ces infos.

Du coup, il semble que l’on ait la même version de python3. Ca ne doit donc pas venir de là. Je continue à chercher …

A coté de çà, j’ai reconfiguré le KLF pour que le Wifi soit toujours actif. La prochaine fois que la connexion filaire plantera, je verrais si je peux toujours le joindre en Wifi histoire de voir s’il est complètement planté ou pas et voir ce qu’il dit dans les logs mais ils n’ont pas l’air très fournis (et pas moyen de changer le niveau de log …) ou alors peut être via l’API … il faut que je regarde.

Cela fait maintenant 10 jours que le Wifi est resté activé sur le KLF et je n’ai pas rencontré de nouveau le soucis. A voir ce que cela donne sur la durée car j’aimerais bien pouvoir coupé le wifi dessus …

@Ds5, le Wifi est resté activé sur le tiens ?

Bonjour. Je n’ai touché ni au SSID ni à un paramétrage afin que le hotspot du klf soit différent de la config usine. Vu que je ne vois pas le SSID klf et que la Led blanche est fixe contrairement au mode hotspot klf pdt qques minutes post reboot je dois donc toujours être en wifi klf off. En revanche j’ai expérimenté un ko hier de mes commandes sans erreur de connexion et erreur dans les longs donc indetectable :confused: OK après reboot klf et relance démon plugin mais mon scénario d’auto dépannage n’a pas pu résoudre le cas car pas d’erreur dans le log (mode défaut ou debug). Pas top cela faisait longtemps que tout fonctionnait sans défaut. Pas trop noté et j’avais peu de temps mais en gros après connecting to klf je n’avais pas connecté to klf bla bla. Et ensuite des résult vide ttes les minutes

Bonsoir,

Bon, pas de bol, cela s’est reproduit hier après 19 jours sans soucis.

Le Wifi étant resté actif, j’ai pu me connecter sur le KLF par ce biais malheureusement les logs sont toujours aussi pauvre sur le KLF, rien de ce côté là. En revanche, cela m’a permis de faire quelques tests supplémentaires (mais qui malheureusement n’ont rien donnés).

Le premier déjà, c’est que que j’ai pu me connecter dessus via le Wifi, le KLF n’est donc pas complètement “planté”. J’ai également pu un faire un test de commande directement depuis le KLF et le volet est bien réactif.

J’ai tenté de désactiver/activer l’interface LAN du KLF mais cela n’a pas résolu mon problème.

J’ai également tenté d’établir la connexion depuis un Jeedom de test pour m’assurer que cela ne venait pas de mon Jeedom de prod et même problème, la connexion ne s’établie plus.

J’avais quand même ouvert un ticket chez Velux mais je m’attendais à leur réponse : “Pas de support sur l’API” comme indiqué sur leur site. Néanmoins, ils sembleraient quand même qu’ils essaient de mettre à disposition des scripts qui permettrait de faire un premier niveau de diagnostic. A voir si cela arrive ou pas.

Un truc que je n’ai pas encore essayé serait peut être de faire un reset usine du KLF. Sinon, le revendeur me propose de me l’échanger pour écarter un problème matériel.

A suivre.

Salut,

Cela s’est encore produit 2/3 fois en début de semaine.

Du coup, j’ai tenté un reset du KLF et cette fois-ci je n’ai pas ré associé mon volet SML de la même façon que la première fois.

La première fois, j’avais suivi ce qui était indiqué dans le manuel en utilisant le bouton Reset du KLF et le faisceau de fils.

Cette fois, je l’ai fait à partir de l’interface Web du KLF.

Pour le moment, RAS depuis mercredi matin. A suivre …

Concernant les échanges avec le fabriquant, ils ne m’ont pas laissé tombé pour le moment :

Des tests sont toujours en cours pour vous répondre.
Nous reviendrons vers vous dès que possible avec plus d'éléments.

Je leur ai aussi notamment demandé s’il était possible d’élever le niveau de log du KLF pour le passer en mode « Débug » afin d’essayer d’y voir plus clair sur le problème.

Enfin, si le reset ne résoud pas le problème, le revendeur m’a proposer un échange matériel afin d’écarter cette piste.

Salut,

Suite au reset, cela a planté plusieurs fois au bout de 24 ou 48 heures. Néanmoins cela ne s’est pas reproduit depuis quelques jours.

D’autre part, je suis toujours en train d’échanger avec le support Velux qui m’a proposé de leur retourner mon KLF pour qu’il le teste (mais bon, ce n’est pas pour tout de suite compte tenu de la situation actuelle).

J’attend également un retour de leur part pour savoir si je peux tenter de faire fonctionner le KLF avec une alimentation de Raspberry. On ne sait jamais, peut être que l’alimentation a un soucis.

Dans le même temps, ils m’ont également indiqué qu’ils devraient entrer en contact avec toi @lunarok sans me donner de détails.

Pour le moment nous nous mettons en contact avec le développeur du plug-in (Lunarok), et un retour se fera dès que possible.

Pour avoir, je suppose, plus d’informations sur le fonctionnement du plugin et surtout de la librairie pyvlx (je leur ai donné le lien github vers la librairie).

Bonsoir à tous,

Je souhaitais simplement me joindre à vous car j’ai également ce problème.
Les mêmes symptômes. Si je peux aider, n’hésitez pas.

Bonjour,

Quels sont les éléments que tu pilotes avec ton KLF ?

Tu as également une connection qui échoue dans les logs ?

Cela reste quand même très aléatoire car cela fait 3 semaines que cela ne s’est pas reproduit chez moi. Ca fonctionne depuis le 16 mars sans souci (soit 22 jours). Cela n’avait jamais tenu aussi longtemps (19 jours max avant) …

La seule chose que j’ai faite juste avant (le 15 mars) a été la mise à jour de 2 plugins mais qui n’ont rien à voir avec le KLF. Le plugin KLF est toujours dans la version du 2020-01-16 06:38:37