soigner le réseau

[Patdec]

Bonjour, je voudrai faire un scénario pour que le réseau se soigne automatiquement toutes les 3h00, je vais essayer de faire ça pendant 1 semaine, comment est ce que je peux faire ?

Ton bonheur est peut être là ?

[Nik0]

Bonjour et merci de m'avoir répondu, j'ai vu le bout de code mais justement quelqu'un en parle à la fin et n'a pas eut de réponse sur la manœuvre à suivre pour soigner le réseau
le lien vers la doc du plugin est mort : https://jeedom.github.io/documentation/ ... index.html
et il n'y a rien là dessus dans la nouvelle doc du plugin : https://jeedom.github.io/plugin-openzwave/fr_FR/

[Mav3656]

Bonjour, je voudrai faire un scénario pour que le réseau se soigne automatiquement toutes les 3h00, je vais essayer de faire ça pendant 1 semaine, comment est ce que je peux faire ?

Bonjour @Nik0,

Tu trouveras des informations de valeur pour réaliser cela à cet endroit : https://nechry-automation.ch/2018/06/07/api-restful/

@nechry explique très bien l'ensemble des mécanismes à comprendre pour se servir de l'API REST proposée par le plugin zwave de Jeedom.

Cependant, je te déconseille très fortement de soigner le réseau toutes les 3H. Il faut soigner le réseau lorsqu'on en modifie la topologie (exemple : lorsqu'on déplace un élément, ajoute, supprime ou remplace un module, ou encore si tu modifie l'environnement dans lequel opère tes modules, si tu fais des travaux, ou déplace des meubles par exemple). En production, et lorsque la topologie du réseau n'est pas modifiée, un réseau zwave n'a pas besoin d'être soigné.

Autre information à prendre en considération, lorsque tu soignes le réseau, l'opération démarre lorsque tu cliques sur le bouton et se déroule immédiatement avec les modules secteurs présents sur le réseau. L'opération se terminera lorsque le dernier module a pile se réveillera (potentiellement donc dans plusieurs heures, sauf si tu réveilles toi même tes modules sur pile).

Remarque : il te faudra réveiller manuellement les modules sur pile si tu as désactiver leur réveil.

La ou je veux en venir, c'est que si tu relances une action de soigner le réseau toutes les 3h, tu risques de relancer une action pour soigner le réseau alors que la précédente action n'aura même pas pris fin.

Pire encore, lorsque tu soignes le réseau, le réseau se retrouve, tant que l'opération n'est pas terminé, dans un état instable car tous les modules n'ont pas des informations cohérentes sur les routes à utiliser. Tu risques donc finalement de toujours rester dans un état instable sur ton réseau et faire plus de mal que de bien.

L'action de soigner le réseau est donc à utiliser, oui, mais lorsqu'elle est nécessaire.

Autre information : de mon expérience, il faut redémarrer le démon du module zwave pour que Jeedom renvoit les dernières informations connues à tous les modules. Comme tous les modules ne se mettent pas à jour simultanément, les premiers modules qui auront été mis à jour ne disposent pas des informations sur le routage qui arriveront par la suite. Et ils n'en disposeront jamais si l'on ne fait rien de plus. Redémarrer le démon permet de rejouer l'interview avec l'ensemble des modules, et qu'ils soient tous bien à jour ensuite.

Ce dernier point est mis en évidence lorsque la table de routage n'est pas symétrique. Autrement dit un module prétend avoir dans la liste de ses voisins un autre module, mais la relation n'est pas réciproque. L'un des 2 a raison, et l'autre se base sur une information obsolète.
Lorsque la table de routage Zwave est asymétrique, l'objectif est de mettre à jour la "liste des noeuds voisins", des noeuds qui sont concernés par cette dissymétrie. L'autre solution, qui permet que tout rentre dans l'ordre, et en réalisant une seule action simple, c'est de redémarrer le démon Zwave, comme expliqué ci-dessus.

[Nik0]

Bonjour mav3656 et merci pour toutes tes explications, c'est beaucoup plus clair ! Je me sentais vraiment dans l'impasse ! Je relance donc le demon en continue pour que les routes se mettent bien a jour, j'ai fait ça tout le we, et deux modules ont enfin été bien intégré, j'espere que ça va continuer avec tous les autres ! Je te remercie pour tout !

Envoyé de mon SM-G950F en utilisant Tapatalk

[Mav3656]

Bonjour @Nik0,

Un seul redémarrage suffit. Après redémarrage, attend 24h, dis-nous si tu observes encore des problèmes, si oui lesquels, et n'hésitez pas à nous mettre une screenshot de ta table de routage qu'on comprenne un peu mieux dans quelle situation tu évolues.

