Bonjour
heureux utilisateur du plugin KLF200 (et de la KLF200), j’ai toutefois un doute sur le fait que la KLF (puis le plugin) récupère bien l’état des ouvrants lorsque manipulés en dehors de jeedom/KLF. Je m’explique : lorsque j’utilise les commandes murales simples des Velux Integra KLI310 ou bien que les programmes auto de la KLR200 lancent l’aération des ouvrants, je ne vois pas de changements d’état dans Jeedom (en ayant attendu bien sur a minima 1 à plusieurs minutes le temps d’actualisation d’état coté plugin). Pourtant si je lance une commande depuis Jeedom le plugin et la KLF répondent et exécutent la commande. Est-ce le comportement attendu ou pas du tout ? Je m’attendais à des écarts que lors d’ouverture manuelle des fenetres, mais pas trop lors d’un usage des commandes électriques
PS : je n’ai pas regardé des détails de log ou autre vu que l’ensemble répond correctement d’un coté ou de l’autre, c’est plus la récupération d’état coté KLF ou plugin KLF qui semble ko. Après je vais refaire qques essais mais avant je me demande déjà si pour tout le monde tout cela marche parfaitement auquel cas je devrais creuser du coté de mon install…
Bon pas de succès sur ce sujet 
je me réponds (en partie) en complétant mes remarques : je pense avoir identifié ce qui ma induit en erreur lorsque j’ai regardé cela une fois puis à une seconde reprise, ce qui m’a alors fait penser à un souci. J’ai vu ce soir (ou plutot eu la confirmation) que la liaison avec mon KLF est parfois down, le plugin ne parvenant plus via son daemon à se connecter au KLF avec un message de connexion refusée avec ceci dans les logs (ici en mode debug) :
[2019-12-16 18:28:03][DEBUG] : Send http://localhost:9123/devices
[2019-12-16 18:28:03][ERROR] : Erreur sur la fonction cron du plugin : Echec de la requête HTTP : http://localhost:9123/devices cURL error : Failed to connect to localhost port 9123: Connection refused
Je peux ainsi avoir l’ensemble qui fonctionne parfaitement 4 ou 5j puis tout d’un coup se planter (ou meme comme la première fois etre ok quand j’ouvre un velux avec la commande murale puis 4mn après quand je teste la fermeture etre devenu ko et donc ne plus remettre le retour d’état du velux à niveau 
Après correction d’un nouveau plantage ce soir, je viens de réessayer avec ma commande KLR200 d’ouvrir une fenetre puis de la refermer avec la commande murale KLI et au bémol du refresh ttes les minutes voire 2mn pour le cas de bonne détection de fermeture, l’ensemble s’est mis correctement à niveau dans Jeedom via le plugin.
Je me suis donc trompé, mea culpa, cela fonctionne. J’ai en revanche un souci régulier de perte du plugin/liaison ce qui est moins bien
J’avais vu un cas similaire au mien dans les anciens forum ici : https://www.jeedom.com/forum/viewtopic.php?f=184&t=46656&start=80#p779183
Le retour à la normale est comme décrit pas trivial. Dans mon cas :
- reboot KLF sans effet
- redémarrage démon inopérant (avant ou après reboot KLF)
- attendre un peu (sans effet après le reboot ou démon)
In fine je ne m’en sors qu’en forcant une reinstall du plugin (évidemment sans désinstaller sinon je perds tous mes ouvrants déclarés dans jeedom et remontés via Jeelink vers mon jeedom principal)
Vu la nature du retour à la normale, je me dis que : - ca ne vient pas de la KLF ou sa joignabilité (le reboot ne change rien, elle est tjs visible sur le réseau) et dans les logs plugin en mode debug, lors de la relance du démon je n’ai pas vu l’IP de la KLF marquée non joignable (la connexion est refusée mais semble établie)
- je ne pense pas que ca soit le plugin « directement » sinon je ne serai pas le seul
Je pencherai plutôt pour une corruption des données de connexion (ou un souci à ce niveau en tout cas) que le forcage de reinstall remet droit peut-être. Bref je sèche je vais continuer à chercher mais je commence à être à court d’idées. Donc si idées elles sont les bienvenues
Bonjour, je suis bien à l’origine du message sur l’ancien forum.
Je croise les doigts dans la mesure où le soucis n’est s’est pas reproduit dernièrement. Entre temps, j’ai procédé à une bonne campagne de mises à jour (Jeedom et ses plugin, mais également sur le raspberry pi qui l’héberge).
J’ai également activé la case heartbeat du démon, mais je n’ai aucune idée de l’influence réelle de ce paramètre sur le bon fonctionnement de mon installation.
Pour info, j’ai parfois une erreur d’auth qui se produit sans que j’ai trouvé de raison (j’ai pu rester des semaines sans problèmes)
Dans mon cas, un reboot du KLF par contre résoud le problème. Du coup il est sur prise commandée maintenant. Et je garde en mémoire de détecter des erreurs de connexions dans le démon pour pouvoir agir en automatique dessus.
PS : le heartbeat du démon peut marcher aussi pour ca.
Bonjour, merci pour ce partage d’expérience sur le sujet.
pour jackoz : merci du retour. Mon rpi3 ayant été installé en stretch récente et en v4 avec tout à jour il y a environ 2 mois, je ne pense pas être dans le même cas.
Dans mon cas hier soir j’ai fait un scénario qui scrute le log KLF et m’envoie un Telegram dès lors que je détecte un log « connection refused ». J’avais misé sur le suivi des démons de mes Jeelink (la KLF est installée sur un Jeedom piloté par ma Smart qui peut donc détecter un statut de démon Jeelink ko !) mais comme sauf méprise le démon reste OK ca ne m’aurait pas servi et in fine c’est natif dans le plugin si je comprends la vocation du heartbeat, voire mieux si on active le redémarrage.
Il me reste qques questions (et un peu de boulot de diagnostic:) ) et je mettrai ce sujet à résolu/solution quitte à en réouvrir un si jamais je progressai sur le diagnostic d’une cause de perte de réponse KLF de mon côté :
- le reboot KLF résout le pb => on est d’accord que dans ce cas, aucune manip de relance de démon n’est requise, il retombe en connexion ok tout seul via 1mn en gros de délai ? Je ne suis pas très patient post reboot et me suis dit que passé 2 ou 3mn si je vois tjs connection refused c’est que ca n’a pas suffi…
- est-ce que dans votre cas d’authent ko vue en log, le démon est en statut NOK car dans mon cas non ? et du coup le heartbeat avec relance n’agira pas ?
- pour le heartbeat (comme son nom l’indique), j’imagine que c’est plus pour traiter le cas du démon NOK que connection ko (avec démon UP) ? ce qui ne me dédouane pas de l’activer en plus pour gérer aussi ce cas !
- a tout hasard la vu que ne peux pas donner de logs/infos précises, qu’est-ce que le plugin modifie en permanence qu’une reinstall forcée pourrait corriger ?
Merci par avance de vos réponses. Je poursuivrai mes tests et analyses, notamment pour vérifier comment facilement dépanner si cela se produit. Je retiens d’ailleurs le coup de la prise pilotée (même si pour le moment ca ne fait pas retrouver le service KLF
Non le service ne redémarre pas tout seul car comme tu le dis il reste OK.
C’est ca qu’il faut que j’ajoute dans le démon.
Et le démon ne se relance que toutes les 5mn dans Jeedom, pas à la minute.
Donc en cas de détection de l’erreur, il faut redémarrer le KLF et le mieux est de redémarrer ensuite le démon.
ah ok ca me rassure, je ne suis pas totalement à l’ouest en compréhension :)
Vu aussi pour le 5mn, je me suis en revanche trompé entre cron5 (démon) et retour d’état ttes les mn.
Je referai un test précis la prochaine fois car in fine, en ayant regardé mes logs, je me demande si au bout de 5 à 10mn le démon n’était pas redevenu Ok en connexion pdt que je reinstallais (pour rien surement) le plugin.
Je vais donc poursuivre pour voir si je suis dans le même cas que vous ce qui est plus que probable, au bémol que chez moi ca revient assez souvent (une semaine ?), d’ou mon scénario sur mes logs m’alertant par Télégram. Reste plus qu’à demander une nouvelle prise pilotée au petit Papa Noel pour la KLF et je serai au top
Je vais mettre solution sur ce sujet du coup.
Merci à vous pour vos réponses.
Moi il était sur Shelly Plug S, mais du coup je me suis dit autant mettre tout le rack en prises commandées et je me suis fait mal en achtant un PDU pilotable …
Mais oui, je confirme il est fortement probable que tes réinstallations « maquillent » le fait que le demon etait en fait relancé.
Hello
Je ne connaissais pas Shelly, je restais sur des Fibaro mais qui sont chers et luxueux pour un usage juste de commande de prise sans mesure de conso. Je vais sans doute examiner l’offre shelly pour mes commandes de ce type (cafetière, KLF voire pour chacun de mes 3 rpi en jeelink) et réutiliser les wallplugs Fibaro pour un usage plus de mesure de conso.
PDU pilotable je ne connaissais pas et oui ca fait un peu plus cher en passant de 20€ shelly à plus de 200 à 1000€ ! Glups ! A voir si pour le rack de ma baie ca serait bien à terme.
Je retiens toutes ces bonnes idées en tout cas.
La Shelly plug s fait aussi mesure de conso y a juste le prix qui change et l’anneau rgb n’indique pas la puissance en cours
Pour le pdu, c’est 150€ les 8 prises le mien. Ça cogne c’est sûr mais c’est plus joli dans le rack (argument waf quand c’est pour le salon, mais irrecevable pour le rack je sais…)
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.