comportement étrange avec les retours d'état

[jjacques68]

sous DSM ... 

 

Citation

Fatal error: Uncaught Error: Call to undefined function curl_init() in /volume1/web/z-wave_network_hc3_correct.php:24 Stack trace: #0 /volume1/web/z-wave_network_hc3_correct.php(75): getDevices() #1 {main} thrown in /volume1/web/z-wave_network_hc3_correct.php on line 24

 

[jjacques68]

ah !!

 

et maintenant ??

 

[Lazer]

Bravo

 

Et bien maintenant tu vois tous les devices qui ne communiquent pas en direct avec le contrôleur.

Il faut que tu pointes ceux qui seraient éventuellement des vieux modèles avec le SDK tout pourri

Et comme je t'ai dis, si tu en trouves, tentes une reconstruction, dès fois qu'ils arrivent à communiquer en direct, il me semble que c'est censé améliorer les choses si je me souviens bien de ce qu'avait dit @TonyC à l'époque

[jjacques68]

j'ai pointé, mais j'avoue ne pas comprendre trop ce que je vois...

 

[Lazer]

Et bien c'est simple.

Par exemple, tu as les 241, 199, 187, 47, 66, 762, etc... qui passent par au moins 1 saut, voire 2 (ce qui est franchement mauvais... ils sont si éloignés que ça ces modules ?)

 

A l'inverse, par exemple 332, 296, 292, etc... sont en communication directe avec la box, donc c'est tout bon, ne touche pas à ceux là

[jjacques68]

y a un truc qui m'échappe...

 

le module 199, qui est module sur secteur, il est situé à 4 m de la box, juste un étage au dessus !

Le premier saut est par le device 64, qui est 2 étages plus haut que la box !!!

Mais c'est du gros n'importe quoi !!

J'ai jamais voulu, ou provoquer ça !!

 

j'ose demandé si on est sûr du résultat de ce script php ? si je peux me permettre...

 

si j'utilise la fonction de remesh, ça remet tout ça en ordre ?

C'est étrange parce que ce graph a été fait après que j'ai remeshé les volets, et ils sont toujours à l'ouest...

c'est les modules 37, 41, 44, 47, 53 et 762 !

 

 

[Lazer]

Si tu n'es pas sûr du script, tu vérifies dans le JSON du module, les infos proviennent de là.

 

Peut être que tu as déplacé ce module (ou intercalé un obstacle entre lui et la box), donc il a trouvé un nouveau chemin qui fonctionne.

Et même si ce chemin est plus long, il le conserve, c'est normal.

Le Z-Wave ne prévoit pas la recherche de la meilleure route.

Le protocole prévoie juste de trouver la meilleure route à un instant T (la différence est de taille). Une fois trouvé une route fonctionnelle, il la conservera éternellement, tant qu'elle mène à bon port.

Il n'y a pas de recalcul dynamique tant que ce n'est pas absolument nécessaire.

D'où l'intérêt de voir la carte, et de forcer le recalcul pour les quelques modules qui te paraissent anormal.

 

 

En fait d'après ce que j'ai compris, les modules Z-Wave maintiennent en permanence une liste de leurs voisins (avec la puissance du signal associée)
En revanche, la route est statique, c'est à dire qu'une fois trouvé un chemin, le module l'utilisera toujours, tant qu'elle fonctionne, et ce même si ce n'est pas la meilleure route (parce qu'entre temps, un obstacle a été supprimé, ou un autre routeur présentant un meilleur signal a été ajouté)
Il y aurait 2 façons de modifier cette route :
- Si la première route ne fonctionne plus, alors il utilisera l'ancienne route (qui est mémorisée également).... sinon (aucune des 2 routes ne fonctionne) alors il en cherchera une nouvelle.
- Le contrôleur Z-Wave a demandé le recalcul d'une nouvelle route (mais normalement on n'a jamais besoin de le faire... en tout cas perso en 7 ans et 94 modules, je n'ai jamais eu à le faire). Le recalcul des routes peut être assez gourmand (trames d'exploration du réseau), et s'il est demandé pour plusieurs modules, la conséquence est pire que tout : le réseau peut s'écrouler. Donc attention !