Tu peux également mettre une screenshot de l'écran santé, il fournit un résumé de qualité sur l'ensemble de la configuration Z-Wave de tes modules.

Un redémarrage peut prendre plusieurs minutes selon le nombre d'équipements que tu as et la qualité de ton réseau. Lorsqu'un démarrage est terminé, tu vois combien de temps il a mis à opérer en cliquant sur "Réseau Z-Wave" dans l'onglet "Résumé", tout en haut.

Tout le temps que le démon démarre, puis que le réseau Z-Wave s'initialise en échangeant un certain nombre d'information, autrement dit tant que ton réseau n'a pas atteint l'état "Topology Loaded" ou "Started", il est dans un état instable. Ainsi, il faut le redémarrer uniquement lorsque c'est nécessaire.

Bonne journée.

[Nik0]

Tout d'abord, je te remercie encore pour ton aide precieuse, c'est vraiment sympa de bien vouloir te pencher sur mon problème parceque je me sentait vraiment dans l'impasse sans plus savoir quoi faire !

Pour moi, il y a quelquechose qui cloche, la liste des nœuds voisins ne se met pas du tout à jour de façon normale.
elle reste la même qu'à l'inclusion et c'est d’après moi pour ça que ça ne fonctionne pas correctement.

tu trouveras ci-joint, la carte des nœuds qui sont dans mon installation :
avec de haut en bas RDJ - RDC et R+1

2019-08-19 - Carte des noeuds.pdf

(355.11 Kio) Téléchargé 42 fois

la liste des nœuds dans l'état de santé :

capture 01.PNG (117.7 Kio) Consulté 4721 fois

Capture 02.PNG (69.45 Kio) Consulté 4721 fois

