jluc2808 Posté(e) le 4 septembre Auteur Signaler Posté(e) le 4 septembre oui bien entendu reset des modules pour les passer de S0 en non sécurisé 1
jluc2808 Posté(e) le 18 novembre Auteur Signaler Posté(e) le 18 novembre bon , ça y est j'ai débuté ma migration j'ai opté pour une réinitialisation zwave ==> OK ensuite j'ai repris mes modules - 1 exclusion : OK - 2 inclusion en mode non sécurisé : OK - 3 paramétrage des noms , type , pièces , .... : OK maintenant je me retrouve avec les anciens ID toujours présents (voir copie d'écran) lorsque je veux faire un delete : j'ai le message suivant dans la console en bout de course tous mes anciens modules sont toujours là même après un reboot de la HC3 ce qui perturbe la lecture et l'usage NUKI comment je peux m'en débarrasser
Lazer Posté(e) le 19 novembre Signaler Posté(e) le 19 novembre Quand tu dis que tu as réinitialisé le Z-Wave... tu as bien réinitialisé toute la box ? Parce que sinon, la box connait encore les anciens modules, stocké dans la base de données interne de la box.
jluc2808 Posté(e) le 19 novembre Auteur Signaler Posté(e) le 19 novembre (modifié) Il y a 21 heures, Lazer a dit : Quand tu dis que tu as réinitialisé le Z-Wave... tu as bien réinitialisé toute la box ? Parce que sinon, la box connait encore les anciens modules, stocké dans la base de données interne de la box. non je n'ai pas réinitialisé la box, juste un réinit de Zwave, je ne voulais pas tout perdre avec les quickApp, scénarios LUA, plugin , user, remote user, droits , ..... j'ai procédé par un exclude de chaque noeud , OK avec ack au vert, (de tout manière cette étape est obligatoire même en réinitialisant la box) puis un include qui me donne un autre item une fois réalisé et reparamétré avec les bons nom, je voulais supprimer les entités orphelines qui restent puisque plus accrochée à un module zwave (réinit du réseau) ce que je trouve bizarre, c'est que pour certaines ça fonctionne , la suppression se fait correctement, mais pas pour d'autres, a priori sans liens entre elle, ni du même type. je précise que des items créés avec des FGS223 pour certains le process de delete est OK, mais pas pour d'autres. j'ai pas trouvé de logique du pourquoi ça marche et pourquoi non. sur mes 165 devices, j'ai pu en supprimer environ 80, j'en ai 15 récalcitrante, les autres ne sont pas encore traitées. Modifié le 19 novembre par jluc2808
Lazer Posté(e) le 21 novembre Signaler Posté(e) le 21 novembre Hum OK je comprends.... malheureusement tu as toujours des traces des anciens modules dans la DB, cette fonctionnalité de reset du réseau Z-Wave a toujours été problématique chez Fibaro (HC2, HC3...), je me demande même pourquoi elle existe tant ça apporte plus de problèmes qu'autre chose. Essaye peut être de contacter le support Fibaro en leur expliquant le problème et en désignant bien les anciens modules récalcitrants, ils pourront peut être faire le ménage à la main dans la DB.
jluc2808 Posté(e) le 21 novembre Auteur Signaler Posté(e) le 21 novembre oui c'est ce que j'ai fait, j'ai eu une réponse pour demande de connexion du support et faire le ménage dans la DB j'ai vu qu'ils avaient fait un backup hier soir, ce qui m'a fait perdre une partie des modifs qui ont été réalisées pendant ou après le backup , j'ai là aussi demandé des explications et j'attends le grand nettoyage, parce que il me reste plus de 40 modules fantômes et c'est vraiment pas simple de m'y retrouver parce que j'ai repris les même noms pour simplifier le lien avec HomeAssistant je vais voir aujourd'hui la suite Maintenant pour ma migration, j'arrive au bout (jour 4) - dans un premier temps, en test unitaire je ne note pas de latence, autre que celle qu'on constate avec des modules au lieu des inters, mais ça semble être de l'ordre du 0.1s voir moins. - je constate ancussi que les éclairages avec starter réagissent moins bien que avec un inter direct. - constat sur le changement de couleur des anneaux le système réagit et permet de changer la couleur des anneaux des walli controller, via des scénarios qui sont associés aux lampes qu'ils pilotent (lampe allumées / éteintes) sauf que, il y a toujours un mais, le module walli (controller ou autre) a un acquitement en vert allumé de l'ordre donné, donc lorsqu'on appui sur le bouton, si l'ordre est correctement interprété et transmis on a un allumage en vert au bout de quelques centièmes / dixièmes de secondes qui allume puis éteint l'anneau. Ceci perturbe très fortement les scénarios, puisque dans le scénario si éclairage allumé je mets le retroéclairage + la couleur et là si cette séquence se déroule plus vite que l'acquitement , alors l'anneau clignote puis passe en rétroéclairage off. ce qui fait que ça devient pas stable et que la fonction de j'éclaire l'anneau (ou le bout d'anneau) en vert quand la lampe est allumée est lui même instable . je teste une solution qui consiste a dire que le déclencheur (lampe allumée ou éteinte) doit l'être pendant 2 secondes , pour que la fonction rétroéclairage et couleur anneau s'execute, je vais voir si ça bypass le pb .
Lazer Posté(e) le 21 novembre Signaler Posté(e) le 21 novembre Hum.... les rétroéclairages des boutons je n'ai jamais joué avec, donc je n'ai aucun avis sur la question. En tout cas espérons que le support Fibaro finisse le ménage proprement... il faudra insister gentiment je pense. En revanche : Il y a 9 heures, jluc2808 a dit : - je constate ancussi que les éclairages avec starter réagissent moins bien que avec un inter direct. Je n'ai pas compris cette phrase.
jluc2808 Posté(e) le 21 novembre Auteur Signaler Posté(e) le 21 novembre (modifié) yes !!!! le support fibaro a réagit et terminé le nettoyage des modules fantômes ouf!! j'y vois plus clair juste pour info , une fois le nettoyage terminé, il faut absolument faire un reboot de la HC3 pour constater les suppressions j'ai terminé - 4 jours entiers avec personne dans les locaux pour tout reprendre (presque 50 heures en tout) je confirme que pour la gestion de la couleur des anneaux , avec l'astuce de rajouter un délai/temps dans la détection du déclencheur (2s), je n'ai plus les interférences avec les acquittements des modules walli controller. dommage que ces modules (y compris quand ils sont sur secteur) ne soient pas équipés de fonction de retour d'état, parce que c'est un vrai moins quand on les couples en association directes avec des modules actions (FGS, FGD, FGR) y compris sans utiliser plusieurs walli pour commander une lampe, il suffit de faire l'action sur la partie domotique et le walli ne sait pas se synchroniser , par exemple si utilisation pour du ON/OFF basic avec une lumière, si on actionne la lumière via l'interface HC3, le walli ne le sait pas , donc on est obligé de faire 1 clic pour rien de manière à le remettre dans l"état ON ou OFF , avant de pouvoir faire la vrai commande ==> pénible pour ma remarque avec lumière avec starter laisse tomber, c'est pas l'endroit de discuter de cela. Modifié le 21 novembre par jluc2808 1
jluc2808 Posté(e) le 3 décembre Auteur Signaler Posté(e) le 3 décembre (modifié) bon après quelques jours et l'usage par des utilisateurs lambda, le constat est bon - la réaction sur appui bouton est beaucoup plus courte - je n'ai plus de latences qui mettaient les utilisateurs en stress et les amenaient à appuyer plusieurs fois (ce qui entrainaient encore plus de confusion) - l'astuce d'ajouter un délai de 2s sur le changement d'état d'une dispositif afin d'enclencher le changement de couleur des anneaux des interrupteurs (walli controller) associés est semble-t-il efficace - la gestion des commandes (interrupteur walli controller) pour les BSO via les scénarios semble aussi plus appropriée que la gestion via association directe entre walli controller et FGR224 1x court haut = montée 1x court bas = descente 2x court haut ou bas = stop 1x long haut ou bas = position favorite de l'inclinaison des lamelles j'ai été amené à ajouter une autre astuce avec les BSO - quand on ferme (ou on ouvre) le BSO via l'application (dans mon cas avec l'intégration Homeassistant), le BSO redescend de quelques centimètres après avoir atteint sa butée haute (ou remonte si butée basse) afin de repositionner les lamelles. je n'ai pas trouvé comment on peut modifier ce comportement et le paramètre 153 des FGR224 ne permet pas de dire pas de repositionnement et le seul paramètre 151 en BSO (store vénitien) alors j'ai ajouté un scénario qui consiste a positionner les lamelles à la main si on ferme ou si on ouvre, mais ça nécessite d'ajouter un délai (le temps de la montée ou descente et du mouvement de positionnement automatique) si vous avez une autre solution, je suis preneur ? Modifié le 3 décembre par jluc2808
Messages recommandés