Bref, le recalcul des routes quand il est nécessaire est effectué automatiquement et surtout de façon transparente pour l'utilisateur.
A mon avis le seul cas de figure problématique doit se poser quand un module bagote entre ses 2 routes mémorisées et qu'elles sont toutes les 2 de mauvaise qualité. Dans ce cas, forcer la reconstruction doit être utile.

 

 

J'espère que je ne dis pas trop de bêtises, c'est en tout cas ce que j'ai retenu des exposés savants de @robmac :

• Z Wave Routing Basics
• Z Wave Routing Basics: Retry Strategies
• Z Wave Routing Basics: Application/Binding Retries, Heal and Explorer

 

 

Perso mon astuce, c'est qu'à chaque fois que j'inclue un module, je le fais à coté de la box (donc en vison directe sans passer par un routeur), et ensuite je vais l'installer à sa position définitive.
Donc il se débrouille tout seul pour trouver une nouvelle route si nécessaire, sinon c'est qu'il peut continuer à communiquer en direct avec la box, sans passer par un routeur, ce qui est encore le mieux.

En fait, le meilleur conseil qu'on puisse donner, c'est d'inclure les modules à proximité de la box, puis de les installer à leur emplacement définitif. Cela maximise les chances de communication directe sans utiliser de saut via des routeurs.

D'ailleurs, quand on a une grosse installation, c'est même indispensable, car le trafic normal du réseau gêne l'inclusion si le module est trop loin (ça prend trop longtemps (plusieurs minutes) voire ça n'aboutit jamais) => inclure le module près de la box permet de maximiser la bande passante et d'inclure plus vite (l'inclusion est un processus extrêmement bavard)

 

[jjacques68]

belles explication, merci !

 

donc en gros, on est pas censé toucher...

je l'ai fait pour les volets, demain j'essayerai encore pour le 199, histoire de voir le changement sur le graph...

 

et combien de rebond maximum peut - il y avoir entre la centrale et un module ?

 

Et par rapport au version z-wave de mes FGRM, ça va finir par leur remplacement  

[mprinfo]

Si je me souviens bien c'est 3 rebonds

Envoyé de mon BLA-L29 en utilisant Tapatalk

[Lazer]

Je crois que c'est plutôt 5 rebonds.

 

[jjacques68]

on peut le définir manuellement ?

définir par quel module passer ?

[Lazer]

Ah non pas du tout

 

EDIT : tu débranches tout le monde, puis tu n'allumes que les modules par lesquels tu veux imposer le passage.

Bon, vraiment nul comme technique

 

Modifié le 15 février 2021 par Lazer

[jjacques68]

on peut pas modifier directement dans l'API le :

 

 

 

edit : c'est vraiment tentant... plus j'analyse, plus je me dis que que pour pas mal de modules, ce routage est n'importe quoi... après j'y connais pas grand chose...

Modifié le 15 février 2021 par jjacques68

[Lazer]

Bah bien sûr que tu ne peux pas le modifier dans l'API... quelle drôle d'idée.

C'est une information remontée par le device.

Tu devrais relire tout le topic depuis le début, je pense que tout cela est confus dans ton esprit

 

[jjacques68]

oui tu as raison, faut que je lise tout ça...

 

en tout cas le remesh par module ne change absolument rien au routage zwave !!

 

Les 6 volets ainsi que le fameux module 199 dont on prenait l'exemple, n'ont absolument pas changé...

Donc je me demande si cette fonctionnalité... fonctionne ??!!!

[Lazer]

mouais.... bien possible que ça ne fonctionne pas....

 

Remarque, la phrase descriptive est ambiguë :

 

" Reconfigurer le maillage en interrogeant le dispositif sur les appareils voisins („RequestNodeNeighborUpdate”). "

 

=> du coup on ne sait pas trop si ça force réellement la reconstruction d'une route, ou bien si ça se contente d'interroger et de mettre à jour la liste des voisins (ce qui est peu utile)

 

[jjacques68]

alors je viens de me rendre compte, que sur les 6 FGRM, 1 n'avait pas les paramètres 40, 42 et 43 à 0.

cela vient du fait que j'ai du le ré-inclure il y a quelques temps...

Suite à une galère profonde pour inclure un Qubino FP, ce FGRM avait disparu de la circulation... ?¿? bref...

 

Je n'avais pas penser à ces 3 paramètres à ce moment là.

 

Je les ai modifiés, on va voir si ça va jouer un rôle...

J'ai un doute vu que ce bug de remonté d'info, était aléatoire sur les 6.