j'ai bien un server ready et topology loaded.
et si je prend l'exemple du nœud N°57 qui devrait avoir pour voisins les noeuds 33 - 59- 64
au lieu de ça, il pense qu'il est dans la cage d'escalier et affiche des voisins à pile ( les sirenes de l'alarme )
qui sont 51 - 52 - 53 - 55 - les mêmes noeuds a coté desquels il était lors de l'inclusion
du coup, je ne sais pas si l'information passe par ces nœuds lorsque je veux allumer l'éclairage mais ça fonctionne 1 fois sur 10

[Nik0]

je réécris un post parceque je suis limité à 3 pieces jointes par post :
je viens de voir ce paramètre : est ce que ça ne résoudrai pas tous mes problèmes de le décocher ?
apres ça parle du jeu de configuration pas des nœuds voisins ...

[Mav3656]

je réécris un post parceque je suis limité à 3 pieces jointes par post :
je viens de voir ce paramètre : est ce que ça ne résoudrai pas tous mes problèmes de le décocher ?
apres ça parle du jeu de configuration pas des nœuds voisins ...

réponse rapide pour ce post : non, cela n'a rien à voir. Il s'agit bien comme tu l'as souligné de paramètres recommandés par l'équipe Jeedom.

Je ne vois pas la table de routage. Est-il possible de nous la montrer ?

Je devine toutefois ton problème à ce que tu as écris concernant le noeud qui connait ses voisins lors de l'inclusion et qui ne se met pas à jour.

Hypothèse :
Tu inclus le noeud à un endroit, ou il est en mesure de communiquer avec les noeuds 51, 52, 53 et 55, puis tu le déplaces à un endroit où il ne peut plus communiquer avec aucun de ces noeuds là.......Il ne peut donc pas recevoir l'action de mise à jour des noeuds voisins ! En effet, peut-être que toi tu sais qu'en passant par les noeuds 33, 59 et 64, ton noeud pourrait communiquer correctement. Mais le réseau Z-wave ne le sachant pas, il ne fera pas ces tentatives.

Ce que tu sais déjà : lorsque tu inclus un noeud, il doit être à porter du contrôleur initial.

Ce que tu sais peut-être : Dans l'implémentation de la librairie "OpenZWave", l'inclusion se fait à pleine puissance, même en mode sécurisé. C'est bien dommage d'un aspect sécurité, cependant, ça a l'avantage de pouvoir placer le module à son emplacement définitif dans bien des cas pour en faire l'inclusion, sous réserve qu'il arrive à communiquer directement avec le contrôleur. A noter que je suis foncièrement contre ce comportement, faisant passer la sécurité après le côté pratique. Mais c'est pas comme si on m'avais consulté. C'est un problème récurrent en domotique d'ailleurs....

Ce dont il faut que tu tiennes compte lorsque tu positionnes un noeud à son endroit définitif : le module peut communiquer via un certain nombre de routes possibles (celles définies à l'inclusion). Il faut qu'il puisse communiquer, au moins par une route, lorsque tu l'éloignes pour le mettre à sa position définitive. Si ce n'est pas le cas, alors :
- il faut l'éloigner une première fois, sans le mettre à sa place définitive
- soigner CE NOEUD en particulier au sein du réseau (pas la peine de soigner tout ton réseau pour l'instant puisqu'il n'est pas à sa place définitive). - si ton noeud est sur pile, soit tu attends son prochain réveil, soit tu le réveilles manuellement pour ne pas avoir à attendre. Je te conseille de le réveiller manuellement une 2ème fois au moins pour être sûr que toutes les trames se sont bien échangées.
- regarde ensuite ta table de routage, si elle n'est pas symétrique, sois tu fais des "mises à jour des noeuds voisins" sur les lignes concernées pour que ta table devienne symétrique, soit tu redémarre ton démon Z-Wave (c'est + simple, même s'il faut attendre).
- à ce stade, tu dois avoir une table de routage symétrique. Tu répètes l'opération pour éloigner ton équipement vers son emplacement définitif autant de fois que nécessaire.

Bonne journée.

[Mav3656]

la liste des nœuds dans l'état de santé :
capture 01.PNG
Capture 02.PNG

Concernant les noeuds "Unknown", il faut également faire disparaitre ces noeuds pour remettre ton réseau Z-Wave dans un état stable. Ces noeuds peuvent apparaitre lorsqu'une inclusion se passe mal. Il y a de multiples raisons pour qu'une inclusion se passe mal (exemple : le noeud que tu essais d'ajouter n'a presque plus de pile et se comporte mal, ou s'il est en limite de portée, ou si il est défectueux, et bien d'autres encore...).

Pour cela, je te propose de commencer par supprimer les "équipements" correspondants depuis le plugin Jeedom. Lorsque tu les as supprimés, tu peux alors cliquer sur le bouton "synchroniser", et voir s'ils reviennent. Si ils reviennent, et je pense que ce sera le cas car tu as un petit numéro sur la ligne juste après le mot "unknown" dans l'écran de santé, il faut alors, noeud par noeud, les supprimer.

Pour cela :
- rentrer dans l'équipement en question
- cliquer sur le bouton configuration
- tu vas dans l'onglet des actions
- tu cliques sur "noeud en échec ?" pour faire passer le noeud en échec
- à ce stade, le noeud doit passer en échec.
- tu cliques ensuite sur "supprimer noeud en échec" et tu attends que le démon Z-wave redémarre complètement. (je crois qu'il redémarre quand tu fais ça).
- lorsque le démon a redémarré, ton équipement est toujours présent, mais dans l'écran santé tu n'as plus de numéro à côté de son nom.
- tu peux alors supprimer l'équipement. Il ne reviendra plus lorsque tu cliqueras sur synchroniser

Prends ton temps pour réaliser ces actions, et laisse le temps au démon démarrer et se mettre dans des états stable

A titre d'information, bien que tu n'as absolument pas besoin de comprendre ce qui suis pour résoudre tes problèmes, mais si tu souhaites approfondir tes connaissances :
- Le contrôleur ZWave possède la liste de tous les noeuds de son réseau. Il les connait par un numéro.
- Le plugin ZWave possède aussi la liste de tous les noeuds du réseau. On leur donne un nom, un objet, etc.
- le mapping entre les 2 est fait par le paramètre "Node ID".

ainsi, dans l'écran santé, si tu vois :
- une ligne, avec un nom, mais pas de numéro dans la colonne "Node ID" => C'est que le plugin Zwave a un équipement, mais qui ne correspond à aucun équipement réel connu par le contrôleur ZWave.
- une ligne, sans nom, mais avec un numéro => C'est que le contrôleur ZWave connait un équipement, mais que tu ne visualises pas dans le plugin. C'est pour solutionner ce cas de figure que le bouton "synchroniser" a été mis en place. Il va créer autant d'équipements dans le plugin ZWave que nécessaire.

Cas concret d'utilisation
- Quand tu supprimes un équipement dans le plugin ZWave, sans passer par "l'exclusion", il réapparait lorsque tu cliques sur synchroniser => Logique, il est encore connu du contrôleur lui même.
- Quand tu exclues un équipement, là il y a 2 possibilités.
1) Si tu as coché dans les options du plugin Zwave la case "Supprimer automatiquement les périphériques exclus" alors l'équipement est automatiquement supprimé du plugin ZWave
2) Si la case n'est pas cochée, alors il te reste l'équipement dans le plugin ZWave, mais le contrôleur ne le connaitra plus. Il faut alors supprimer le "Node ID" de l'équipement pour éviter les problèmes (en effet, lorsque tu ajoutes un nouveau module, le contrôleur associe le prochain "Node ID" disponible. A chaque fois, il incrémente de 1. mais arrivé à un certain nombre (236 je crois... car les valeurs suivantes sont réservées, à vérifier) il renumérote à partir de 0, en utilisant les valeurs disponibles. S'il n'y a plus de valeur disponible, tu ne peux plus ajouter d'équipement tout simplement. Prenons le cas où il réassocie le "Node ID" : "10" par exemple, si tu as conservé l'équipement dans ton Jeedom avec un binding sur le "Node ID" : "10", il va réutiliser ce même équipement et l'associer à ton équipement que tu viens d'associer, alors que les 2 n'ont probablement rien à voir !! Attention donc...D'où le conseil si tu gardes l'équipement pour conserver tes historiques par exemple, de bien supprimer le Node IDJ

Désolé pour le hors sujet, et bonne fin de journée !

[Nik0]

Merci pour toutes tes explications ! c'est parfait !
je vais faire comme tu as dit et vais reprendre les nœuds qui posent problèmes ! Merci !
tu trouveras ci-joint, la table de routage :
et oui, c'est bien ce que j'ai fait au sujet des nœuds, je l'ai inclus à un endroit pour ensuite le déplacer à un autre ...

capture 01.PNG (66.39 Kio) Consulté 4692 fois

Capture 02.PNG (69.45 Kio) Consulté 4692 fois

[Theking31]

C'est triste pour toi Nik0, surtout avec un réseau comme le tiens

Mais sujet très intéressant... Merci pour la leçon Mav3656


En espérant que tu résolve ton problème !

[Nik0]

j'ai donc procédé comme suis :
- réinclusion du noeud à coté de la clef puis redemarrage du démon puis test OK sur le noeud
- débranchage du noeud + positionnement au milieu de la maison à portée du contrôleur principal puis redémarrage du démon puis soigner le noeud et mise à jour des noeuds voisins
résultat : aucune mise à jour des nœuds voisins réalisées ... le contrôleur reste attaché aux nœuds avec lesquels il est à portée et comme il est à portée, rien ne se passe.
je le déplace ensuite à son emplacement définitif : il passe en death ....
rien ne va et à chaque fois que je fais de redémarrage du démon c'est 45 minutes, j'ai déjà essayé de le relancer plusieurs fois pour avoiir nune mise a jour des noeuds voisins, c'est juste l'enfer ...

[Mav3656]

Bonjour Nik0,

As-tu réussi à avancer sur le fonctionnement de ton réseau Z-Wave ?

Il est normal que tu observes des latences importantes. Le réseau Z-Wave met en œuvre des mécanismes simples, mais très puissant pour fiabiliser les communications. Il essaie toutes les routes possibles, et chacune d'entre-elles est essayée plusieurs fois, avant de conclure que la communication a échoué. Quand le réseau est bien configuré, je te laisse imaginer la robustesse d'une telle philosophie. Malheureusement, dans ton cas, il croit qu'il peut passer par des chemins alors qu'il ne le peut pas, et toutes tes communications prennent du temps à cause de ça.

Pour remettre les choses en ordre, je vois 2 façons de faire, les 2 te permettront d'arriver à tes fins (je te conseille de lire ce post en entier avant de choisir) :

• 1) Si tu arrives à avancer de cette manière, tu peux soigner nœud par nœud tes équipements.
  2) Tu peux faire un reset du contrôleur Z-Wave. Tu trouveras cette action parmi les actions générales du plugin, en cliquant sur "Réseau Zwave" puis en allant dans l'onglet "Actions".

