C’est une mise a jour des voisins qu’il faut faire et non l’action de soigner un noeud ?
Et tu proposes de faire :
Mise à jour des voisins d’un noeud
Réveil des modules qui dorment
Attendre 1mn / observer les logs
Redémarrage du daemon zwave
Recommencer …
Tu te rends compte du temps à consacrer à l’opération s’il faut redémarrer le daemon zwave à chaque mise à jour des noeuds ? J’ai mal du comprendre
Question : si par hasard j’opère ces opérations de soin massivement depuis une nouvelle VM debian stretch + Jeedom V4, est-ce que ça sera ok pour rebrancher la clef sur le jeedom actuel car c’est la clef qui stock tout ?
Derrière « Soigner le noeud », je ne sais pas quelles sont les opérations effectuées. Ça ne mange pas de pain de le faire. Si tout les paramètres sont présents, un petit « Rafraichir les valeurs du noeud » ne fait pas de mal non plus. Pour la mise à jour des voisins, tu peux en faire 2 ou 3 à la fois ou plus, mais trop à la fois, cela peut planter aussi le réseau.
A toi de voir ce qui va le plus vite, mais quand le réseau est planté, la mise à jour des voisins peut ne pas être finie à ce moment là. Oui, ce sera long. Moi je ne compte plus les semaines que j’ai passées à nettoyer, opérer, soigner, panser, surveiller le malade, analyser sa maladie !
Oui, c’est la clé qui stocke tout. Mais avec un réseau tout clean stocké dans la clé, ce ne sera pas clean dans un nouveau Jeedom au début. La synchro vers Jeedom peut être galère, comme précisé plus haut, ou il faut rentrer dans équipement faire un Sauvegarder pour faire bien la correspondance avec l’ID, Puis faire rafraîchir les paramètres dans Configuration. Du boulot en plus, donc je te conseillerais d’effectuer les opérations directement sur ta version finale de Jeedom pour ne le faire qu’une fois.
Ben comme apparemment avec ma Debian Buster + Jeedom V4 je n’arrive pas à soigner noeud par noeud sans qu’à un moment donné le processus délire irrémédiablement, je ne vois pas trop comment le faire sur un Jeedom prêt à l’emploi c’est à dire avec plugins, scénarios, design, widgets.
Je pense que l’idée de @Mav3656 c’est de partir d’une fresh installation sans rien dessus pour vérifier si le fait de soigner pose problème. Ça permet de s’assurer que le matériel n’est pas en cause (VM sur QNAP + clef USB zwave). C’est vrai que si ça fonctionne à ce stade alors on pourrait sûrement en déduire que c’est l’un des plugin/widget qui viendrait interférer et planter le processus.
Maintenant ça peut aussi visiblement venir d’un module au vu de l’expérience du post Juste pour comprendre :) qui s’est terminé par un défonçage du module à la pioche
Je ne sais pas si tu peux sauvegarder ta clé comme la Aeotec, faire un reset de ta clé, puis réinclure quelques modules pour voir si le réseau tient
Si ça fonctionne, tu es bon pour les inclure un par un et voir ce qui ne vas pas à un moment donné. Bon ce sera encore plus long que la mise à jour des voisins…
Oui, si tu arrives à savoir lequel, tu peux toujours l’exclure du réseau temporairement.
Concernant le message de @BizZ62 , ah oui, j’ai adoré son coup de pioche et j’ai bien rigolé
J’ai utilisé le logiciel de Sattaz (Zwave Cloner) et j’ai effectivement pu backup la clef.
Je suis en train de refaire une VM avec une installation Debian 9.12 pour poser un Jeedom V4 dessus afin de synchroniser la clef et voir ce que ça donne juste avec le plugin zwave.
Mais sinon bonne idée … le reset de la clef se fait via Jeedom ici ?
Branchement du dongle zwave sur rallonge USB pour l’éloigner des perturbations NAS et BOX opérateur (wifi)
Nouvelle VM sur NAS QNAP fraichement installée en 9.12 ( donc Stretch)
Nouveau Jeedom V4
Voila ensuite mon mode opératoire :
Stopper la VM et monter la clef
Démarrer la VM, installer le plugin zwave, installer les dépendances
Régler le port pour pointer sur le device /dev/ttyACM0
Reveiller les 2 périphériques sur pile. « network ready » dans Jeedom
Action « Synchroniser » pour faire remonter les modules de la clefs dans Jeedom
A chaque action attente que la queue soit à 0 et que le CPU ne soit pas/plus à 100% durant plusieurs secondes :
mise à jour des routes du contrôleur (dongle zwave)
soigner noeud :
2 oui : ok
3 non (sur pile)
4 non (sur pile)
7 non (précédemment inclu mais actuellement éteint)
9 non (précédemment inclu mais actuellement éteint)
12 oui : ok
18 oui : ok
19 oui : ko … Queue 1 et CPU 100% depuis maintenant plus de 12mn. Voilà c’est à nouveau mort.
Je peux difficilement faire plus propre ou plutôt on va dire que pour moi ça ne servirait à rien de faire plus chiadé. Je travail dans l’informatique et, si avec ce process je n’obtiens pas un résultat sans erreur c’est que l’un des maillons est défaillant (car le système doit forcement accepter de la tolérance sur les actions sinon ça ne fonctionnerait pour pas grande monde) :
Le système de VM sur QNAP avec sa gestion des ports USB et dans cette version
Mon dongle zwave Vision ZU1401-5
Debian 9.12
Jeedom V4
OpenZwave
Comme ça se saurait si Debian 9.12 était une daube, ça doit pas être ça
Comme pas mal de personnes disent ne pas avoir de problèmes avec Jeedom V4, ça doit pas être ça
Comme énormément de personnes utilisent OpenZwave et disent ne pas avoir de problèmes avec ça doit pas être ça
Bon il me reste la partie matériel : le dongle ou le système de VM avec QNAP et la gestion de l’USB et là je n’ai pas vu grand monde me dire qu’il était dans le même cas et que tout allait bien pour lui !
Je pense que le test suivant c’est de recommencer la même chose en montant une VM sur mon PC fixe (VirtualBox) et en branchant la clef dessus n’est-ce pas ?
C’est quoi ton module 19 ?
Si tu redémarres le réseau Z-Wave sans rien faire ensuite, comment se comporte-il ?
Il est bien ton test. Que disent les fichiers log ?
Imagine ceux qui ne sont pas dans le domaine… Je trouve que ce n’est pas normal de galérer autant.
J’estime qu’il n’y pas de tolérance, si ce n’est pas clean, ça bug, si trop d’actions Inclusion/Exclusion/Soigner le réseau/Mise à jour des voisins, ça plante le réseau au bout d’un moment. Il faut en prendre soin comme pas possible de ce p*t**n de réseau Z-Wave.
Nouvelle VM sur PC fixe avec VirtualBox avec une Debian 9.12 (Stretch) fraichement installée
Nouveau Jeedom V4
Mode opératoire :
Stopper la VM et monter la clef
Démarrer la VM, installer le plugin zwave, installer les dépendances
Régler le port pour pointer sur le device /dev/ttyACM0
Reveiller les 2 périphériques sur pile. « network ready » dans Jeedom
Action « Synchroniser » pour faire remonter les modules de la clefs dans Jeedom
A chaque action attente que la queue soit à 0 et que le CPU ne soit pas/plus à 100% durant plusieurs secondes :
mise à jour des routes du contrôleur (dongle zwave)
soigner noeud :
2 oui : ok
3 non (sur pile)
4 non (sur pile)
7 oui : ok
9 non (précédemment inclu mais actuellement éteint)
12 oui : ok
18 oui : ok
19 oui : ok
20 oui : ok
21 oui : ok
22 oui : ok
23 oui : ok
24 oui : ok
25 oui : ok
26 oui : ok
27 oui : ok
28 non (précédemment inclu mais actuellement éteint)
31 oui : ok
32 non (précédemment inclu mais actuellement éteint)
36 oui : ok 37 oui : ko !!! (j’y croyais pourtant) … restart du daemon zwave
Après le restart :
38 oui : ok
Du coup je retente le 37 … 37 oui : ko !!! (purée alors c’est ce module qui fou la bazar !?.. restart du daemon zwave
Je vais voir à quoi il correspond, c’est un FGR-223 pour un volet roulant.
Je vais sur le module, je refresh les paramètres pour voir s’il arrive à récupérer des infos … apparemment oui les valeurs remontent bien. Je retente de le soigner … 37 oui : ok !
BILAN :
J’étais presque à la fin des actions pour soigner les noeuds donc j’étais vraiment en train de me dire que c’était un problème avec le NAS QNAP (même si forcement mon PC fixe n’est pas au même endroit que le NAS) quand le problème s’est produit … et à 2 reprises sur ce module 37.
Alors du coup je pensais que c’était ce module qui buguait, oui mais c’est sans compter sur le fait que finalement il a fini par réussir à le soigner
Je suis un peu déboussolé du coup et ne sais pas trop quoi en penser. La clef zwave ne me semble pas en cause pour le coup.
Je n’ai pas essayé à plusieurs reprise, hier, sur la VM toute propre du QNAP mais en tout cas le bug s’est présenté bien plus rapidement que sur mon PC fixe.
Je suppose que ta clé n’était pas au même endroit. Attention, la table de routage est donc bien différente. Ce qui oblige à tout remettre à jour : les voisins, la route au contrôleur. La clé peut effectivement mieux fonctionner à certains endroits du logement. Pour comparer, il faut que la clé reste au même endroit.
Donc ce n’est pas le module 37 ni le 19, on en vend tellement que ça se saurait sinon! À un moment donné, ils finissent par fonctionner.
Donc ce n’est pas ta VM, ni Debian 9.12, ni Jeedom V4, ni ta clé Z-Wave.
Entre le PC fixe et le QNAP, c’est difficile de juger… Je pense que tu devrais avoir moins de souci avec le PC fixe car QNAP n’est pas prévu pour faire tourner Jeedom.
On voit bien que les problèmes ne sont pas francs. Tu as pris le temps de faire des installes propres. Un coup, c’est le module 19, ensuite c’est le 37, puis ils sont ok, la queue sortante reste bloquée, le réseau plante, on redémarre et ça repart, on ne comprend pas pourquoi. Je ne pense pas que ce soit un problème matériel avec les modules sinon les erreurs seraient plus récurrentes et systématiques. Je pense que c’est openzwave qui ch*e dans la colle !
Hier j’ai remis ma clef sur le QNAP via la rallonge et refais la petite séance de soin des nœud, un par un et en observant à chaque fois.
Ce que j’ai remarqué c’est que le fait de faire une récupération des paramètres avant un soin ne garantissait pas du tout le succès de l’opération de soin.
J’ai suivi le même processus que ce que j’avais fais au dessus. J’ai été obligé de restart le daemon 8 fois pour arriver au bout ! Donc c’est clair que ça marche moins bien sur le NAS QNAP que sur mon PC fixe
Je me lève ce matin … Queue supérieur à 0 : reboot du Daemon obligé.
Je crois qu’il va falloir que je m’achète un mini-pc pour mettre un proxmox dessus et une Debian de PROD avec Jeedom afin de stabiliser tout ça !
J’ai regardé hier afin de trouver un mini-pc avec 4 cœurs, 8G de RAM et un SSD de 64G ou 128G. Config qui me semble être plutôt normal pour le besoin.
Il n’y a pas grand chose vers les 150-200€, voir rien.
En terme de CPU, est-ce que l’on peut raisonnablement prendre des Celeron Jxxxx ou faut-il taper dans les I5/I7 au risque de ne rien trouver à moins de 500€ ?
Salut,
Par curiosité, tu as cherché tes miniPC où?
Le mien m’est revenu à moins de 200€ sur ali (I5, 4 coeurs, 8Go).
Certes il faut attendre un peu mais la qualité et le rpix en valent la peine.
J’avais une SSD dans un coin.
Il faut une mSata. Tu peux la prendre avec ou sans mais le prix est très ns, moins de 30€.
Les machines que tu achètes sur Amazon viennent des mêmes fournisseurs en plus chers.
En plus, tu peux leur demander toutes les options que tu veux, wifi ou pas, la ram que tu veux, … Tu peux même faire graver ton nom.
Je confirme de nouveau cette collision mal gérée entre un module sécurisé et non sécurisé.
J’ai eu plusieurs fois le coup dans différentes pièces d’un Fibaro Dimmer 2 non sécurisé (Node045) qui n’arrive pas à s’allumer lorsqu’un Fibaro Door Sensor 2 sécurisé (Node024) est en train de communiquer.
Les collisions sont assez rares, mais elles arrivent par exemple lorsque je rentre dans une pièce et que j’en ressors aussitôt en fermant la porte de la pièce. En effet, le temps que le scénario se lance et envoie l’ordre au Dimmer 2 d’allumer la lumière tombe pile, à la milliseconde près, en même temps que le capteur de porte qui envoie son état.
Donc les collisions sont plus fréquentes statistiquement lorsque le nombre de modules sécurisés augmente, cela confirme que :
Pour ceux qui ont un réseau globalement sécurisé et qui fonctionne sans souci, j’attends une démonstration avec des preuves.
À un moment donné, ils finissent par fonctionner.