Qui sait comment ça marche?

Bonjour à Tous,
Après avoir bien lu la documentation, et vérifier les points (Pas d’espace, une cnx rj45 & Wifi, …), j’ai tjs des problèmes depuis 2 mois pour faire fonctionner de manières fluides un scénario simple d’ouvertures ou de fermeture des volets.

Tous les incidents, rencontrer par chacun des sujets, arrivent.

Je pourrais facilement fournir des logs, mais est ce nécessaire de rouvrir un nouveau sujet ?

Le but mon sujet est de savoir si il y a une méthode miracle qui n’est pas décrite dans la documentation, et un condensé des ouetmilliers de réponses reçues dans les différents posts…
Car là je désespère.

  • vérifier le bon python
  • mais attention par la dernière version de celui
  • modifier une partie du code
  • utiliser plutôt la version bêta
  • et vérifier si le chat n’appuie pas 2 fois sur le bouton, faire des pauses …

Quand la version bêta, passera en prod, si elle fonctionne mieux que l’autre ?

Tout ça pour dire, que ce sujet semble fouillis depuis que je le suis.
En 2020 j’ai attendu, en 2021 j’ai senti une progression, en fin d’année je me lance et investi 250 balles dans l’appareil, pour finir en 2022, toujours pas de stabilité.

Merci pour votre aide sur le sujet, car j’aimerai partir l’esprit tranquille, en me disant ce que me dit la domotique n’est pas faux. Quand c’est ouvert, c’est ouvert… Pour le moment côté Velux ce n’est pas le cas … et si les volets fonctionnent, avec sérénité je pourrais mettre les fenêtres sans de me retrouver inondés en croyant que l’ouvrant est fermé !

Bonjour,

En postant dans la mauvaise catégorie et sans tag cela ne va pas aider à clarifier :wink:
J’ai corrigé pour vous.

Le nouveau sujet, vous l’avez ouvert; donc oui, fournissez vos logs et les infos sur votre environnement (versions de tout) et surtout décrivez votre problème parce que là il n’y a même pas de question, on ne sait pas ce qui ne va pas pour vous.

J’ajouterai juste que la beta et la stable sont identiques depuis au moins 2 semaines. Alors si passer en beta change quelquechose, faut aller jouer au loto immédiatement.

Soit, je vais envoyer mes logs, mais le but bien sûr au delà que cela fonctionne, c’était surtout d’avoir que le meilleur des kms de discussions, et éventuellement améliorer au mieux la light documentation (éventuellement agrémenté de 2 ou 3 belles photos :wink: )
Pour ce qui est de poster dans la mauvaise catégorie (et tu m’a déjà fait cette remarque :smiley: ), je n’ai toujours pas compris le fonctionnement de la nouvelle communauté (même si ça fait quelques temps que nous avons changé de site)

Voici la config :

  • Ethernet branché :white_check_mark: (IP fixe)
  • Pass du SSID (du KLF) :white_check_mark:
  • Pas d’espace dans le nom :white_check_mark:
  • Commandes à utiliser pour allumer et éteindre le KLF200 :white_check_mark:

Je pense ne rien avoir oublié, et j’ai relu à plusieurs reprises pour être sûr …

J’ai ensuite utilisé ma KLR pour récupérer les volets.

Le log des deps :
klf200_dep.log (6,8 Ko)

Le log général :

  • au long de la journéee :
    klf200.log (47,9 Ko)
  • à l’éxécution du scenario de fermeture (ce soir) => bilan seulement le 0 & 3 étaient réellement fermés.
    klf200_2.log (49,6 Ko)

J’ai tenté de voir si ma version de Python était bonne, si la version du pyvlx était OK (j’ai lu que la 0.2.16 semblait meilleure, mais pour moi ça n’a rien changé, et elle se remet en .19 à l’upgrade)
Je ne lis pas de message d’erreur particulier.

Cependant, dans les logs les rollers ne se mettent pas à jour, une fois ça fonctionne, et après le système se déconnecte, et après « KLF200 has been restarted after found not responding » many times …