Concernant la 1ère solution il faut être patient, car beaucoup d'attente (mais de moins en moins au fur et à mesure que tu remettras les choses en ordre). Je te conseille de commencer par les nœuds qui, selon toi, sont capables de communiquer en direct avec le contrôleur, tout en les laissant, à leur emplacement définitif. Ensuite tu continues avec ceux que tu penses capables de communiquer avec les nœuds qui sont déjà bien configurés.

Afin d'éviter de redémarrer ton démon (vu le temps que ça te prend), privilégie les actions unitaires de soigner un module au sein du réseau. Surveille que ta table de routage est symétrique, et si elle ne l'est pas, il te faudra "mettre à jour la liste des nœuds voisins" sur les lignes concernées.

A ce stade, tu auras donc reconfiguré assez facilement quelques modules. Pour les autres, ceux qui ne sont pas capables de communiquer avec le contrôleur, avec un peu de chance, ils seront capables de communiquer avec des modules que tu auras pu soigner à ce stade. Tu seras alors capable de les soigner, sans les déplacer. En dernier recours, tu devras les déplacer....

Concernant la 2ème solution, elle consiste à effacer toute la mémoire de ton contrôleur Z-Wave, tout en conservant tes équipements (et leurs historiques) dans le plugin.
Pour rappel :