Apres peut-être qu'il bombarde sa conso sur le réseau et sature celui-ci et du coup j'ai des retours d'état qui se perdent...

[jjacques68]

je reviens avec mon histoire, après avoir pris le temps d'analyser les choses...

Je me suis permis de refaire le script php sous une application windev histoire d'enrichir un peu les infos...

Bon malheureusement j'arrive pas à avoir le rendu graphique du plugin en php, donc c'est une arborescence classique, mais le résultat est le même (et pas besoin de serveur http ou autre  )

 

voilà le résultat : [id] - name - (room - section)

 

 

si on regarde un des mes FGRM, celui du volet 3 (ID 47), et qu'on regarde de plus près le chemin 

 

en partant du module :

 

RDC ---> CAVE ---> CAVE (encore ??) ---> ETAGE (incroyaaaable !) ---> CAVE ---> CAVE

 

nan mais c'est quoi ce maillage ?

J'ai du mal a croire que c'est le seul chemin qu'il ait trouvé !!

et c'est de loin pas le seul !!

 

Franchement, ça me dérange vraiment de voir ça, ça fait mal aux yeux  !

Modifié le 20 février 2021 par jjacques68

[mprinfo]

Tu dois avoir de bonne bouteille dans ta cave c'est pour cela que le signal y passe une grande partie de son temps

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

 en même temps, la HC3 est à la cave...

Pas de chance, pas de bouteilles dans la cave !

[mprinfo]

Tu as essayé un fgrm222 en direct avec la box

Je pense que tu ne fais pas une recherche méthodique de panne.

Sachant que tu as des modules en 3.52 il y a de fortes chances que le problème vienne de la.

Donc un fgrm222 à côté de la box au pire exclusion puis inclusion et faire des tests
Tu seras fixé.

Une autre solution c'est de déplacer la box à l'étage afin de forcer un remaillage

Au départ j'avais une quinzaine de modules et j'avais parfois des nœuds morts. Ma box était au rdc dans le bureau complètement excentré du centre de la maison.

J'ai pris la décision de tirer un câble réseau jusqu'à l'étage dans le hall qui ce trouve au centre de la maison. Je n'ai plus jamais eu de problème.

Les ondes radio c'est comme de l'eau ça passe par le ou les chemins les plus faciles qui sont rarement les plus courts. J'ai aussi remarqué que les ondes n'aiment pas les dalles poutrelle hourdis car il y a beaucoup de ferraille

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

il y a 1 minute, mprinfo a dit :

Sachant que tu as des modules en 3.52 il y a de fortes chances que le problème vienne de la.

ça je comprends bien !

 

il y a 1 minute, mprinfo a dit :

Une autre solution c'est de déplacer la box à l'étage afin de forcer un remaillage

Mais les FGRM sont à 2 mètres vol d'oiseau !!

 

il y a 1 minute, mprinfo a dit :

Donc un fgrm222 à côté de la box au pire exclusion puis inclusion et faire des tests
Tu seras fixé.

si je peux l'éviter, je préfère  

 

il y a 3 minutes, mprinfo a dit :

Une autre solution c'est de déplacer la box à l'étage afin de forcer un remaillage

si je peux la remettre après à son emplacement d'origine, je veux bien, mais qui me dit que le maillage ne va rechanger après ça !?

 

 

J'ose poser la question, (vais me faire gronder je le sens...  ) si je force un remaillage complet du réseau.

et que c'est pire, un bordel sans nom quoi... est ce qu'un recovery me remet les routes comme avant ?

[Lazer]

Non, le recovery ce n'est que le contenu de la puce Z-Wave.

Et comme tu as lu avec attention ce qui est écrit avant, tu sais que les routes sont stockées dans les modules.

 

il y a 20 minutes, jjacques68 a dit :

si je peux la remettre après à son emplacement d'origine, je veux bien, mais qui me dit que le maillage ne va rechanger après ça !?

Comme écrit plus haut, une route est conservée quand qu'elle fonctionne.

D'où ma suggestion de toujours inclure les modules à coté de la box. Route directe, simple et efficace.

[jjacques68]

il y a 3 minutes, Lazer a dit :

D'où ma suggestion de toujours inclure les modules à coté de la box. Route directe, simple et efficace.

je vais quand même pas tout réinclure !!

[Lazer]

non, juste les modules qui posent problème