Klf200 plante

Plugins Autre
1

Bonjour, j’utilise le klf200 pour contrôler mes volets somfy sur jeedom 4.051

Cela fait 2 fois en 10 jours que jeedom ne me ferme pas les volets le soir, aucunes erreurs dans jeedom, plugin et demon klf200 ok.
Les commandes d’ouvertures et fermetures ne marchent pas. J’ai fermé les volets avec les interrupteurs et les volets sont toujours ouverts sur jeedom. Donc aucunes communication jeedom / klf200.

Je débranche / rebranche le câble réseau du klf200 : les commandes sur jeedom ne marchent pas.
Je débranche / rebranche électriquement le klf200 : jeedom retrouve l’accès, aucunes erreurs, plugin et demon ok !

J’ai enlever la tahoma car pas fiable à cause des serveurs somfy, après 3 mois d’utilisation le klf200 n’est pas terrible non plus !

Quelqu’un a t-il eu le même soucis que moi?

2

Hello
Des remarques similaires ont été évoquées ici KLF200 ne repond plus aux commandes ou KLF200 : synchro retour d'état entre actions via KLF et actions via commande murale/KLR200 ko suite erreur périodique connexion refusée. Les raisons dans les deux cas diffèrent.
Pour ma part, après un début un peu similaire à toi sur des non réponses/défaut KLF, l’ensemble est stable à ce jour. J’ai déjà signalé avoir fait un reset KLF lors de l’ajout de mes Somfy à mes velux sans réussir à savoir si c’est cette manip qui avait contribué à stabiliser ou une autre chose (maj KLF, autre version Jeedom, passage de mon rpi3 sur une prise ondulée et plus stable que la précédente, etc…)
A voir dans le premier sujet que je cite qui ressemble un peu à ton symptome.
Désolé je n’ai pas compris qu’on avait une recette miracle pour stabiliser un KLF « sorti de carton » (neuf)

3

Salut,

Comme indiqué sur le premier post cité par @Ds5 , j’ai eu pas mal de soucis aussi au début et cela fait maintenant quelques semaines que c’est stable sans aucune raison apparente.

Cela serait quand même interessant d’activer le mode debug sur le plugin pour voir si tu as un message parlant au moment ou tu as le soucis.

4

merci je vais activé le mode debug

5

merci de ta réponse, je vais regarder sur l’ancien forum

6

Slt j’ai le klf 200 qui à replanté.

Voici le log, jeedom ne peut pas se connecter au klf200 :

[2020-04-29 09:22:48][DEBUG] : Action /set/1/0
[2020-04-29 09:22:48][DEBUG] : Send http://localhost:9123/set/1/0
Connecting to KLF 200.
[2020-04-29 09:22:48][DEBUG] : Result {« result »: « fail », « reason »: « exception during execution », « message »: « [Errno 111] Connect call failed (‹ 192.168.2.116 ›, 51200) »}

Avec le plugin network je surveille les connections réseaux de tous mes éléments. Le klf200 est toujours connecté en LAN. En le débranchant électriquement le plugin network m’indique la déconnexion.

Donc je pense que le plugin KLF200 pose probleme ou sinon c’est jeedom.

Merci d’avance

7

Bonjour, le klf200 à replanté ce matin.

Voici le log :
[2020-05-04 09:21:06][DEBUG] : Action /set/1/100
[2020-05-04 09:21:06][DEBUG] : Send http://localhost:9123/set/1/100
Connecting to KLF 200.
[2020-05-04 09:21:06][DEBUG] : Result {« result »: « fail », « reason »: « exception during execution », « message »: « [Errno 111] Connect call failed (‹ 192.168.2.116 ›, 51200) »}
Connecting to KLF 200.

J’ai réinstallé le plugin sans débrancher le klf200 et ça remarche

@lunarok le problème peut il venir du plugin ou de jeedom? ( jeedom 4.051, raspbian buster, raspberry 4)

Merci d’avance

8

@lunarok une fois de plus obliger de le débrancge pour que le KLF200 refonctionne,

Dan les log j’ai : connection aborted error ssl klf 200

ou est le problème? merci d’avance

9

Bonjour à tous,

Comme d’autres, je suis propriétaire d’un KLF200 en remplacement d’une tahoma pour lequel les serveurs somfy avec leur limitation d’appels API et leurs indisponibilités récurrentes m’ont tourné vers une solution locale. Verdict temporaire: C’est pire. La connexion vers l’API de la KLF200 tombe plusieurs fois par jour et le smart plug situé sur son alim la redémarre n’y change rien.

Voilà ce que j’obtiens en fermant tous mes volets somfy(9) et velux(3) AVEC SUCCES via l’équipement « All RollerShutter »:

[2021-01-25 17:53:26][DEBUG] : Action /set/5/0
[2021-01-25 17:53:26][DEBUG] : Send http://localhost:9123/set/5/0
[2021-01-25 17:53:26][DEBUG] : Result {"result": "ok", "device": 5, "position": "100 %"}
[2021-01-25 17:53:26][DEBUG] : Action /set/11/0
[2021-01-25 17:53:26][DEBUG] : Send http://localhost:9123/set/11/0
[2021-01-25 17:53:26][DEBUG] : Result {"result": "ok", "device": 11, "position": "100 %"}
[2021-01-25 17:53:26][DEBUG] : Action /set/3/0
[2021-01-25 17:53:26][DEBUG] : Send http://localhost:9123/set/3/0
[2021-01-25 17:53:27][DEBUG] : Result {"result": "ok", "device": 3, "position": "100 %"}
[2021-01-25 17:53:27][DEBUG] : Action /set/4/0
[2021-01-25 17:53:27][DEBUG] : Send http://localhost:9123/set/4/0
[2021-01-25 17:53:27][DEBUG] : Result {"result": "ok", "device": 4, "position": "100 %"}
[2021-01-25 17:53:27][DEBUG] : Action /set/6/0
[2021-01-25 17:53:27][DEBUG] : Send http://localhost:9123/set/6/0
[2021-01-25 17:53:27][DEBUG] : Result {"result": "ok", "device": 6, "position": "99 %"}
[2021-01-25 17:53:27][DEBUG] : Action /set/7/0
[2021-01-25 17:53:27][DEBUG] : Send http://localhost:9123/set/7/0
[2021-01-25 17:53:28][DEBUG] : Result {"result": "ok", "device": 7, "position": "100 %"}
[2021-01-25 17:53:28][DEBUG] : Action /set/10/0
[2021-01-25 17:53:28][DEBUG] : Send http://localhost:9123/set/10/0
[2021-01-25 17:53:28][DEBUG] : Result {"result": "ok", "device": 10, "position": "99 %"}
[2021-01-25 17:53:28][DEBUG] : Action /set/9/0
[2021-01-25 17:53:28][DEBUG] : Send http://localhost:9123/set/9/0
[2021-01-25 17:53:28][DEBUG] : Result {"result": "ok", "device": 9, "position": "100 %"}
[2021-01-25 17:53:28][DEBUG] : Action /set/0/0
[2021-01-25 17:53:28][DEBUG] : Send http://localhost:9123/set/0/0
[2021-01-25 17:53:29][DEBUG] : Result {"result": "ok", "device": 0, "position": "99 %"}
[2021-01-25 17:53:29][DEBUG] : Action /set/8/0
[2021-01-25 17:53:29][DEBUG] : Send http://localhost:9123/set/8/0
[2021-01-25 17:53:29][DEBUG] : Result {"result": "ok", "device": 8, "position": "100 %"}
[2021-01-25 17:53:29][DEBUG] : Action /set/1/0
[2021-01-25 17:53:29][DEBUG] : Send http://localhost:9123/set/1/0
[2021-01-25 17:53:29][DEBUG] : Result {"result": "ok", "device": 1, "position": "100 %"}
[2021-01-25 17:53:29][DEBUG] : Action /set/2/0
[2021-01-25 17:53:29][DEBUG] : Send http://localhost:9123/set/2/0
[2021-01-25 17:53:30][DEBUG] : Result {"result": "ok", "device": 2, "position": "100 %"}
[2021-01-25 17:54:03][DEBUG] : Send http://localhost:9123/devices
[2021-01-25 17:54:03][DEBUG] : Result {"result": "ok", "devices": [{"id": 0, "name": "Palier", "type": "RollerShutter", "position": 0}, {"id": 1, "name": "S\u00e9jour-chemin\u00e9e", "type": "RollerShutter", "position": 0}, {"id": 2, "name": "S\u00e9jour-entr\u00e9e", "type": "RollerShutter", "position": 0}, {"id": 3, "name": "Bureau-C\u00e9cile", "type": "RollerShutter", "position": 0}, {"id": 4, "name": "Cellier", "type": "RollerShutter", "position": 0}, {"id": 5, "name": "Bureau-Cyrille-Fen\u00eatre", "type": "RollerShutter", "position": 0}, {"id": 6, "name": "Chambre-Jos\u00e9phine", "type": "RollerShutter", "position": 0}, {"id": 7, "name": "Chambre-parents", "type": "RollerShutter", "position": 0}, {"id": 8, "name": "Salon", "type": "RollerShutter", "position": 0}, {"id": 9, "name": "Cuisine", "type": "RollerShutter", "position": 0}, {"id": 10, "name": "Chambre-Timoth\u00e9e", "type": "RollerShutter", "position": 0}, {"id": 11, "name": "Bureau-Cyrille-porte-fen\u00eatre", "type": "RollerShutter", "position": 0}]}
[2021-01-25 17:54:03][DEBUG] : Update Palier at 0%
[2021-01-25 17:54:03][DEBUG] : Update Séjour cheminée at 0%
[2021-01-25 17:54:03][DEBUG] : Update Séjour entrée at 0%
[2021-01-25 17:54:03][DEBUG] : Update Bureau at 0%
[2021-01-25 17:54:03][DEBUG] : Update Cellier at 0%
[2021-01-25 17:54:04][DEBUG] : Update Atelier Fenêtre at 0%
[2021-01-25 17:54:04][DEBUG] : Update Chambre Joséphine at 0%
[2021-01-25 17:54:04][DEBUG] : Update Chambre parentale at 0%
[2021-01-25 17:54:04][DEBUG] : Update Salon at 0%
[2021-01-25 17:54:04][DEBUG] : Update Cuisine at 0%
[2021-01-25 17:54:04][DEBUG] : Update Chambre Timothée at 0%
[2021-01-25 17:54:04][DEBUG] : Update Atelier porte-fenêtre at 0%

