Perte d’état au (re)démarrage

pendant que pas mal de monde est le KLF… j’en profite : mon install fonctionne maintenant mais j’ai déjà eut le cas où le KLF semble ne pas répondre au plugin (dans les logs on voit la tentative de connexion mais rien d’autres) et un rebootage electrique du KLF a résolu le probleme. je vais donc surement investir dans une prise connecté…mais j’ai noté lors de mon rebootage electrique que l’état des ouvrants (dans mon cas des stores solaires) était perdu => donc si je planifie un reboot du KLF tous les jours, cela va pas génial.
=>vous connaissez cette perte d’état au (re)démarrage ? vos solutions ?
Merci d’avance :wink:

Bonjour. Parles tu de perte d’état des ouvrants sur le klf ou au sein du plugin et jeedom ?
Pour moi la mise à jour du statut dans jeedom est possible juste après reboot mais au cron minute d’après au pire c’est bon. Côté klf pur je n’ai pas ce souvenir. Et attention post reboot il faut redémarrer le démon klf. Donc dans l’ordre c’est reboot klf, tempo, relance démon et pour moi soit la soit au cron minute suivant donc en vrai dans les 30 secondes l’ensemble est OK. Et même depuis la version klf avec les commandes de reboot intégrées je pense que la relance démon se fera seule.
Maintenant hormis plantage ssl handshake récent et bloquant mon klf est vraiment stable et seules les coupures EDF le mettaient à mal. Donc je n’ai pas de cas récent de reboot pour vérifier la reprise des états ouvrants. Toutefois si c’était systématique je pense que je l’aurai vu

Bonjour,

J’ai eu plusieurs fois le cas au début ou la connection avec le KLF ne se faisait plus et un redémarrage de celui-ci était necéssaire. En revanche, cela fait maintenant plusieurs mois que cela fonctionne très bien sans souci. Comme evoqué par @Ds5 sur d’autres posts, c’est à croire que le KLF se stabilise avec le temps …

Je confirme la stabilité « à terme » après un début moins stable (une maj secrète du KLF post usine ? :slight_smile: )
à titre de preuve, une capture issue de mon design de supervision de tout mon système :
étatKLF_Tahoma
En gros, depuis que j’ai rétabli mon KLF (passage sous buster), eh bien aucun défaut ou perte (ni de relance démon dans mes logs). Je remercie EDF pour ne pas m’avoir refait de micro coupure comme régulièrement à une période (bon ca va pas tarder à être onduleur bientôt cela dit).

A noter que justement fort content du KLF, ma Tahoma est maintenant définitivement arrêtée (cf la date d’état dans la capture !). Si le KLF avait existé au moment de mon achat de Tahoma, je n’aurai jamais pris cette Tahoma.

Ce matin, la connexion semblait toujours OK entre le plugin et le KLF (rien dans les logs et je suis au niveau INFO) , mais pourtant l’état de mes ouvrants était faux. Même en faisant « Actualiser » sur les modules, toujours pareil. J’ai redémarré le plugin seulement, et là l’état de mes stores étaient corrects.
Question : peux-tu planifier un redémarrage de plugin ?? :wink:

Hum bizarre qu’il n’y ait rien dans les logs en erreur ou même le statut de démon OK alors que plus rien ne semble remonter (et j’imagine que dans cet état une commande sur un ouvrant est ko ?).

Pour accéder à la relance du démon par programmation/scénario, tu peux exploiter le plugin jeelink pour contrôler ton jeedom avec le KLF (normalement jeelink c’est plus pour n jeedoms reliés, toutefois on peut relier un jeedom à lui même juste pour avoir des commandes de contrôles, il ne faut surtout pas faire de bouclage entre un jeedom et lui même avec un équipement jeelink). Une fois le plugin installé, créer un jeedom cible sur la même IP que le Jeedom avec le KLF et la clé API du jeedom. Cela va créé un équipement de nom "controle " dans lequel il y aura une commande action « Démarrer KLF 200 » et une commande « Arrêter KLF 200 » avec une commande info binaire de statut du démon « Démon KLF 200 ».