- Le contrôleur ZWave possède la liste de tous les noeuds de son réseau. Il les connait par un numéro.
- Le plugin ZWave possède aussi la liste de tous les noeuds du réseau. On leur donne un nom, un objet, etc.
- le mapping entre les 2 est fait par le paramètre "Node ID".

Si tu ne souhaites pas conserver les commandes actuelles et les historiques de tes équipements, il te faut supprimer tous les équipements de ton plugin Z-Wave. C'est de loin le cas le plus rapide et simple.

Si tu souhaites conserver tes historiques :

• 1) Après avoir reset ton contrôleur Z-Wave, il faut impérativement que tu ailles dans chacun des équipements, pour supprimer la valeur du node-ID (tu peux ne rien mettre ou mettre -1).
  2) Tu inclus un nouveau module => Le plugin te créer un nouvel équipement "X" pour ce nouveau module. Tu regardes la valeur du node ID de l'équipement "X" et tu notes cette valeur (par exemple : "2").
  3) Tu attends la fin de l'inclusion de l'équipement : pour être sûr que l'inclusion est terminée, tu peux suivre les étapes en allant dans l'équipement "X", en cliquant sur le bouton "configuration", tu y trouveras quelques informations, dont "état des demandes".
  4) Lorsque l'inclusion est terminée, tu supprimes l'équipement "X". En effet, il ne te servira pas puisque vas réutiliser ton ancien.
  5) Tu vas dans l'équipement qui existes, celui que tu as gardé, et qui correspond au nouveau module que tu viens d'inclure dans ton réseau. Tu lui attributs ici le node ID que tu as noté à l'étape 2 (dans notre exemple : "2").

Attention : contrairement à la 1ère solution, pour pouvoir procéder à l'inclusion d'un équipement, il faudra que celui-ci soit suffisamment proche du contrôleur pour pouvoir communiquer directement avec lui. Si des modules ne peuvent communiquer avec le contrôleur depuis leur emplacement définitif, il te faudra les déplacer plus proche du contrôleur. Ensuite, il faudra que tu recule le module pour pouvoir le placer à son emplacement définitif, en suivant la règle que nous avons déjà évoqué ici :