Voici maintenant ce que j’obtiens AVEC 3 ECHECS en changeant de mode quand je passe par le plugin volets qui pilotent individuellement chaque volet:

[2021-01-25 17:56:16][DEBUG] : Action /set/3/100
[2021-01-25 17:56:16][DEBUG] : Send http://localhost:9123/set/3/100
[2021-01-25 17:56:16][DEBUG] : Action /set/9/100
[2021-01-25 17:56:16][DEBUG] : Result {"result": "ok", "device": 3, "position": "0 %"}
[2021-01-25 17:56:16][DEBUG] : Send http://localhost:9123/set/9/100
[2021-01-25 17:56:16][DEBUG] : Result {"result": "ok", "device": 9, "position": "0 %"}
[2021-01-25 17:56:16][DEBUG] : Action /set/2/100
[2021-01-25 17:56:16][DEBUG] : Send http://localhost:9123/set/2/100
[2021-01-25 17:56:16][DEBUG] : Action /set/6/100
[2021-01-25 17:56:16][DEBUG] : Action /set/8/100
[2021-01-25 17:56:16][DEBUG] : Action /set/7/100
[2021-01-25 17:56:16][DEBUG] : Action /set/10/100
[2021-01-25 17:56:16][DEBUG] : Action /set/1/100
[2021-01-25 17:56:16][DEBUG] : Action /set/5/100
[2021-01-25 17:56:16][DEBUG] : Result {"result": "ok", "device": 2, "position": "0 %"}
[2021-01-25 17:56:16][DEBUG] : Send http://localhost:9123/set/6/100
[2021-01-25 17:56:16][DEBUG] : Send http://localhost:9123/set/7/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/10/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/8/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/5/100
[2021-01-25 17:56:17][DEBUG] : Action /set/11/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/1/100
[2021-01-25 17:56:17][DEBUG] : Action /set/0/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/0/100
[2021-01-25 17:56:17][DEBUG] : Action /set/4/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/11/100
[2021-01-25 17:56:17][DEBUG] : Send http://localhost:9123/set/4/100
[2021-01-25 17:56:17][DEBUG] : Result {"result": "ok", "device": 7, "position": "0 %"}
[2021-01-25 17:56:25][DEBUG] : Result {"result": "ok", "device": 6, "position": "0 %"}
[2021-01-25 17:56:25][DEBUG] : Result {"result": "ok", "device": 10, "position": "0 %"}
[2021-01-25 17:56:26][DEBUG] : Result {"result": "ok", "device": 8, "position": "0 %"}
[2021-01-25 17:56:34][DEBUG] : Result {"result": "ok", "device": 5, "position": "0 %"}
[2021-01-25 17:56:34][DEBUG] : Result {"result": "ok", "device": 1, "position": "0 %"}
[2021-01-25 17:56:42][DEBUG] : Result
[2021-01-25 17:56:42][DEBUG] : Result
[2021-01-25 17:56:42][DEBUG] : Result
[2021-01-25 17:57:04][DEBUG] : Send http://localhost:9123/devices
[2021-01-25 17:57:04][DEBUG] : Result {"result": "ok", "devices": [{"id": 0, "name": "Palier", "type": "RollerShutter", "position": 0}, {"id": 1, "name": "S\u00e9jour-chemin\u00e9e", "type": "RollerShutter", "position": 100}, {"id": 2, "name": "S\u00e9jour-entr\u00e9e", "type": "RollerShutter", "position": 100}, {"id": 3, "name": "Bureau-C\u00e9cile", "type": "RollerShutter", "position": 100}, {"id": 4, "name": "Cellier", "type": "RollerShutter", "position": 0}, {"id": 5, "name": "Bureau-Cyrille-Fen\u00eatre", "type": "RollerShutter", "position": 100}, {"id": 6, "name": "Chambre-Jos\u00e9phine", "type": "RollerShutter", "position": 99}, {"id": 7, "name": "Chambre-parents", "type": "RollerShutter", "position": 100}, {"id": 8, "name": "Salon", "type": "RollerShutter", "position": 100}, {"id": 9, "name": "Cuisine", "type": "RollerShutter", "position": 100}, {"id": 10, "name": "Chambre-Timoth\u00e9e", "type": "RollerShutter", "position": 99}, {"id": 11, "name": "Bureau-Cyrille-porte-fen\u00eatre", "type": "RollerShutter", "position": 0}]}
[2021-01-25 17:57:04][DEBUG] : Update Palier at 0%
[2021-01-25 17:57:04][DEBUG] : Update Séjour cheminée at 100%
[2021-01-25 17:57:04][DEBUG] : Update Séjour entrée at 100%
[2021-01-25 17:57:04][DEBUG] : Update Bureau at 100%
[2021-01-25 17:57:04][DEBUG] : Update Cellier at 0%
[2021-01-25 17:57:04][DEBUG] : Update Atelier Fenêtre at 100%
[2021-01-25 17:57:04][DEBUG] : Update Chambre Joséphine at 99%
[2021-01-25 17:57:04][DEBUG] : Update Chambre parentale at 100%
[2021-01-25 17:57:04][DEBUG] : Update Salon at 100%
[2021-01-25 17:57:04][DEBUG] : Update Cuisine at 100%
[2021-01-25 17:57:04][DEBUG] : Update Chambre Timothée at 99%
[2021-01-25 17:57:04][DEBUG] : Update Atelier porte-fenêtre at 0%