Après soit le statut du démon est ko soit tu as un élément testable te faisant dire « bizarre le lien doit être ko » (log, date d’état d’un ouvrant trop loin dans le temps (type 12h ou 8h si tu manipules tes ouvrants le matin et le soir par ex etc). Sur détection de ce ko, un scénario peut arreter le démon, attendre 2 ou 3s, et le relancer par ex via l’équipement Jeelink.

Je ne sais pas si c’est la bonne réponse à ta question :slight_smile:

Merci @Ds5 , je ne connaissais pas cette méthode. très utile.
Dans un 1er temps, je tente en demandant le redémarrage du plugin via l’option HeartBeat , et je met les logs au niveau DEBUG.
Ce midi, de nouveau, le probleme, mais le redemarrage manuel du plugin n’a rien fait, il a fallu débrancher et rebrancher le KLF. sans doute aussi, je vais investir dans une prise connectée et planifier reboot KLF régulièrement…!

J’ai avancé : en fait en mode DEBUG, on voit que le plugin récupère l’état des mes ouvrants toutes les minutes(donc le heartbeat ne résoudra rien).Par contre, la position est fausse (c’était 100% alors que physiquement c’est 0%). je redémarre le plugin et magie, dans les logs on voit bien maintenant la récupération de la position a 0%
Au passage au demarrage : j’ai des erreurs liées à l’activation du HeartBeat, je ne sais comment les interpréter.

Hypothèse 1 : au bout d’un certain temps, le KLF envoie des données fausses et le fait de redémarrer le plugin ouvre une nouvelle connexion et on reçoit les bonnes infos
Hypothèse 2 : le plugin fait croire qu’il récupère les infos mais en fait, c’est une valeur ancienne.
Hypothèse 3 : 1 + 2 donc le KLF ferme la connexion ou un truc s’en approchant, mais le plugin ne détecte pas le problème, il ne récupère donc plus les infos, mais pas de traces dans les logs et il garde les anciennes valeurs.

Je penserai tout simplement qu’après une durée que je ne sais pas déterminer, globalement la liaison plugin -KLF est bancale comme pour certains durant une période post install initiale dont la durée est variable.
Le seul remède dans ce cas est la double relance « électrique KLF » suivie de la relance du démon.

Comme dit ci-dessus, plutôt que relancer tous les jours, il faudrait plutôt détecter un état anormal (visiblement la recherche d’un motif dans le log ne donnera rien car pas d’erreur) comme par ex un état d’ouvrant anormal à une heure donnée ou sinon peut-être mieux tester post lancement d’une commande si 1mn plus tard l’état est à niveau (c’est ce que je fais de mon côté pour détecter si j’ai un volet bloqué mais ici ce serait plus pour voir si la liaison est ok). Un petit « ask » pour demander s’il faut relancer tout et le scénario fera fort bien les actions

Par ailleurs si le système est hs mais qu’on n’utilise pas les commandes des ouvrants, ce n’est pas trop gênant (le symptome du vélo avec la roue à plat dans le garage : elle est à plat mais on n’utilise pas le vélo donc cela n’est pas un pb, ca le devient que si on vient prendre son vélo :))

Si en revanche les ouvrants sont très souvent manipulés manuellement (hors Jeedom), etre certain que coté Jeedom c’est à jour est sans doute utile.

Bref, je ferai plutôt un truc comme ca de mon côté : test état post demande sur un ou des ouvrants. Cela étant dans mon cas les commandes manuelles sont peu utilisées donc c’est vraiment le bon déroulé d’une demande depuis Jeedom qui m’intéressait. Ce n’est peut-être pas ton souhait !

PS : de mémoire sur un autre sujet, quelqu’un avait des soucis d’alim de son KLF (mais l’alim n’était pas celle fournie je crois). Dans mon cas j’ai mis sur une prise que le KLF au cas où il serait sensible à des variations. Et de tte manière ensuite pour une prise pilotée c’est sans doute préférable de ne pas la mettre sur une multiprise avec x trucs, qu’elle coupe ou pas les x trucs branchés.

