Merci pour ton intervention.
En effet, il s’agit d’introduire de la robustesse pour fiabiliser mon installation. Nombreuses sont les fois où des modules a piles ont arrêté de communiquer sans remonter l’information de pile faible. Inversement certains modules ayant remontés l’information pile faible fonctionnent des mois durant encore par la suite. L’implémentation de mon script est donc basée sur les constats suivants :
la remonté d’information des piles (algorithme de conversion tension / pourcentage à charge du fabricant du module) n’est pas fiable
il devient intéressant de surveiller les réveils de ces modules
un module sans wake-up (ex : FLiRS a pile) n’a pas de notion de réveil et ne peut cesser de fonctionner à tout moment (ref point numéro 1)
un module FLiRS n’ayant pas de wake-up, je me sers de la méthode « public » officiellement disponible et documentée « hasNodeFailed » pour tester si un noeud est en échec (lorsque j’enlève la pile du module FLiRS, il passe DEAD suite a l’exécution de mon script)
j’ai étendu ce principe au noeud secteurs.
Jusque là je t’ai décrit mes raisons de faire appel a cette commande. Ce n’est pas pour implémenter mon script que j’ai demandé de l’aide ici, mais en proposant ce script exemple de 3 lignes, je pense mettre en évidence l’instabilité constatée a la maison.
Je ferai tourner ce code exemple quand j’aurai un peu de temps devant moi pour confirmer ou infirmer mon hypothèse. Dans cette attente, j’ai partagé mon expérience ici avec des personnes qui semblent avoir rencontré des difficultés similaires, en e attaquant également le serveur REST.
En tant que profil expérimenté, as tu déjà rencontré cette difficulté "queue zwave qui s’incrémente et processus du démon Z-Wave utilisant un coeur CPU en permanence ?
Bonne journée a tous,
Pierre (Mav3656) - Helper Officiel Jeedom.
Édit : il est tout a fait normal qu’à ce temps d’intervalle le serveur REST réponde une alternance de OK/KO sur la bonne prise en compte de la requête, la requête étant traitée ensuite de manière asynchrone et prenant un certain temps a s’exécuter. En revanche, planter le démon n’est pas le comportement attendu.
On dirait que ca a eu l’effet inverse, c’est mon point.
De manière général (pas que sur zwave ni que sur jeedom), un des plus sur moyen de faire crasher un système et de l’empêcher de se rétablir c’est de le spam avec des requêtes (pour vérifier si tout va bien), tu te fais juste un DOS à ton système, tout seul.
Je ne comptais absolument pas travailler sur ce script et je pense que tu n’as pas besoin de faire ton test: le système va probablement crash en recevant une requête toute les dixième de seconde.
juste pour info, le plugin aussi utilise le serveur REST du démon; il ne crash pourtant pas chez tout le monde
Oui, j’avais rencontré ce problème après avoir un nombre « important » de modules (jamais au début avec 10-20 modules, seulement plus tard avec 40-50 ou plus) lorsque je tournais sur smart ou sur pi, je n’ai plus jamais eu ce problème depuis que je suis sur une vm (plus de cpu etc).
Cependant je ne peux pas être certain que c’est dû au changement de machine, il y a eu d’autre mise à jour entre temps etc, le contexte a changé et donc on ne peut pas tirer de conclusion.
J’ai tous les 10 jours environs la queue zwave qui monte (quasiment à 10000). J’ai pour l’instant trouvé une solution rapide, je désactive quelques nœuds (je coupe les fusibles) … j’attends que ça revienne à 0 et hop je remets.
Y aurait il une méthode pour savoir facilement si j’ai un nœud qui merdoie et si il faut le remplacer ?
Merci d’avance
je sais pas trop, j’avais ouvert un ticket
il faut passer le plugin en mode debug et il y a des logs openzwave, il faut regarder si un module revient très souvent, j’avais eu ce problème pour un module qui parlait trop et donc chargeait le zwave qui n’arrivait plus à gérer les demandes, mais il peut y a voir plusieurs type de problème
je viens de relancer le démon zwave et je pense que maintenant cela va tourner sans soucis, mais pourquoi suite à une maj ou à un reboot de là smart, il part en cacahuète ?
Pour avoir ce phénomène de queue qui plante sur mon Jeedom hébergé sur une VM d’un NAS QNAP j’ai souvent remarqué avoir très régulièrement le soucis dans les heures qui suivent un reboot du daemon (le soir, ou dans la nuit).
Bizarrement si ça arrive à passer un cap, après je suis tranquille un bon bout de temps.
je me permet de relancer ce sujet car j’ai exactement les mêmes logs que toi, pour ma part mon réseau zwave est très lent il est pourtant bien maillé (j’ai plus de 40 modules 100% Fibaro aucuns sur piles.) et je constate souvent lors de commandes tout éteindre que certains modules restent allumés, lorsque je regarde les logs je vois que les commandes ont étés envoyés…
Quelqu’un pourrait il m’expliquer a quoi corresponde ces erreur :File /usr/lib/python2.7/threading py , line 789 in__bootstrap_inner
del _limbo self?
J’aimerai vraiment comprendre.
merci de vos réponse, je suis en train de mettre à jour ma distribution, mais je doute que cela apporte un réel bénéfice au niveau du plugin zwave…
Je suis un pro qui est en train de migrer son parc (lifedomus) sous jeedom et je commence a me poser des questions quand à la stabilité du zwave sur cette box…
Même si la grande majorité de nos clients sont en knx.
J’entends bien mais, d’une part ça ne peut pas faire de mal, d’autre part le message fait référence à un problème python. Alors qui sait.
Sinon, de mon côté mes z-wave tournent comme une horloge. Plus de 60 modules avec un mixte de secteurs et piles.
J’utlise un bloc code, celui de @Nemeraud, afin de pinguer régulièrement, toutes les 6 h, tous les modules et vérifier ainsi s’il y a en des death.
Voici mon petit retour d’expérience… J’ai une SMART avec 106 modules… plus de 60% de modules sur secteur. La maison est grande avec des murs épais mais j’ai des modules secteur un peu partout.
Quand je redémarre mon pluggin ZWAVE, j’ai souvent le statut « Drivers initialized » qui prend des plombes avec une queue qui ne cesse d’augmenter. Maintenant, au bout d’une demie heure, je redémarre le pluggin. Ca m’arrive de le faire 3 ou 4 fois parfois puis le coup suivant, nickel, Topology Loaded en 5-10 minutes !!!
Ensuite, je soigne le réseau un petit coup, la queue ré augmente mais revient vite à 0
Une fois que nous sommes en Topology Loaded, ca semble gagné. Si la queue se met à augmenter, elle finira toujours par redescendre. Hier soir, elle est montée à 800 voire 900. J’ai cru que c’était encore plié. J’ai laissé faire et ce matin, nickel, tout fonctionnait très bien
Donc pour conclure et me concernant:
quand ça dure et que la queue augmente en « Drivers initialized », ca peut ne jamais aboutir (j’ai parfois attendu plus de 24H pour voir) donc maintenant, je redémarre au bout de 30 minutes. Et ce jusqu’à ce que j’arrive en « Topology Loaded ». Sûrement un device qui pose problème. La question est pourquoi cela finit par passer !!!
Quand la queue augmente en "Topology loaded ", cela abouti tout le temps
Tout cela est basé sur mon expérience et sur ma config
À éviter justement. Si les modules n’ont pas changé de position, on ne clique sur rien.
On soigne le réseau une seule fois.
On attends que tous les modules se réveillent au moins une fois
On redémarre pour finir la mise jour des voisins.
On attends que tous les modules se réveillent au moins une fois.
Autres conseils, ne pas cliquer partout dans le plugin openzwave. J’ai commis les mêmes erreurs au début, je pensais que la domotique allait aussi vite que moi. Ben, non !
Et quand ça marche, on ne touche plus. Surtout : AUCUNE « action pour la route »
ok merci pour vos retours
Je comprends donc que l’on soigne le réseau une seule fois et que ça n’est pas la peine de le faire après chaque redémarrage du pluggin si rien n’a bougé, right ?
Là, je suis parti pour un long périple, j’ai 6 modules fantômes à supprimer (4 qui dataient un peu et dont je ne m’étais pas trop occupé et 2 récents, tous des fibaro Door sensors 1ere génération)… donc je me donne le WE pour arriver à les supprimer… dommage que l’on ne puisse pas les supprimer tous en même temps et qu’il faille redémarrer à chaque fois le pluggin !!!
Sinon j’ai parcouru l’analyse de Domatizer, du super boulot, rien à redire J’ai pas mal de Door Sensors et de Motion Sensors de chez Fibaro… je pense que ca explique mes temps de démarrage…
Dommage tout de même que nous ayons à envisager de telles manips pour que cela fonctionne mieux
Sinon auriez vous une idée du pourquoi à chaque redémarrage du pluggin, il restore un fichier de conf XML qui date (j’ai créé un autre post sur ce sujet) ?
Bonne journée et encore merci