Premières conclusions: Les dernières commandes transmises sont mal gérées car seuls les 7 premiers volets sont en action. Les suivantes répondent uniquement par « Result ». On note aussi que l’envoi des commandes est moins bien ordonnancé, ce qui conduit à des échecs puis à des plantages de ce type:

[2021-01-25 18:09:03][DEBUG] : Send http://localhost:9123/devices
[2021-01-25 18:09:04][DEBUG] : Result
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.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "/var/www/html/plugins/klf200/resources/klf200d.py", line 22, in init_pyvlx_connection
await pyvlx.load_nodes()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 76, in load_nodes
await self.nodes.load(node_id)
File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 69, in load
await self._load_all_nodes()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 85, in _load_all_nodes
await get_all_nodes_information.do_api_call()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 21, in do_api_call
await self.send_frame()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 33, in send_frame
await self.pyvlx.send_frame(self.request_frame())
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 66, in send_frame
await self.connect()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 43, in connect
await self.connection.connect()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/connection.py", line 91, in connect
ssl=self.create_ssl_context(),
File "/usr/lib/python3.7/asyncio/base_events.py", line 959, in create_connection
raise exceptions[0]
File "/usr/lib/python3.7/asyncio/base_events.py", line 946, in create_connection
await self.sock_connect(sock, address)
File "/usr/lib/python3.7/asyncio/selector_events.py", line 464, in sock_connect
return await fut
File "/usr/lib/python3.7/asyncio/selector_events.py", line 494, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
TimeoutError: [Errno 110] Connect call failed ('x.x.x.x', 51200)
[2021-01-25 18:09:25][INFO] : Arrêt du service klf200
[2021-01-25 18:09:25][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py x.x.x.x 9XXXXXb4h
[2021-01-25 18:09:25][ERROR] : KLF200 has been restarted after found not responding
[2021-01-25 18:09:29][INFO] : Arrêt du service klf200
[2021-01-25 18:09:29][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py x.x.x.x 9XXXXXb4h
[2021-01-25 18:09:29][ERROR] : KLF200 has been restarted after found not responding
[2021-01-25 18:09:44][INFO] : Arrêt du service klf200
[2021-01-25 18:09:45][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py x.x.x.x 9XXXXXb4h
[2021-01-25 18:09:45][ERROR] : KLF200 has been restarted after found not responding
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.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "/var/www/html/plugins/klf200/resources/klf200d.py", line 22, in init_pyvlx_connection
await pyvlx.load_nodes()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 76, in load_nodes
await self.nodes.load(node_id)
File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 69, in load
await self._load_all_nodes()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/nodes.py", line 85, in _load_all_nodes
await get_all_nodes_information.do_api_call()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 21, in do_api_call
await self.send_frame()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/api/api_event.py", line 33, in send_frame
await self.pyvlx.send_frame(self.request_frame())
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 66, in send_frame
await self.connect()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/pyvlx.py", line 43, in connect
await self.connection.connect()
File "/usr/local/lib/python3.7/dist-packages/pyvlx/connection.py", line 91, in connect
ssl=self.create_ssl_context(),
File "/usr/lib/python3.7/asyncio/base_events.py", line 959, in create_connection
raise exceptions[0]
File "/usr/lib/python3.7/asyncio/base_events.py", line 946, in create_connection
await self.sock_connect(sock, address)
File "/usr/lib/python3.7/asyncio/selector_events.py", line 464, in sock_connect
return await fut
File "/usr/lib/python3.7/asyncio/selector_events.py", line 494, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
ConnectionRefusedError: [Errno 111] Connect call failed ('x.x.x.x', 51200)
[2021-01-25 18:10:03][INFO] : Arrêt du service klf200
[2021-01-25 18:10:04][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py x.x.x.x 9XXXXXb4h
[2021-01-25 18:10:05][DEBUG] : Send http://localhost:9123/devices
[2021-01-25 18:10:06][DEBUG] : Result
[2021-01-25 18:10:46][INFO] : Arrêt du service klf200
[2021-01-25 18:10:48][INFO] : Lancement démon klf200 : /usr/bin/python3 /var/www/html/plugins/klf200/resources/klf200d.py x.x.x.x 9XXXXXb4h
[2021-01-25 18:10:48][ERROR] : KLF200 has been restarted after found not responding
[2021-01-25 18:11:03][DEBUG] : Send http://localhost:9123/devices

J’ai noté également dans la doc de l’API velux:

4 Gateway interface
4.1 TCP/IP interface
The Ethernet module establishes a TCP/IP server listening at port 51200. Up to two
sockets can be established at the same time on wired ethernet.
TCP/IP socket will be closed after 15 min, with no communication. The command
GW_GET_STATE_REQ can be used to ping KLF200 from time to time, to keep the socked
established.
TLS is used to encrypt communication. For now, the certificate is self-signed.

Je me pose la question si le klf ne se met pas en standby durant 15 min car trop de connexions. Je vais tenter de jeter un œil sur le plugin et faire des tests avec les scripts python proposés par velux pour reproduire le pb ou bien le contourner.
@lunarok, si tu as des éléments de réponse ou si cette piste te semble intéressante, je suis preneur de ton retour, cela m’évitera de creuser au mauvais endroit.

10

Je me réponds à moi-même en permettant à d’autres d’y trouver peut-être un début de solution:
Le fait d’envoyer des requêtes en burst au klf200 crée des erreurs. Le klf200 semble effectivement mal réagir et finir par planter
La solution: Tout simplement ne jamais exécuter les requêtes en parallèle. Pour cela, je passe par le plugin mode qui a pour actions de passer chaque volet dans un nouveau mode programmé en action immédiate et là les requêtes se font bien de manière ordonnée quand on ne coche pas l’exécution en parallèle et en laissant le temps au klf200 de répondre à chacune comme cela est le cas lorsqu’on appelle « All RollerShutter ». Solution basique mais qui règle mon soucis…

Conclusion: Ne pas stresser le klf200 par de multiples requêtes parallélisées

11

Hello
De mon côté comme dit en début de sujet le début était bancal et après un peu de temps cela s’est vraiment stabilisé. Je ne sais pas si le premier reset a été salutaire ou pas quand j’ai tout remis à zéro pour réintégrer proprement tous mes ouvrants Somfy + Velux. Cette phase de démarrage d’install parfois bancale suivi de stabilité est incompréhensible.
Pour ce qui est de ne pas solliciter via x requêtes simultanées sur les ouvrants, je n’ai pas ce soucis : j’ai créé des virtuels de regroupement d’ouvrants pour mes usages car les seuls groupes du KLF ne correspondaient pas à mes attendus. Par exemple dans une commande Ouvrir d’un virtuel de groupe du premier étage, j’ai mis #volet 1-ouvrir# && #volet 2-ouvrir# && #volet 3-ouvrir# && #volet 4-ouvrir# comme action de la commande (donc 4 commandes d’ouverture à la suite) et cela se passe correctement. Idem pour le rez de chaussée ou 2è étage.
C’est perturbant de ne pas identifier ce qui permet de stabiliser plus vite le KLF car vraiment à l’usage depuis bientôt 1 an c’est vraiment très performant et bien loin des contraintes de la Tahoma que j’avais avant. J’espère que à un moment assez vite, ton KLF sera dans le même niveau de stabilité que grand nombre d’entre nous.

edit : je ne sais pas sur quel matériel / OS / version tu es, dans mon cas ca avait bien fonctionné sur rpi3 stretch et Jeedom v4.0 après le début délicat durant pt etre 1 mois 1 mois et demi. Ensuite j’ai du basculer en buster car le plugin était devenu ko

12

Merci DS5 de ton retour et désolé du temps que j’ai mis à te répondre.
Je suis en buster, Jeedom V4 sur un NUC.

J’ai fait beaucoup de tests et surtout j’ai eu de multiples plantages mais fidèle à ma première impression, j’ai véritablement constaté qu’il ne fallait pas stresser le klf avec trop de requêtes.
Ce que j’ai fait/constaté:
1- Enlever la commande de rafraichissement de la position de chaque volet dans le plugin Gestion Volets (développé par Jeedom). Pourquoi? Car il produit des requêtes unitaires pour chaque volet en mode burst tandis que le plugin klf200 génère lui-même une interrogation de tous les volets en une seule requête chaque minute: "Send http://localhost:9123/devices"
2- Le klf200 ne gère que deux connections simultanées, si on envoie une demande de changement de volet au moment où un update se produit: Patatrac! Sauf erreur de ma part, le plugin klf200 ne gère pas cette limitation–> Serait-ce la source de tous nos ennuis?
3- Un refresh toutes les minutes tandis que le klf200 met quasi 1 minute pour démarrer peut créer des anomalies en série quand le klf200 est branché sur une prise connectée pilotée par le plugin. Le plugin ne laisse parfois pas le temps au klf200 de revenir à la normale et hop on repart pour un reset (j’ai pu avoir 300 resets en 1 seule journée!)
4- La gestion par groupe de volets via des virtuels soulage le traffic avec le klf200, ce qui limite les risques de plantage mais comme j’utilise le plugin gestions volets, je suis obligé de d’envoyer mes commandes au plugin gestion volets qui renvoie les commandes au plugin klf200 sinon je perds la notion de mode avec les cas de suspension prévus dans le plugin volets. (J’utilise le plugin volets pour sa gestion des jours de canicule essentiellement) → Le plugin gestion volets est imparfait car il sursollicite les tahomas et klf200 dès lors que nous avons un nombre important de volets (limitation à 10 requetes sur le cloud Somfy)
5- C’est pas encore parfait mais ça va déjà mieux.

@lunarok, je suis intéressé de connaitre ton point de vue sur mes observations, surtout celles concernant la limitation à 2 requêtes et le système de reset. J’en profite également pour te remercier pour ce plugin et l’ensemble des contributions que tu apportes à Jeedom que je suis attentivement.

13

Hello
Intéressant ton retour sur ton usage via le plugin Gestion volets. Je n’utilise pas ce plugin ayant dès le départ choisi de tout programmer et gérer moi même pour avoir exactement ce que je voulais et modifier à loisir. La gestion des journées chaudes est aussi un cas que j’ai mis en scénario.

En tout cas j’ai un usage sans doute moins « agressif » que ce que tu décris et en effet pas de type ttes les minutes je demande volet 1, volet 2, volet x sur mes 15 ouvrants. J’imagine qu’on déclare volet par volet dans le plugins donc ensuite autant d’actions que de volets déclarés au lieu d’une seule ou de 2 ou 3 groupés selon nos groupe d’ouvrants. Dans l’absolu bombarder de requete un serveur n’est rarement une bonne idée surtout ttes les minutes. Dans le même esprit je faisais des requetes sur mon WES (écocompteur) avant via le plugin script pour chercher un item du xml renvoyé. Sauf que au lieu de requeter une fois et extraire toutes les données, le plugin nécessitait que je fasse une requete par info soit environ 15 requetes simultanées chaque minute : le WES a aimé moyen. EN faisant un code php moi meme requetant une seule fois toutes les minutes je suis repassé de WES instable à WES nikel. Ca me fait étrangement penser à ton cas ici !

In fine j’espère que tu as pu stabiliser ton usage car le KLF reste vraiment la meilleure solution à date sur de l’IO selon moi et bien loin devant la Tahoma que j’avais avant.

Je ne mesure pas ta « dépendance » :slight_smile: vis à vis du plugin volets pour déterminer si c’est facile de s’en affranchir dans ce cas. En usage « classique » pour ma part, c’est vraiment plutôt stable et très efficace.

14

Bonjour,
je suis votre échange. Je n’ai pas votre niveau de compréhension du fonctionnement de jeedom , etc . Aussi pardonnez moi, si je n’emploie pas les bons termes.
J’ai un klf200 ; 6 velux et 5 volets dessus. contrôlés par 7 scénarios qui sont déclenchés toutes les 10 min ( / temp ext; angle soleil; luminosité; vent) . Sans le klf200 et le plugin de lunarok , ce serait impossible à gerer ainsi ! Donc déjà un grand merci à lunarok.

le klf a environ une dizaine de reset par jour ( sans conséquence sur le fonctionnement , mais …)

La question : les scénarios déclenchés par 10 min s’executent tous aux temps 00, 10, 20 ,… min donc peut être encombrement dans la charge du klf.
Question: En changeant la minute de déclenchement de chaque scenario (par exemple 02, 12, 22,…) est il possible de diminuer la charge sur le klf et la fréquence des reset ? Question annexe comment fait on pour faire cette modif sachant que ces minutes rondes on l’air preprogrammées.
A vous lire.
joel

15

Hello
Plusieurs aspects me posent question dans votre description donc avant de revenir sur le déclenchement à des créneaux non « pleins/piles », il faudrait peut-être comprendre le contexte car la solution ne s’appliquera peut-être pas.

  • vous parlez de « reset KLF » et j’imagine par la que vous voulez dire "relance du démon du plugin (fait par le plugin lui même qui génère un message normalement « le démon a été relancé… » de mémoire ? vous parlez d’arret électrique et redémarrage (style j’éteinds l’alim et je la remets) ? ou autre chose ?
  • vous parlez de 7 scénarios déclenchés toutes les 10mn, ce qui me semble beaucoup ou alors selon le contexte un seul de ces scénarios se lance toutes les 10mn… A la base lancer 7 actions en simultané pouvant toutes agir sur des ouvrants ne m’apparait pas la bonne approche. Au pire regroupez l’ensemble dans un seul qui déroulera en séquentiel les demandes avec si besoin des pause de 2s entre chaque demande. Mais peut-être n’ai-je pas compris ce que font vos 7 scénarios…

Dans un premier temps sur par ex 48h, j’arreterai TOUS mes scénarios pour ne laisser que le démon tourner sans rien faire hormis l’interrogation périodique des états de vos ouvrants. Si déjà même là le KLF parait instable, ce sera une info intéressante et il sera alors parfaitement inutile de déplacer vos horaires de scanarios puisque même off le KLF ne tiendrait pas

Ensuite j’essaierai de voir en remettant un ou plusieurs ce que ca veut dire en nbre de demandes vers des ouvrants à l’instant t. Dans mon cas avec 15 ouvrants (7 volets + 4 fenetres velux + 4 volets roulants velux) c’est rare que je fasse dans la même minute une demande sur les 15 ou encore moins 15 demandes en simultané. Comme expliqué ci-dessus attaquer en masse un « serveur » n’est pas une bonne approche, et parfois via des plugins on introduit ce type de comportement si le plugin ne gère pas les groupes.

Pour ce qui est de programmer votre ou vos scénarios à des horaires non pleins type 0, 10 etc, vous avez plusieurs possibilités je pense :

  • la première est de trouver la bonne syntaxe de cron/période de déclenchement définie sur le scénario directement :slight_smile: je ne sais plus si la syntaxe 1/8 * * * * par exemple pour toutes les 8 minutes à partir de la minute 1 fonctionne… ce qui donnerait 1, 9, 17, 25, 33, 41, 49, 57 par ex
  • autre solution que j’utilise moi et que je trouve à la fois sympa en visu et facile à appréhender : le plugin agenda permettant de définir des évènements se déclenchant à telle ou telle heure (cas de mes ouvertures / fermetures du matin variant selon le jour de la semaine => la c facile il suffit de dire je veux tel scénario à telle ou telle heure et de faire par exemple une heure distincte pour chaque type de scénario (dans mon cas je dissocie de 2mn ouverture RdC et étage par ex, même si j’ai constaté que ca marche quand mm a priori mais j’évite de sursollciter)
  • Autre point : c’est la aussi à confronter à votre approche de scénario : pour ce qui est des fermetures, j’ai un unique scénario qui se lance vers 4h du matin qui programme avec des blocs « A » des actions unique fonction des heures du soleil et idem je décale un peu la fermeture de l’étage 2 de l’étage 1 et le RdC lui est en décalage plus marqué (volontairement et tjs pour éviter de demander tout en rafale sur la même minute)
  • dernier item : mon scénario de gestion des ouvrants pour la protection soleil et canicule : il se déclenche en revanche lui ttes les 15mn (je n’ai pas cherché à décaler versus 0, 15, 30, 45) et est unique pour déclencher de manière séquentielle les diverses actions sur tous les ouvrants concernés. Mais la encore fermeture et reouverture selon azimuth du soleil ne concerne jamais à l’instant t plus de 2 ouvrants donc il n’y a pas de forte sollicitations en simultané et au pire je les espace car gérées en un seul scénario parcourant ouvrant par ouvrant le besoin et mettant une courte pause entre les demandes

Dernier point je ne comprends pas trop pourquoi vous dites que vos horaires sont pré programmés si c’est vous qui avez fixé la programmation de votre scénario (sauf à dire que vous avez chois ttes les 10mn dans l’interface et que du coup la prg se cale sur 0, 10 etc). Dans ce cas voir ma remarque sur la syntaxe de cron à modifier versus celle générées par défaut et voir si elle est acceptée (à tester vite fait en faisant un petit scénario et en mettant ce que je citais ci-dessus (en espérant ne pas m’être trompé dans la syntaxe, il y a des sites web proposant cela : via recherche google tout à l’heure je suis tombé au hasard sur https://crontab.cronhub.io/ qui ne doit être qu’un exemple)

Voila ce que je pourrai vous conseiller : donc globalement un test à vide pour déjà éprouver la stabilité hors sollicitation de votre KLF, puis ensuite de pt etre bien analyser vos besoins pour mieux cloisonner et isoler en timing chacun de vos besoins

Espérant vous aider

1 « J'aime »
16

D’abord un très grand merci pour votre réponse . il va me falloir qq temps pour faire ces tests , etc. Aussi je reviendrai vers vous à ce moment là (peut être dans une ou 2 semaines) .

2 précisions :

  • le message qui est répétitif est : KLF200 has been restarted after found not responding.
    cela est automatique , je n’ai pas de prise commandée sur le klf.

  • Effectivement c’est toutes les 10 min que sont testées les conditions d’actions ( temps ext, int, angle soleil/ toit , lu, vent) et en pratique une action via le klf n’est pas systématiquement déclenchée. En ce moment c’est plutôt aucune sauf ouvrir, fermer les volets matin et soir car il n’ y a pas besoin de reguler plus) . L’été dernier il y avait beaucoup plus d’actions effectives, mais de memoire pas plus de message .

  • enfin dans la mesure où les velux sont dans 4 pieces avec 3 orientations différentes, les conditions ne peuvent pas vraiment être regroupées et les actions sont souvent un peu distinctes.

voilà
encore merci ,

17

Ok c’est clair. J’en déduis que c’est plus la stabilité du KLF qui est à creuser que les lancements de scénarios ou cumul de demandes vu qu’en ce moment vous n’avez que les ouvertures fermetures (à voir comment vous les lancer : pour ma part j’ai une commande groupée par étage faisant « ouvrir 1 && ouvrir 2 && ouvrir 3 » par ex, chaque commande de groupe étant lancé à des horaires en très léger décalage

18

Bonjour,

je reste à pencher du côté de la charge du klf :
je n’ai pas appliqué strictement votre proposition, mais j’ai tenté de suivre les principes que vous indiquez. Donc les modifs ci dessous il y a 9 jours

  • les volets de même orientation (3 différentes) sont lancés maintenant avec désynchro du lancement du scenario d’appel et dans chaque scenario pause de 4sec pour séparer chaque appel distinct)
  • les velux sont lancés par piece ( 3 pieces) en fonction du vent, de la temps ext…etc) avec les mêmes procédés de desynchro des scénarios de lancement et dans chaque scénario une séparation des appels de 4 sec pour chaque velux)

bilan provisoire ( on verra plus tard en saison qd les appels / volets seront ++ fréquents, pour les velux cela sera tj assez peu fréquent) :
Plus de message de redémarrage depuis 10 jours ! Vous m’avez sans doute mis sur la bonne voie: ne pas surcharger d’appels trop proches un klf très utile, mais pas trop costaud

Encore merci
joel

ps : de-synchro des scénarios en mettant des fréquences d’appel avec des temps arithmétiquement premiers entre eux , pour minimiser les appels simultanés

19

Très bien si vous avez réussi à avoir un comportement plus stable. J’espère pour vous que cela va persister sur la durée.

20

Bonjour ,
En pleine période estivale ( ou presque ) avec beaucoup de mouvement des velux entre ventilation et réglage le jour des stores. Donc beaucoup d’appels sur la KLFf200. mais les désynchronisations des appels marchent et pas de plantage de la KLFf200.
Ceci plaide bien pour les solutions que vous aviez évoqué en mars et suggère bien que la KLF200 ne supporte pas beaucoup d’appels simultanés malgré sa capacité à gérer XXX équipements .
Merci encore