Ce dont il faut que tu tiennes compte lorsque tu positionnes un nœud à son endroit définitif : le module peut communiquer via un certain nombre de routes possibles (celles définies à l'inclusion). Il faut qu'il puisse communiquer, au moins par une route, lorsque tu l'éloignes pour le mettre à sa position définitive. Si ce n'est pas le cas, alors :
- il faut l'éloigner une première fois, sans le mettre à sa place définitive
- soigner CE NOEUD en particulier au sein du réseau (pas la peine de soigner tout ton réseau pour l'instant puisqu'il n'est pas à sa place définitive). - si ton noeud est sur pile, soit tu attends son prochain réveil, soit tu le réveilles manuellement pour ne pas avoir à attendre. Je te conseille de le réveiller manuellement une 2ème fois au moins pour être sûr que toutes les trames se sont bien échangées.
- regarde ensuite ta table de routage, si elle n'est pas symétrique, sois tu fais des "mises à jour des noeuds voisins" sur les lignes concernées pour que ta table devienne symétrique, soit tu redémarre ton démon Z-Wave (c'est + simple, même s'il faut attendre).
- à ce stade, tu dois avoir une table de routage symétrique. Tu répètes l'opération pour éloigner ton équipement vers son emplacement définitif autant de fois que nécessaire.

Dans un réseau Z-Wave, seuls les noeuds secteurs participent au maillage du réseau Z-wave. Pour cette raison, je te conseille donc, quelque-soit la solution 1 ou 2 que tu choisisses de réaliser, de te concentrer dans un premier temps uniquement sur les noeuds secteurs. Lorsque tous les noeuds secteurs seront bien configurés, et à leur emplacement définitif, tu pourras alors t'occuper des noeuds sur piles.

Bon courage, et bonne journée, n'hésites pas à nous tenir informés

[Nik0]

Bonjour et merci pour ton aide de nouveau.
Quand je vois que tu parles de robustesse et de fiabilité du réseau, ça me rassure, parceque je commencais a perdre la foi
En redemarrant le demon plusieurs fois et en soignant le réseau petit a petit, je suis parvenu, à avoir quelquechose qui fonctionne à peu prêt ( mais c'est excessivement long )
Ma table de routage est symétrique, ce qui me gêne vraiment à l’utilisation aujourd'hui, c'est le temps que met un nœud a s'allumer après que la commande soit envoyée. Pour tous les noeuds qui sont en contact direct avec le contrôleur ça va, mais pour les autres, c'est plus compliqué ...
J'ai par exemple, le nœud 68, c'est celui qui me pose le plus de problèmes et qui est le plus loin du controlleur - environ 30m - avec des murs betons au milieu. Il communique correctement 1 fois sur 4.
Quand je regarde la liste des voisins, je remarque qu'il y a le controlleur 1 alors que cette route n'est pas bonne d'apres moi, maus surtout, je vois qu'il est voisin avec toutes les sirenes de l'alarme au milieu de la maison. Ces sirenes sont sur piles et "a l'ecoute" FlirS
http://manuals-backend.z-wave.info/make ... 8-12020009
Tous les noeuds qui ont des problemes de latences ( genre 5-10 minutes ) et qui sont éloignés ont ces alarmes dans les voisins,
Est ce qu'il serait possible de supprimer le routage pour ces alarmes, histoire qu'elles soient utilisées comme les quelques autres modules a pile qui sont dans mon reseau ?

Je vais essayer la premiere la solution, je ne me sens pas de mettre en oeuvre la deuxieme, surtout que je ne suis plus sur place pour reinclure les modules s'il y a un soucis.

Là, j'ai listé tous les noeuds qui devraient communiquer avec la base selon moi ( comme tu m'as dit ), je vais les soigner regulierement un par un a la petite semaine, et je ferai ensuite la meme chose pour les autres.

Je vous tiendrai au courant de mon avancée.

Merci en tous cas ! A bientot !

[Nik0]

J'aimerai essayer de faire un scénario qui soignerai automatiquement les nœuds qui pose problèmes,
plus simplement, est ce que vous savez comment je peux appeler la commande soigner le nœud depuis jeedom ?
je vais pas m'en sortir sinon, c'est pas possible que je reste devant mon PC a cliquer sur les actions comme ça, ça va me prendre trop de temps !

[Edit]
en lançant soigner les noeuds + soigner le réseau (de façon régulière sur la journée, je suis arrivé à faire raccorder 3 nœuds au contrôleur principal.
je pense que je vais y arriver petit a petit mais bon c'est vraiment laborieux ...
je suis conducteur de travaux dans le bâtiment, du coup, je m'imagine tout le temps en situation professionnelle et je ne peux pas m'empêcher de penser que ce système en l'état ne peut pas être envisagé par les professionnels.
C'est dommage car tout le reste marche bien mais la mise en oeuvre du maillage est trop aléatoire !
ça irait si le maillage pouvait fonctionner tout seul du premier coup, ou à la limite après quelques redémarrage.
et si ça n'est pas possible que ça fonctionne du premier coup, il faudrait qu'il y ait :
- soit un script qui soigne tout le réseau automatiquement et là on sait qu'on en a pour un mois mais c'est pas grave parcequ'on a été prévenu
- soit la possibilité de proposer le maillage manuellement à la box pour qu'elle corrige ensuite les quelques erreurs.

Bon allé je perd pas la fois que ça fonctionne bien un jour
Merci en tous cas de me lire et de m'aider, c'est bon de savoir qu'on est pas tout seul dans ces cas là !

[Mav3656]

Bonjour @Nik0,

Quelques précisions ci-dessous :

J'ai par exemple, le nœud 68, c'est celui qui me pose le plus de problèmes et qui est le plus loin du controlleur - environ 30m - avec des murs betons au milieu. Il communique correctement 1 fois sur 4.
Quand je regarde la liste des voisins, je remarque qu'il y a le controlleur 1 alors que cette route n'est pas bonne d'apres moi,
[...]
Est ce qu'il serait possible de supprimer le routage pour ces alarmes, histoire qu'elles soient utilisées comme les quelques autres modules a pile qui sont dans mon reseau ?

Les modules FLiRS ne participent pas au maillage. Le fait que des modules FLiRS soient voisins de ton node 68 leur permet de communiquer à d'autres modules, en passant par le node 68 => pas l'inverse. => le node 68 ne peut pas parler sur le réseau aux travers de tes équipements FLiRS et il ne le fera pas, c'est techniquement impossible.

Mais il y a quand même une bonne nouvelle dans tout ça, tu as mis en avant ton problème: ton nœud 68 pense pouvoir parler au contrôleur directement alors que ce n'est pas le cas. Il te faut soigner ce nœud au sein du réseau. S'il ne peut pas lui parler, il ne doit pas l'avoir dans ses voisins ! Il essaiera d'abord de parler en direct avec le contrôleur, plusieurs fois, d'où les latences que tu observes.

Je vais essayer la première la solution, je ne me sens pas de mettre en œuvre la deuxième, surtout que je ne suis plus sur place pour ré-inclure les modules s'il y a un soucis.

En effet, tu ne peux pas inclure de module si tu n'es pas à proximité de ces modules puisqu'il y a une manipulation manuelle à réaliser pour l'inclusion d'un module. D'ailleurs, j'ai oublié de le préciser dans mon précédant message mais il faut aussi faire un reset du module avant de pouvoir l'inclure à nouveau dans la solution n°2 (en effet, de son point de vue, il était déjà inclus à un contrôleur et il ne peut pas deviner que le contrôleur ne servira plus).

Là, j'ai listé tous les nœuds qui devraient communiquer avec la base selon moi ( comme tu m'as dit ), je vais les soigner regulierement un par un a la petite semaine, et je ferai ensuite la meme chose pour les autres.

Je te renvoie vers mon premier message qui te donnait les éléments techniques pour réussir à faire ça (je ne remets pas tes compétences en cause, mais attends toi tout de même à y passer un peu de temps avant de comprendre les mécaniques), tout en te déconseillant très fortement de le faire.........je fais référence à ce message :

Bonjour @Nik0,

Tu trouveras des informations de valeur pour réaliser cela à cet endroit : https://nechry-automation.ch/2018/06/07/api-restful/
[...]
Cependant, je te déconseille très fortement de soigner le réseau toutes les 3H.

Autre point important : as-tu pris le temps de supprimer les nœuds "unknown" de ton réseau ? Je t'ai indiqué la marche à suivre ici :

Concernant les nœuds "Unknown", il faut également faire disparaitre ces nœuds pour remettre ton réseau Z-Wave dans un état stable.

Bonne fin de journée, et tiens nous au courant

[Nik0]

Merci pour tes réponses franchement je comprends plein de choses maintenant ! je me sors les modules Flirs de la tête alors.
je te confirme également que mon réseau est propre, il y a seulement 2 petites choses :

j'ai cette electrovanne popp
https://www.domotique-store.fr/fr/domot ... results=11
les infos constructeurs n'ont jamais été reconnue correctement mais elle fonctionne bien et répond au commande :
elle a ce statut là :

Capture 02.PNG (7.37 Kio) Consulté 4565 fois

j'ai essayé de l'exclure et de la réinclure plein de fois et elle reste avec ce statut tout en répondant au commande. elle a également quelques noeuds voisins qui sont cohérents avec les emplacements, donc je me suis dit que ça allait.
lamienne est en Zwave par contre, pas en Zwave+

j'ai ensuite mis 2 répéteurs Zwave parceque je me suis demandé s'il fallait pas renforcer le signal d'une façon ou d'une autre.
ils ont été correctement inclus et bien reconnus mais au bout de quelques jours, ils apparaissent les 2 systematiquement en unknown :

Capture.PNG (11.24 Kio) Consulté 4569 fois

je me suis pas dit que c'était forcément un problème parceque tout les reste est sur OK.

Sinon, hier soir, j'avais 6 nouveaux nœuds qui avaient trouvés leur route et qui communiquaient directement avec le contrôleur.
Sur la première zone que j'avais défini ( la plus proche du contrôleur ) il me restait 4 nœuds à réparer.
Ne voyant pas d'évolution j'ai tenté une réparation complète du réseau.
3 des nœuds sur les 6 qui avaient retrouvés leur routes sont revenus en arrière ... sur la configuration précédente.
Est ce que c'est pour ça que tu me déconseillais d'utiliser cette commande trop souvent ?
qu'est ce qu'il faut que je fasse pour "fixer le réseau" une fois que les modules ont les bons numéros de voisins dans leur résumés ?
j'ai essayé de mettre à jour les voisins du contrôleur mais ça n'a pas l'air de répondre.

J'ai bien lu l'article de Nechry, effectivement, c'est très intéressant et je te remercie du partage, du coup, j'ai créé un scénario pour soigner le réseau automatiquement 2 fois par semaines, il y dit que pour lui c'est un maximum. Effectivement, j'ai peut être un peu abusé sur la commande.

[Nik0]

j'ai donc créé en tout 3 types de scénario
je les met là au cas ou cela pourrait aider quelqu'un

1 - un scénario qui heale le réseau 2 fois par semaines la nuit
j'ai ajouté un bloc code dans lequel j'ai mis :

Code : Tout sélectionner

// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'YourAPIZWaveKey';
// End Setup

// call the network health endpoint
$url_health = 'http://localhost:8083/controller?type=action&action=healNetwork&apikey=' . $apizwave;
$content = file_get_contents($url_health);
//$scenario->setLog($content);
// get result as json
$results = json_decode($content, true);
$success = $results["state"];
if ($success != 'ok') {
    $scenario->setLog('ZAPI controller healNetwork return an error: ' . $results["result"]);
}

il suffit d'y mettre la clef Zwave en remplacement de YourAPIZWaveKey

2 - un scénario qui heale les noeuds qui posent problèmes.
j'en ai relevé un certain nombre et je lance une action de heal sur chacun d'eux toutes les heures à intervalle de 5 minutes entre chaques noeuds.
pour chaqun des noeuds, je n'ai qu'a modifié la valeur nodeId

Code : Tout sélectionner

// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'YourAPIZWaveKey';
// the node Id to perform the ping
$nodeId = 13;
// End Setup

$url = 'http://127.0.0.1:8083/node?node_id=' . $nodeId . '&type=action&action=healNode&apikey=' . $apizwave;
$contents = file_get_contents($url);
//$scenario->setLog('Contents :'.$contents);
$results = json_decode($contents);
$success = $results->state;
if ($success != 'ok') {
    $scenario->setLog('ZAPI TestNode return an error: ' . $results->result);
}

et en 3ème, je force la mise à jour des nœuds voisins à intervalle de 5 minutes entre les requêtes de heal de noeuds
sur une plage random de noeuds que j'ai définir

Code : Tout sélectionner

// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'YourZWaveAPIKey';
// the node Id to perform the ping
$randomChoice  = function($array) {return $array[array_rand($array)];};
$input = [8, 9, 11, 12, 13, 14, 15, 16, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 33, 35, 36, 37, 38, 39, 43, 44, 45, 47, 50, 61, 64, 67, 68, 70, 71, 73, 74, 75, 76];
$nodeId = $randomChoice($input);
// End Setup

$url = 'http://127.0.0.1:8083/node?node_id=' . $nodeId . '&type=action&action=requestNodeNeighbourUpdate&apikey=' . $apizwave;
$contents = file_get_contents($url);
//$scenario->setLog('Contents :'.$contents);
$results = json_decode($contents);
$success = $results->state;
if ($success != 'ok') {
    $scenario->setLog('ZAPI TestNode return an error: ' . $results->result);
}

[Juju31]

Hello,

Je vois qu'il y a des experts en médecine de réseau !

Pour ma part, je suis en train de stabiliser mon réseau qui est maintenant en place, en utilisant la commande soigner réseau.
Mais cela provoque à chaque fois une exclusion/inclusion de plusieurs équipements. Ils récupèrent leur IDs, mais certains n'ont plus de commandes (que je dois recréer), d'autres les ont mais avec des id différents.
Du coup, je suis à chaque fois bon pour tout remettre d'équerre dans les scénarios, virtuels, ...

C'est le fonctionnement normal de soigner réseau ?

[Nik0]

Bonjour Juju,
je ne suis pas un expert mais là, ça à l'air complètement fou ce que tu nous racontes ?
normalement la box n'est pas sensée exclure des modules toutes seules en soignant le réseau.
ça me fait me dire que t'as peut être un problème avec ta clef Zwave.

là je te donne quelques conseils de père tranquille,
1] n'utilise rien d'autre comme clef Zwave que la aeon zen gen5
2] n'inclus aucun modules en mode sécurisé.
3] le périphérique de stockage doit être un disque dur
4] Il faut un onduleur derrière ta box jeedom

