jjacques68

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

ah !! et maintenant ??

sous DSM ...

Et oui, je l'utilise pour mes applications Webdev... Mais rien y fait, j'arrive pas à lancer ce foutu script. Si j'ai un NAS, mais pfffff...

punaise je suis avec IIS et il me gonfle en me disant que j'ai pas le droit

J'arrive pas à fair marcher ce script PHP !!! ça me saoul

@TonyC : une petite vingtaine... tous sur secteur. Edit : par contre la manip de @Lazer, je l'ai faite que sur les 6 FGRM...

ahhh ok punaise je savais pas merci ! chose faite sur un module : comment on sait que c'est fini ? avec le log "New neighbor list received" ?

on peut faire ça ? c'est où ?

mais c'était fait !! et pourtant !!!???

alors je viens de retourner le fil avec @TonyC : (en plus j'étais l'interlocuteur ...) Mais visiblement c'est pas régler comme problème...

oui c'est bien ça : 3.3.52 et donc ? faut que je les remplace c'est ça ?

alors ce sont bien des FGRM 222 en version 2.2 et 2.4. @Lazer : pas au courant de ce bug, j'ai du louper une info...

hello tout le monde ! En 10 jours, j'ai eu 3 comportements identiques étranges. Cela se passe avec les FGRM. Ils sont tous bien actionné en temps et en heure, mais sur 6, un (et ce matin un deuxième...) n'a pas son état mis à jour. Donc ce matin, ces 2 volets avaient un status fermé, alors qu'ils s'étaient bien ouvert. n'ayant pas fait attention sur le coup, ce soir, lors de la fermeture, et bien ces 2 volet, qui avaient encore le status fermé, ne se sont donc pas fermés. c'est la 3ème fois que ça m'arrive en quelques jour, alors que je n'ai rien modifié sur la box. Ce bug, ne concerne pas toujours le même volet. Dans les 3 cas, cela touchait un autre volet. Ce n'est pas un problème de calibrage, ils sont juste. vous avez une idée ?? merci d'avance !!

étrange en effet...

ça fait combien de temps ? sinon hard reboot... ça m'est déjà arrivé une fois ou deux...

@mprinfo , je me suis fait la même remarque

@Lazer, oui oui tout à fait, je répondais à @idomotique la solution de @Barelle est déjà bien utilisée

attention, ça c'est pas une indirection, tu utilises la propriété "sunriseHour". ça c'est une utilisation classique. Mais par exemple ça, qui est une indirection : local MaVariable = "sunriseHour" fibaro.debug("Scene155", api.get("/settings/info/").MaVariable) ça ne marche pas.