Pour résumer : je n’ai pas de perte d’état du démarrage comme je l’avais affirmé (titre du post) Les 2 soucis rencontrés sont donc :

  1. désynchronisation entre plugin et KLF, non visible dans les logs. action effectuée chez moi : redémarrage du plugin 2 fois par jour via scénario
  2. echec de la connexion du plugin : dans les logs on voit « connecting » mais pas de réponse avec « KLF 200: Software version: 0.2.0.0.71.0, hardware… ». action à faire à mon avis : utiliser une prise connectée pour le KLF et paramétrer dans la config du plugin « Commande à utiliser pour éteindre le KLF200 »… qui ,si j’ai bien compris, vont être utilisé par le plugin pour arrêter le KLF et le redémarrer.

Hello. Pour le point 2 c’est aussi ma compréhension mais n’ayant pas ce cas de ko je n’ai pas pu testé si la coupure relance de la prise pilotée fonctionne. D’autres personnes ayant remonté ce prb de « Connecting » non suivi de "Connected " ont peut être des retours d’utilisation.
Sur le cas 1, je ne comprends pas trop la nuance avec le 2 sinon que suite à perte de liaison donc d’état, le plugin se relance peut-être au niveau démon en commençant par connecting mais échoue car le lien est en vrac tant que pas de reboot. Et in fine un seul et mm prb rencontré par d’autres au début de leur install.
N’ayant pas le cas chez moi, je suis pt etre à côté de la plaque :slight_smile:

Prise connectée achetée et installée sur l’alimentation du KLF > a voir maintenant
Ce matin, de nouveau mon cas « 1 » : dans jeedom mes 3 volets étaient fermées alors seul 1 l’était
Dans les logs, je voyais :


donc pas d’erreur, ni de connexion refusée
Une fois le DEBUG activée, je vois bien toutes les minutes la requete au KLF et les réponses « 100% » donc fermés. Je redémarre manuellement le plugin, et là , j’ai bien mes ouvrants au bon statut :

( NB:encore une erreur python liée au HeartBeat que j’ai pourtant désactivé… bizarre)

donc il me faut aussi gérer un redémarrage 1 a 2 fois par jour du plugin je pense.

[EDIT] : j’ai programmé l’arrêt du plugin (possible avec JeeLink) : cela a pour conséquence a chaque fois d’eteindre/rallumer la prise connecté du KLF. Très bien. 2 fois par jour me semble le minimum.

Ok je vois mieux les symptômes. Je ne sais en revanche pas trop ce qui pourrait provoquer l’histoire de non remontée d’état alors que la communication semble ok, c’est troublant ca.
Dommage que le KLF ne propose pas une IHM basique accessible sur son IP, ca permettrait quand même de vérifier ce qu’il voit lui et si c’est un problème de comm ou un défaut de remontée natif entre les ouvrants et le KLF. Cela dit j’ai eu en de rares fois un ouvrant qui ratait son retour d’état mais dans mon cas une simple manip rapide sur la commande murale type haut / bas provoquait un refresh correct de l’état et visible côté plugin. C’est pour ca que je trouverai intéressant d’avoir une IHM sur le KLF via son IP. Même avec le hotspot wifi KLF toujours On les infos sont maigres : on a la listedes ouvrants mais de mémoire pas possible de savoir l’état actuel d’un ouvrant vu du KLF. A essayer quand mm peut-être de voir si c’est un souci de mauvaise remontée d’état des ouvrants qu’un reboot remettrai d’équerre en provoquant une réinterrogation des ouvrants. Ca me fait quand mm penser à ca mais vu que seul la relance plugin fonctionne je me trompe surement.
Dans mon cas au fait, j’ai ce souci rarissime qu’avec mes ouvrants Somfy (disons 1 fois par mois au max avec 4 à 5 manipulations des ouvrants par jour), encore jamais vu sur mes Velux Integra.

Pour le cas de connecting sans rien, normalement et j’espère, la prise pilotée associé à ce que le plugin peut détecter devrait automatiser le cas.