jjacques68

super interessant ces articles. d'après ce post https://forum.fibaro.com/topic/48365-hc2-repair-maintenance-guide/, le bouton "remesh" permettrait bien de reconstruire une route à la demande, pour un device spécifique... Bon y a plus qu'à se lancer dans un sniffer zwave... clé usb déjà commandée

très bien, donc la route s'est reconstruite d'elle même. peut -être que je n'étais pas assez patient...

ben en tout cas c'est ce que j'ai constaté avant de faire un remesh. Clairement, j'ai débranché le wallplug, fait fonctionner le volet, qui fonctionnait très bien. Interroger l'API pour avoir la route, qui n'avait pas bougé. C'est seulement après avoir cliqué sur remesh que la route s'est reconstruite. Je peux essayer de refaire la manip (sans qu'il faut que je trouve un module qui passe par un wallplug, c'est plus facile à faire )

maintenant que tu le dis, je l'avais fait aussi ça... et j'ai étrangement pas constaté de modification de la route... chose que j'attendais. Où alors j'ai pas été assez patient (5min max avant de cliquer sur remesh)... pourtant le volet fonctionnait très bien avec la route "cassée".

alors le bouton permettant de faire un remesh d'un device fonctionne. Mais visiblement, il faut "casser" la route existante avant de le faire. Par exemple : J'avais un volet (au Rdc) qui passait par un WP (etage) pour aller sur la box (cave). J'ai dans un premier temps éteint le WP de l'étage, puis demandé un remesh de ce volet. Aucun changement... J'ai donc carrément débranché le WP de l'étage. Redemandé un remesh. Et là, la route à été reconstruite. De 4 rebonds je suis passé à 2 pour ce volet. autre chose, durant la nuit, des routes ont été clairement reconstruites, je ne fais aucune action la nuit... mise à part le redémarrage de la box suite au backup auto. Mais si j'ai bien compris, cela n'a aucune influence sur le maillage des modules. alors encore une fois : EDIT : Je viens d'écrire une petite scene toute simple pour trigger sur le changement de la property lastWorkingRoute, mais je pense pas que ça va marcher...

absolument, et je vérifie avec le script php... histoire d'être sûr que je me plante pas dans l'algo. Et bien c'est tout à fait identique (juste moins visible avec le php)

alors j'ai ajouté quelques icones dans l'arborescence, et ça montre un truc encore plus fou : Je sais pas si vous allez comprendre, ou c'est moi qui est pas compris... le device 121 (icon orange) : Sa propre route passe par le 118. alors qu'il est en 1ère position (icone dossier jaune) dans la route du device 88 ! Pourquoi sa propre route n'est directement relié au contrôleur ?? ???

tu rigoles, mais je le pensais, je coupe le courant partout et alimente que les modules FGRM... en plus il sont sur le même disjoncteur

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

ça je comprends bien ! Mais les FGRM sont à 2 mètres vol d'oiseau !! si je peux l'éviter, je préfère 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 ?

en même temps, la HC3 est à la cave... Pas de chance, pas de bouteilles dans la cave !

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 !

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...

j'ai encore une fois essayé ce matin. Toujours rien. Voici ce qui apparaît dans le debug : Mais il se passe rien, j'ai forcer des réveils, il reste en version 3.3.

@mprinfo, c'est une idée, mais pffffff faut que je le démonte, le branche à proximité, me retaper tous les scripts pour mettre à jour les ID... franchement... bof

les 6 FGRM sont justes au-dessus de la box, mais à l'étage au-dessus. désolé, mal lu. Mon FGMS n'est pas tout à côté. Mais j'ai pris soin de le rapprocher pour faire des essais, mais sans résultat non plus...

petit retour après 2 mois sur cette version : Et bien j'ai l'impression que ça se dégrade... Problème avec le retour d'état des device de type FGRM 222 (voir topic dédié) que je n'avais plus rencontré depuis un très long moment. J'ai de temps en temps, peut-être une ou deux fois par semaine des freeze complet de la box. Plus rien ne répond. Pendant plusieurs secondes... J'observe dans le graphique d'utilisation de la CPU des courbes très étranges (j'attends que ça se reproduise pour vous fair une capture - c'est rare), en gros : j'ai un pic, pas forcément à 100%, et puis ça descend lentement et linéairement. J'ai une mise à jour d'un FGMS dispo, mais elle a jamais voulu se faire correctement. Donc toujours présente... J'attends ave impatience une nouvelle mise à jour de la box.

ohhhh oui

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 ??!!!

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...

on peut le définir manuellement ? définir par quel module passer ?

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

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 !

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