et les dissipateurs thermiques pour refroidir le Rpi seraient pas un luxe.
si tu n'as pas ça de base, d’après moi, tu auras des problèmes.
Et à priori après un soignage du réseau continue de plusieurs mois pour que ça se stabilise, ça marchera peut être
le soignage du réseau peut être lancé 2 fois par semaines ça ne sert a rien au delà d'apres Nechry mais je ne sais pas pourquoi.

Pour tes scénarios, il faut que tu organises tes modules de cette façon :
quand tu les nommes, tu mets la lettre M à la fin de chaque nom de modules pour que tu puisses les repérer
ensuite tu crées un virtuel calqué sur chacun de tes modules en appelant les commandes de tous tes modules
Quand tu créeras tes scénarios, tu pourras renvoyer vers le virtuel de ton module et non vers le module directement
comme ça s'il y a un truc qui se passe dans ton réseau, et que tu dois changer un module ou que tu as un problème, tu n'auras que les commandes de ton virtuel à réattribuer, tu n'auras pas tout à refaire comme là.
l'autre truc qui est pratique avec cette méthode, c'est que tu pourras paramétrer chaque commande individuellement pour renvoyer plusieurs fois la commande d'allumage ou d'extinction genre pour l'instant, j'ai un module ultra capricieux et j'ai paramétré l'envoie de 20 fois la commande On sur une minute pour que je puisse espérer voir la lumière s'allumer un jour.

Voilà, je t'ai donné tout ce que je savais, je te souhaite bon courage ...