Mon log ressemble souvent à cet article (le premier). Du coup, je coupe la prise, et je rallume.
https://community.jeedom.com/t/klf-200-ne-cesse-de-redemarrer-pour-nimporte-quelle-action/71647
Et j’ai souvent eu tous les petits symptômes des différents intervenants, d’où mon idée de condensat.

Pour ma part, je suis sous Jeedom depuis 6 ans, j’ai migré sur une VM Buster depuis 2 ans, en version 4.1.28 Stable.
Je maitrise l’informatique (architecture), mais pas forcément toutes les spécifications du Dev (et surtout Python). J’ai appris depuis ces années le fonctionnement, mais pour ceux qui arrivent et qui se disent « c’est du tout cuit » … Aïe
C’est pour cela que la finalité, si c’est possible serait d’améliorer la doc, et condenser les tips (ou vérifications primaires) dans celle-ci.

Merci en tout cas pour votre aide.

Hello,
et Merci Lunarok d’être passé par là.
C’est au fur à mesure de mes lectures que j’ai vu que des livraisons étaient plus fonctionnelles en bêta.
Mais sans compter que peut être la lecture était plus ancienne que le passage de la bêta en Prod :wink:
En tout cas, Merci pour le dev, et peut être que mes interrogations, pourront aider d’autres personnes, et permettront peut être une amélioration (le cas échéant) de la documentation.

Bonsoir, ça ressemble vraiment au soucis que j’avais.
Relance les dépendance pour que les bonnes versions soit installées des paquets de python.

Enlève la commande de la prise télécommander .
Coupe jeedom
Coupe le klf.
Redémarré le klf et redémarre jeedom.
Fait une commande d’ouverture ou fermeture pour initialiser la com

Tu peu après remettre les commandes de ta prise .

Un apt-get upgrade ne touche pas au paquet python ( à moins que tu ne le fasse dans python ^^)

Je n’ai pas eu de déconnexion depuis la beta.

Après tu as du voir que quasiment tout les projets sur cette interface sur github se heurte aux même problème de non stabilité.

Bonjour,
et Merci pour tes conseils.
J’ai eu fait plusieurs fois pendant mes tests, la relance de dépendances, et je sais que c’est souvent la que ça pêche, mais cette fois-ci, il a semblé mettre des choses à jour.
klf200_dep.log (10,0 Ko)
Il semble y avoir quelques erreurs, cependant je ne sais pas si c’est gravissime pour le fonctionnement.

J’avais aussi bien assimilé dans mes lectures que le produit était plus ou moins stable, cependant que je lisais le nombre d’utilisateur à avoir franchi le pas, je pensais bien qu’il y avait une réelle utilisation, mais basique (ouvrir, fermer, renvoi du statut).
Là, j’avais de temps en temps une des trois qui fonctionnait… ou pas.

Pour conclure, avec tes informations, je peux dire que ce matin, cela fonctionne plutôt bien.
Avec cette prescription, il a retrouvé ses petits. Il donne les bonnes valeurs, et il fait les actions.
Reste plus qu’à mettre en forme, dans le design adéquat.
image

Par contre, quid en cas de reboot de Jeedom ? Lors de la sauvegarde de la VM par exemple.
Est ce que le KLF doit toujours être allumé avant Jeedom ?

Autrement @lunarok, ce serait ce petit Tips qui serait intéressant dans la doc.
Je ne pense pas l’avoir lu avant, et ça répond au besoin : comment faire fonctionner l’équipement.

A voir si dans les jours ou semaines à venir, ça continue de tomber en marche.
Merci, encore !

Pour avoir tester encore une fois HA le mois dernier, je te confirme ce point. Eux proposent meme de rajouter une « automation » qui fait un restart du KLF quand HA redémarre, sinon perte du controle
Ce qui revient à la prise commandée, mais en moins universel.

Les erreurs ont l’air de venir de ton linux

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.