Bonjour,
Depuis quelques temps j’ai régulièrement dans le log du plugin KLF200 l’erreur ci-après et comme je débute sous Jeedom et en Domotique je suis un peu comme une poule qui a trouvé une épingle à nourrice
======== Running on http://0.0.0.0:9123 ========
(Press CTRL+C to quit)
[2021-07-27 15:18:24][ERROR] : Erreur sur la fonction cron du plugin : Echec de la requête HTTP : 192.168.2.18:8484/api/5B838DDED1/lights/2/state cURL error : Failed to connect to 192.168.2.18 port 8484: Connection refused
Je comprend bien que mon RPI4B sur lequel j’ai un Jeedom buster v4.1.24, refuse la connexion mais comment je peux corriger cela ou quoi faire pour éviter cette erreur ?
D’avance Merci de vos réponses
Cordialement
oracle7
A l’époque j’avais fait un scénario comme expliqué dans le sujet qui détecte ce log et relance électriquement le KLF puis le démon. En revanche après qques temps tout était dedevnu stable et ce message avait disparu. Par ailleurs, le plugin a évolué aussi en // .
Au final il convient de mettre le KLF sur une prise pilotée ce qui permet de le relancer automatiquement (ce que permet le plugin via sa config en intégrant les commandes On/off de la prise sur laquelle est branchée le KLF mais pas forcément sur ce cas d’erreur)
@Ds5
Bonjour,
Merci de ta réponse rapide.
J’ai lu avec attention le post que tu as indiqué mais j’avais déjà fait tout cela lors de l’installation initiale (après moulte lectures sur le forum) à savoir utilisation d’une prise commandée et activation du Heatbeat.
Que faire de plus alors, relancer l’installation des dépendances ? Par ailleurs je suis à jour de toutes les MàJ RPI, Jeedon, plugin, etc … et mon installation globale à oins de 3 mois.
Bug du plugin ?
Cordialement
oracle7
→ relance dépendances : a priori si cela a déjà été fait et avec succès, je doute que çà soit utile
→ le heartbeat pour moi ou la relance auto par le plugin ne fonctionne pt etre pas dans tous les cas d’erreurs. De tte manière tu peux regarder quand le KLF ne répond plus si tu vois le plugin arreter et relancer électriquement ton KLF. Si c’est pas le cas il faudra que tu fasses le même type de scénario que moi si jamais tu vois tjs la même erreur dans les logs => ca ne résoudra pas la cause de l’erreur mais lancera les manips de dépannage
Pour le reste avec le KLF, un certain nombre d’utilisateurs a expérimenté une période de premiers mois cahotiques avant de la stabilité (mais sans raison trouvée donc sans possibiluité de manip te rendant stable d’emblée). A mon niveau hélas je ne sais pas t’aider davantage, j’en suis désolé. Sans ces petits couacs de départ, le KLF est ensuite est excellent boitier couplé au plugin Jeedom (et en LAN sans Cloud !!)
@Ds5
Bonjour,
Merci de tes indications, je vais donc continuer à observer les choses et réparer éventuellement ponctuellement par un reboot du KLF200 en attendant cette stabilité que tu évoques.
Sinon, je ne sais pas faire ce fameux scénario qui scrute le log KLF et qui envoie un Telegram dès lors que que l’on détecte un log “connection refused”. Tu aurais STP une trame d’exemple ?
Enfin, à part ce petit soucis, je suis aussi extrêmement content de ce boitier KLF200 pour piloter mes Velux. C’est génial ! l’investissement vaut vraiment le coup. Je le recommande
Cordialement
oracle7
Hello tu as de la chance j’avais laissé mon scénario même s’il ne se déclenche jamais.
principe
examiner périodiquement le fichier de log « klf200.log »
rechercher si le motif « Failed to connect to localhost port 9123: Connection refused » (message que j’avais dans mon cas.
si motif trouvé alors prévenir + relancer/demander si le KLF doit etre redémarré
(d’ailleurs au passage je ne comprends pas trop pkoi on n’a pas le même port : 8484 pour toi, 9123 pour moi, il me semblait que ct une valeur tjs la même)
Scénario
commencer par mettre un item de type « bloc code » contenant le code suivant :
$scenario->setLog("contrôle connexion KLF200 : début...");
$pathlog=log::getPathToLog('klf200');
if (file_exists($pathlog) && shell_exec('grep "Failed to connect to localhost port 9123: Connection refused" ' . $pathlog . ' | wc -l') > 0)
{
$scenario->setLog('un log de défaut de connexion détecté');
$scenario->setData("KLF200_ctlOk", "défaut de connexion");
}
$scenario->setLog("contrôle connexion KLF200 : fin.");
Le bloc recherche le texte erreur, et si trouvé mets dans une variable de scénario « KLF200_ctlOk » la valeur défaut de connexion.
Ensuite il suffit de tester si la variable contient ou pas défaut et alors d’envoyer un telegram/faire un ask demandant si on doit rebooter le KLF et donc faire un off puis 3s plus tard un on
Pour être parfait :
mieux vaudrait utiliser un tag dans le bloc code :
// récupérer les tags du scénario
$tags = $scenario->getTags();
$tags['#tagKLF200_ctlOk#'] = "init ctl"
puis...le test de log
puis
$tags['#tagKLF200_ctlOk#'] = "défaut de connexion"
Ensuite on teste non pas avec variable(« ma variable ») mais avec tag(tagKLF200_ctlOk)
Et enfin dans mon cas je n’étais pas allé au bout car à la fin il faudrait vider le log sinon au prochain coup on va retomber sur le message d’erreur d’avant alors qu’il n’y en a pas de nouveau et le KLF va reboter en boucle Moi j’avais juste mis dans le telegram « pensez à vider le log » (et je le faisais manuellement)
En regardant ttes les 7mn (j’avais mis 7 pour ne pas tomber pareil que les cron hourly, 5, 15 etc) ca donne alors visuellement :
(à noter que dans les dernières commande j’arrete et relance le démon KLF aussi => se fait grace à un équipement Jeedom Link en mettant en jeedom cible le jeedom sur lequel on se trouve, ca permet d’accéder à toutes les commandes de relance des démons du jeedom. Ca doit aussi etre possible par bloc code
@Ds5
Bonsoir et MERCI pour ton aide, c’est vraiment sympa de ta part de me répondre.
Je vais regarder tout cela à tête reposée car comme je débute, je ne maitrise pas tout et il va me faloir un peu de temps pour comprendre et assimiler certaines notions que tu utilises et qui sont pour l’heure un peu du chinois pour moi. Mais comme tes explications me parraissent assez claires, je devrait m’en sortir. Je croise les doigts …
SInon, aujourd’hui je viens d’avoir ceci dans le log, maintenant il semble que le « Heartbeat » s’en mêle lui aussi. Je te laisse examiner si des fois cela te cause car moi, je n’y comprends pas grand chose :
======== Running on http://0.0.0.0:9123 ========
(Press CTRL+C to quit)
Task exception was never retrieved
future: <Task finished coro=<Heartbeat.loop() done, defined at /usr/local/lib/python3.7/dist-packages/pyvlx/heartbeat.py:36> exception=PyVLXException('Unable to send get state.')>
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/pyvlx/heartbeat.py", line 45, in loop
await self.pulse()
File "/usr/local/lib/python3.7/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." />
[2021-07-30 21:07:05][ERROR] : Erreur sur la fonction cron du plugin : Echec de la requête HTTP : 192.168.2.18:8484/api/5B838DDED1/lights/2/state cURL error : Failed to connect to 192.168.2.18 port 8484: Connection refused
Bonne soirée A+
Cordialement
oracle7 :wink:
Ok. Au besoin mets une copie de ton scénario quand tu le feras et je verrai pour t’aider si je peux.
Un truc me chiffonne quand mm : je vois en haut du log « Running :9123 » et l’erreur est sur le port 8484 ?! Je n’ai pas regardé la config de mon plugin depuis plus d’un an mais c bizarre d’avoir des tentatives de connexion sur un port différent de celui qu’utilise le démon ou j’ai manqué un point dans cette erreur
Et comme dit moi j’ai running 9123 et j’avais des erreurs de connexion sur le même port… Cela ne semble pas ton cas, je ne sais pas d’ou vient le 8484 => est-ce qque chose dans la config du plugin ? sinon partages la config plugin (normalement pas de port la dedans) ?
@Ds5
Non, 192.168.2.18 est l’@IP de mon RPI4B sur le quel est installé JEEDOM 4.1.24
Mon KLF200 est en 192.168.2.20 tu as config dans la copie d’écran dans les réponses précédentes (post 3).
Dans Jeedom, le port 8484 est le port utilisé par ma clé Combee II dans le plugin Deconz. Mais je ne vois pas de lien entre un protocole Bluethooh et le KLF200 ? Bizarre, bizarre, non ?
Cordialement
oracle7
oui exact je n’avais pas fait attention à ta capture.
J’avoue que je m’y perds dans les IP et ports…
Si tous ces logs sont bien dans le seul fichier klf200.log, je ne comprends pas trop ce que fait le port du plugin deconz dans ce log ou alors il y a un conflit de port sur les démons. Je te dirai bien de voir si dans deconz tu peux modifier le n° de port mais je ne maitrise pas ce plugin.
Ca me rappelle toutefois des choses vues rapidement de conflit de port entre démon mais je ne retrouve pas le sujet en question.
Lorsque tu relances tout et que la connexion s’établit c’est bien marqué connecté sur 192.168.2.20 ?
Par ailleurs le running on http://0.0.0.0 je ne sais plus si c’est ça dans mon log ou l’IP.
Comme ça quand mm l’ai l’impression que les deux plugins se marchent dessus
@Ds5
Bonjour,
Je viens faire un retour.
Donc les deux plugins se marchaient bien dessus, enfin sur tout le plugin Deconz. De son coté j’avais une mauvaise configuration de ma clé Combee2. J’ai redemander une nouvelle clé API et tout semble être rentré dans l’ordre. Je n’ai plus le message d’erreur sur le port 8484. C’est une bonne chose.
Par contre, j’ai toujours un problème avec le plugin KLF200 qui a dû redémarrer suite à non réponse. Voici le log correspondant :
======== Running on http://0.0.0.0:9123 ========
(Press CTRL+C to quit)
Task exception was never retrieved
future: <Task finished coro=<Heartbeat.loop() done, defined at /usr/local/lib/python3.7/dist-packages/pyvlx/heartbeat.py:36> exception=PyVLXException(‹ Unable to send get state. ›)>
Traceback (most recent call last):
File « /usr/local/lib/python3.7/dist-packages/pyvlx/heartbeat.py », line 45, in loop
await self.pulse()
File « /usr/local/lib/python3.7/dist-packages/pyvlx/heartbeat.py », line 64, in pulse
raise PyVLXException(« Unable to send get state. »)
pyvlx.exception.PyVLXException:
[2021-08-01 21:20:08][ERROR] : KLF200 has been restarted after found not responding
Le log ci-dessus est pour moi issue d’une tentative de relance automatique par le plugin suite à détection de non réponse/joignabilité du KLF (heartbeat).
Sur l’origine de l’erreur en revanche je ne sais pas, cela n’est pas lié au plugin mais à l’installation au global voire aux usages du KLF.
Outre parfois une période de « rodage » après installation récente (moi ca a été chaotique durant 2 ou 4 mois puis après nikel), certains utilisateurs avaient des soucis car ils lançaient trop souvent de manière rapprochée des ordres au KLF qui ne semble pas trop aimer. Il faut alors mieux créer des groupes ou revoir un peu l’espacement entre appels dans ses scénarios pour éviter d’envoyer x requêtes d’ouverture/fermeture en 3s ou 2s.
Sur le début parfois difficile cela pouvait venir d’une version du KLF qui a pu subir une évolution et être meilleure ou autre comportement interne au KLF… Je n’avais jamais vu quelqu’un identifier une manip particulière pour stabiliser le boitier. Un test à faire par ex est de stopper tous les appels au KLF et voir si même sans appel le KLF perd le lien. Si pas le cas ca viendra donc des appels donc ajouter un à un les usages et vérifier (en évitant la sursollicitation KLF sur 2s, ouvrir 4 ouvrants peut se faire à 5s d’intervalle, on n’est pas à 20s près). Si même sans rien le KLF se plante, c’est que le souci est ailleurs.
Je sais que je n’aide pas trop en disant cela mais voila je n’ai pas et n’ai pas lu d’éléments probants sur les manips de stabilisation d’un KLF après install ou controles basiques à faire
@Ds5
Bonjour,
Dans mon cas, j’écarte la fréquence d’envoi d’ordres trop rapprochés. Pourquoi ? parce simplement, aujourd’hui je ne commande qu’un seul Velux avec une ouverture programmée chaque matin à 08h00 et une fermeture au couché du soleil. En dehors de cela, des manœuvres très ponctuelles et limitées en amplitude pour adapter à l’ensoleillement la position du volet (surtout en fermeture) à l’aide de la télécommande physique. Donc en aucun cas par action automatique de Jeedom.
Pour le log, il y a mon humble avis, quand un problème car le programme (demon ?) sort sur une exception « Unable to send get state ». Donc je crois qu’il y a un cas de figure mal traité dans le code. Bug ou mauvaise gestion : allez savoir ?
Cordialement
oracle7
en effet avec un ouvrant on peut pas dire que c’est surchargé
pour le message « unable to get state » je doute que çà soit un prb de code… Cela veut juste dire que « à ce moment là » le plugin ne parvient pas à réaliser une action mais pas qu’il ne réussit jamais. Et de tte manière si la relance auto se déclenche c’est justement qu’il y a un souci mais ce n’est pas tout le temps puisque sauf erreur tu réussis quand mm à lancer l’ouvrant à 8h le matin de temps à autre.
Comme dis il doit y avoir une instabilité qque part, reste à voir d’où çà vient ou procéder par test… Mais c’est là que je suis à court d’idée comme dans d’autres cas d’instabilité KLF. C’est d’autant plus bizarre ces phases ou install que pas mal d’autres n’ont à l’inverse aucun souci.
Bon courage pour tester plusieurs choses, généralement on finit par trouver ou le truc se stabilisera seul
@Ds5
Bonjour,
Oui je vais continuer à surveiller tout cela. au passage, cela fait 3 jours qu’il n’y a eut aucune erreur, serait-ce un début vers la stabilité ?
En tout cas merci de tes réponses et de ta patience avec moi, j’apprécie !!!
Cordialement
oracle7
Hello
Au cas où pour vérification : je viens de maj le plugin KLF200 même si pas indispensable pour moi (modif sur les BSO) et j’ai vérifié mes logs de relance du plugin :
→ j’ai bien aussi 0.0.0.0:9123 (j’avais un doute que ct l’IP du KLF qu’on devait voir)
======== Running on http://0.0.0.0:9123 ========
→ pour autre contrôle dès fois que, la version du KLF vu du plugin (si jamais le KLF ratait sa maj de firmware post usine, c’est un peu opaque la maj KLF…)
Connecting to KLF 200.
Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 6, protocol version: 3.14
Si ce n’était pas cette version sur ton KLF, ca serait déjà un truc à mettre à niveau
Dans le contexte d’un serveur, 0.0.0.0 signifie « toutes les adresses IPv4 de la machine locale ». Si un hôte a deux adresses IP 192.168.1.1 et 10.1.2.1, et qu’un serveur du réseau en cours d’exécution écoute sur 0.0.0.0, il sera accessible sur ces deux IP.
Moi j’avais juste mis dans le telegram « pensez à vider le log » (et je le faisais manuellement)
