si cela peut aider les devs.
J’ai redemaré le jeedom.
le KLF ne communique plus.
Voici les logs.
klf200.log (2,3 Ko)
J’ai du débrancher électriquement puis refaire un scan .
Merci.
1 « J'aime »
Bonjour
Je suis dans le meme cas, fonctionnait bien, depuis impossible de faire la moindre manip,
j’ai beau redémarrer le boitier, jeedom
j’ai essayer la version beta du plug, idem.
merci
Perso ça n’a pas fonctionné longtemps, le pense retourner à TaHoma qui même s’il est dépendant d’internet me semblait plus stable 
.
J’ai essayé de décaler la fermeture d’une minute pour chaque volets mais ça n’a pas fonctionné, je suis passé sur des variables pour ne lire les positions qu’une seule fois toutes les 4 minutes avec des sleep et les réutiliser ensuite mais pas mieux.
Le démon n’arrive pas à récupérer les positions et fini par relancer la box.
Salut,
Pour information, il y a un plugin officiel récent en beta qui permet de contrôler uniquement les ouvrants via l’interface KLF200 :
https://doc.jeedom.com/fr_FR/plugins/automation%20protocol/vlx2mqtt/beta/
Lors du dernier problème avec le klf en décembre, il avait été décelé une incompatibilité entre les modules python: pyvlx, aiohttp et PyYAML
Pouvez-vous fournir vos versions de ces modules?
Voir: KLF 200 ne cesse de redémarrer pour n'importe quelle action! - #169 par jpty
Pour résoudre, il fallait être avec le plugin en beta et relancer les dépendances.
Je ne sais pas si la stable du plugin a inclus ces corrections.
Bonjour,
Quel est l’avantage d’ajouter docker et mqtt pour de toute façon faire du python (pyvlx) entre le plugin et le klf?
La facilité de déploiement et le fonctionnement impeccable entre autre 
1 « J'aime »
Oui passer en stable, sur un autre post il y a des confirmations que ça fonctionne chez ceux qui avaient le soucis.
La on est sur un habituel sans logs rien donc je laisse les modérateurs ‹ communautaire › aider avec leur impartialité …
Faut pas être chonchon comme ça encore. La vie est belle mon ami nul besoin de se vexer de la sorte et de m’attaquer à demi mots.
Salut,
Merci pour l’info, il est effectivement en Beta ainsi que MQTT Manager.
N’ayant rien en Beta je vais attendre un peu.
Un peu du même avis que @jpty un peu dommage de passer par du MQTT.
Ah bon pourquoi cela ?
En imaginant comment cela peut fonctionner (je me trompe peut être), cela fait transiter toutes les informations du KLF via docker à MQTT puis de MQTT au plugin.
MQTT n’étant pas forcément sur le même serveur que jeedom les requêtes sont faites de docker vers le KLF reviennent vers docker pour envoyer les valeurs à MQTT que jeedom va ensuite recevoir via le plugin MQTT Manager.
Ca me semble être beaucoup d’échanges réseau.
Avantage effectivement cela permet de centraliser les données dans MQTT et d’utiliser d’autre plugins.
@lunarok je crée un sujet pour mon problème pour ne pas plus polluer celui là.
Bonne soirée
Oui merci de créer un sujet avec le max d’info.
Pour info le plugin mqtt klf, il fait pas les BSO, pas les lumières etc. Et aujourd’hui il n’a pas été testé sur autant d’install, donc l’aspect non expliqué sur le nombre, c’est du mensonge que s’avancer aujourd’hui en disant qu’il est parfait (j’ai testé le docker klf200 et il correspond pas à un usage complet de la gateway)
Comme expliqué dans la documentation et dans mon message…
Merci pour les tests en tout cas
1 « J'aime »
Salut, @jpty Merci pour l’indice sur la version, après un downgrade de aiohttp dans la bonne version, je n’ai pas eu de problème depuis 3 semaines 
.
@lunarok merci pour ce plugin, peut être ajouter dans la doc cette astuce sur les versions
Bonjour, j’ai aussi installé un klf200 / raspi+ busty+jeedom 4.2.x+ plugin. j’essaye comme vous de trouver une solution stable sans le plugin pour redémarrer le klf200.
je retrouve les mêmes messages, mais j’ai aussi regardé côté réseau :
au démarrage de l’ensemble tout ce passe bien; une session tcp s’établi (au dessus c’est du tls donc je ne vois rien de plus). cette même session semble « permanente » puisque elle est reste environ 4heures (lors de ce test)
j’ai remarqué une nouvelle session dans l’après midi et ce matin, plus de session. je vois les tentatives qui sont refusées par le klf via un reset.
pour aller plus loin je compte redémarrer le plugin, puis le klf200 pour voir comment ça va se débloquer.
Travaillant sur les infras réseau, ma première remarque serait qu’il faut éviter les sessions tcp permanentes qui font l’objet de pas mal de paramètres perturbateur( timers, dépendances, …) Normalement, un appel API = une nouvelle session TCP .
A suivre…
voici déjà mes premiers logs et trace tcpdump:
`0467|[2022-04-13 09:23:44]ERROR : KLF200 has been restarted after found not responding
0468|Traceback (most recent call last):
0469|File "/var/www/html/plugins/klf200/resources/klf200d.py", line 269, in
0470|LOOP.run_until_complete(init_pyvlx_connection(LOOP))
0471|File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
0472|return future.result()
0473|File "/var/www/html/plugins/klf200/resources/klf200d.py", line 22, in init_pyvlx_connection
0474|await pyvlx.load_nodes()
0475|File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 78, in load_nodes
0476|await self.nodes.load(node_id)
0477|File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 69, in load
0478|await self._load_all_nodes()
0479|File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 85, in _load_all_nodes
0480|await get_all_nodes_information.do_api_call()
0481|File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 21, in do_api_call
0482|await self.send_frame()
0483|File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 33, in send_frame
0484|await self.pyvlx.send_frame(self.request_frame())
0485|File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 66, in send_frame
0486|await self.connect()
0487|File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 43, in connect
0488|await self.connection.connect()
0489|File "/usr/local/lib/python3.7/dist-packages/pyvlx/connection.py", line 90, in connect
0490|ssl=self.create_ssl_context(),
0491|File "/usr/lib/python3.7/asyncio/base_events.py", line 959, in create_connection
0492|raise exceptions[0]
0493|File "/usr/lib/python3.7/asyncio/base_events.py", line 946, in create_connection
0494|await self.sock_connect(sock, address)
0495|File "/usr/lib/python3.7/asyncio/selector_events.py", line 464, in sock_connect
0496|return await fut
0497|File "/usr/lib/python3.7/asyncio/selector_events.py", line 494, in _sock_connect_cb
0498|raise OSError(err, f'Connect call failed {address}')
0499|ConnectionRefusedError: [Errno 111] Connect call failed ('192.168.100.200', 51200)`
POur le tcpdump, jeedom est en 192.168.100.106 et le klf : 192.168.100.200
notez les flags [S] puis [R] du klf200 :
09:25:46.679642 IP (tos 0x0, ttl 64, id 4965, offset 0, flags [DF], proto TCP (6), length 60)
192.168.100.106.46820 > 192.168.100.200.51200: Flags [S], cksum 0x4ab2 (incorrect -> 0x1673), seq 1561319422, win 64240, options [mss 1460,sackOK,TS val 1701368508 ecr 0,nop,wscale 7], length 0
09:25:46.679979 IP (tos 0x0, ttl 128, id 56306, offset 0, flags [DF], proto TCP (6), length 40)
192.168.100.200.51200 > 192.168.100.106.46820: Flags [R.], cksum 0xb158 (correct), seq 0, ack 1561319423, win 0, length 0
09:25:51.754516 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.100.200 tell 192.168.100.106, length 28
09:25:51.754893 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.100.200 is-at 64:61:84:00:73:85, length 46
…la suite: le demon était NOK bien sûr comme il n’arrive plus a joindre le klf. j’ai éteind et rallumé le klf et le demon est passé OK tout seul et j’ai naturellement une session tcp:
root@jeedom:~# netstat -tunalp | grep 192.168.100.200 tcp 0 0 192.168.100.106:47012 192.168.100.200:51200 ESTABLISHED 12089/python3
Bonsoir,
Je vous fais un retour sur le test que j’ai mis en place avec mon klf200.
Comme précisé juste au dessus je trouvais les sessions TCP trop longue, alors j’ai fait un petit scénario pour forcer une nouvelle session toutes les heures : (192.168.100.200 → klf200)
/* Lancement du kill de la session tcp klf200 */
$cmd = "sudo kill $(netstat -anlp | grep 192.168.100.200 | awk -F \" \" '{print $7}' | cut -d/ -f1)";
$scenario->setLog('DEBUG REQUETTE : '.$cmd);
$result = shell_exec($cmd);
$scenario->setLog('RETOUR REQUETTE : '.$result);
le process python tombe « proprement » et le plugin rétabli la liaison avec le klf200 avec succès.
seul bémol; juste avant de rétablir la liaison le plugin envoie logiquement le message « … restarted after found not responding ».
aucun dysfonctionnement observé depuis 2 semaines.
@lunarok qu’en penses tu ? serait il possible d’établir la session tcp au besoin ?
Bonjour
@lunarok
Pense tu pouvoir fiabiliser cela ?
Je suis en version beta et la derniere version de jeedom,
c’est vraiment la cata l’erreur,
Je ne comprend pas ce qu’il faut faire pour reboot suivant le script juste avant la session python, mais la franchement c’est dommage qu’on ai autant d’erreurs
Car j’ai mes volets qui ne marchent plus et plus d’explications, pourtant j’ai remis la sauvegarde avant la mise a jour, idem, donc il doit y avoir un pb entre le KLF et le pluging ?
Merci
Merci
1 « J'aime »