comportement étrange avec les retours d'état

[jjacques68]

[Lazer]

Vu que la demande de reconstruction de route ne fonctionne pas, tu n'as pas le choix...

 

Sinon tu fais comme je t'ai suggérer pour rire, mais en vrai : tu débranches TOUT sauf la box et le module.

[jjacques68]

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  

[mprinfo]

Ben voila

 

Un petit truc si tu ne le savais pas il ne faut pas sortir le modules de derrière le bouton pour inclure et exclure

 

Si tu as des boutons poussoirs un triple appuie sur le bouton fonctionne très bien

[jjacques68]

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

 

??? 

[Lazer]

Tu es certain que c'est bien la route que tu analyses, et non pas la liste des voisins ?

[jjacques68]

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)

[jjacques68]

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

Modifié le 21 février 2021 par jjacques68

[Lazer]

Intéressant... Mais du coup, ce qui a forcé la reconstruction de la route, ce n'est pas la demande de reconstruction, mais tout simplement la demande de communication, il fallait bien trouver une nouvelle route pour communiquer avec le module une fois le Wall Plug relai débranché.

Je pense que tu serais arrivé au même résultat, après avoir débranché le WP, soit en :

- forçant un Polling depuis la box

- actionnant le bouton du volet roulant, ce qui aurait envoyé un retour d'état vers la box

 

 

[jjacques68]

il y a 10 minutes, Lazer a dit :

actionnant le bouton du volet roulant, ce qui aurait envoyé un retour d'état vers la box

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

[Lazer]

Donc l'information de route remontée dans le JSON du module serait erronée, et ne correspond pas à la "vraie" route empruntée par le module, c'est ce que tu dis ?

[jjacques68]

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  )

[Lazer]

il y a 9 minutes, jjacques68 a dit :

C'est seulement après avoir cliqué sur remesh que la route s'est reconstruite.

Non cette phrase est fausse

 

En fait ta phrase répond à une interrogation qu'on s'est posé précédemment : ça ne reconstruit pas la route (elle est reconstruite automatiquement en cas de besoin)..... ça se contente d'interroger le module pour connaitre sa route mémorisée

 

 

[Lazer]

Tiens regarde ce post de @tinman , on y voit les commandes de l'API, plus parlant que l'interface Web.

 

 

On y voit les actions suivantes, donc les noms sont bien explicites :

- requestNodeNeighborUpdate

- getNeighborList

- getLastWorkingRoute

 

Je pense que tu peux jouer avec ça.

Mais on constate qu'aucune ne permet de demander la reconstruction de la route.

[jjacques68]

très bien, donc la route s'est reconstruite d'elle même.

peut -être que je n'étais pas assez patient...

[jjacques68]

Le 15/02/2021 à 21:16, Lazer a dit :

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

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  

[jjacques68]

Le 19/02/2021 à 18:26, jjacques68 a dit :

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

pour info : 

 

depuis que j'ai fait cette manip sur CE FGRM en question, je n'ai plus eu de soucis de remonté d'info, pour les 6 FGRM...

 

Voilà c'était juste pour info, toujours en observation...  

[TonyC]

ah voilà ça va calmer ton réseau ! Il n'y avait pas de raison que ça ne marche pas, mais bon  Quoi qu'il en soit c'est une super bonne nouvelle ! 

[jjacques68]

et voilà, mes clé zwave sont arrivées, ça sniffer grave ce week-end  

[henri-allauch]

1°  J'ai installé un ancien Wallplug 3.52  ( j'ai reçu un module neuf mais impossible de l'inclure ni de l'exclure idem sur ma HC2 alors que le vieux ok du premier coup )

J'ai en standard  : 

Paramètre 40:
Reporting significant changes in power.
Sélectionné:
80%
Paramètre 42:
Reporting small changes in power.
Sélectionné:
15%
Paramètre 43:
Time period within which the Wall Plug may sent up to 5 reports on small changes in power (resulting from parameter 42 settings).
Sélectionné:
30s

IL faut les mettre à 0 ou sur ce type de device c'est inutile et ce WP n'est fait pour la HC3 que pour des essais initiaux ?

Et donc éviter en sa présence l'inclusion d'autre module qui pourraient s'en servir de passerelle

 

 

[jjacques68]

j'ai aussi 2 wallplug en version 3.52, j'ai pas de soucis.

Mais j'ai désactivé toutes remontées d'énergie.

Pas s-ur que ce soit ces paramètres à mettre à 0 pour un wallplug... faut que je regarde...

[Fredmas]

Le 04/03/2021 à 20:47, jjacques68 a dit :

et voilà, mes clé zwave sont arrivées, ça sniffer grave ce week-end  

 

Alors la suite ? 

Je viens de découvrir/lire ce post en entier, et maintenant je suis comme ayant fini un chapitre de livre, attendant avec impatience de lire le suivant pour comprendre l'intrigue 

[jjacques68]

 le coup du sniffer a continué ici : 

Mais pas trop le temps en ce moment de jouer avec  

 

[Fredmas]

Ha ok, merci pour l'info