jluc2808

oui comme tu le dis ça m'a pris pas mal de temps pour arriver au bout de cette affaire, le fait de tout reprendre ne se fait pas inopinément. je reste avec quelques anomalies, rares mais qui ne permettent pas de donner aux utilisateurs une confiance absolue au système, notamment - avec les affichages des couleurs de anneaux en fonction de l'état de la lampe (le ack vert vient après x temps et perturbe le positionnement des couleurs des anneaux), avec le décalage de 2s suivant le temps du ack peut ne pas suffire et trop décaler risque de plus être synchro si on fait un on/off rapide. - cet histoire de BSO qui redescendent pour repositionner les lames un fois ouvert ou remontent une fois fermé est aussi un truc que je ne peux pas totalement gérer sans quelques loupés. Mais globalement ça marche La question que je me pose à ce stade de mes installations (et pas seulement celle-là) : est-il possible / raisonnable / fiable dans le temps (10 à 15 ans) de mettre une grande config / bâtisse sous Zwave ou (oui c'est pas le même prix) doit on dans ce cas opter pour du Knx filaire qui a fait ses preuves et compléter si besoin par quelques équipements Wifi (non critiques ou non indispensable) ? (NB: je ne m'aventurerais pas à mettre sous Zigbee )

bonjour, Résumé de la situation: j'ai dû installer et utiliser environ 65 contrôleurs Walli dans le même système pour remplacer un ancien système SCS (câblé) Legrand qui avait quelques problèmes et ne pouvait pas être mis à jour en raison de la non-compatibilité des anciens appareils avec le nouveau contrôleur SCS, j'ai donc choisi de déplacer toute l'installation vers zwave. Tous les boutons de commutation étaient sur le bus SCS, donc je n'ai pas pu avoir le N/P (230v) sur la prise murale, la seule solution que j'ai trouvée est de les remplacer par un contrôleur mural câblé en 24v DC, en utilisant l'ancienne installation physique pour fournir le 24DC sur chaque plot. A ce stade j'ai 65 contrôleurs Walli câblés en 24v DC pour gérer toutes les lumières et les stores (BSO). Toute les lumières et les BSO ont été câblés et regroupés dans un seul tableau sur le local technique au sous-sol. J'ai choisi des FGS223 pour gérer les lumières, FGD212 pour les variateurs de lumière et FGR224 pour les BSO. Donc ma config est : des interrupteurs dans chaque pièce (65 walli controller), et des modules actif sur une seule pièce (45 FGS223/FGR224 et 5 FGD212) En raison de l'utilisation multiple de chaque bouton, ce nouveau système doit utiliser un anneau coloré pour avoir l'état du bon voyant, vert lorsqu'il est allumé, blanc lorsqu'il est éteint. les problématiques auxquels j'ai été confronté : - 1er : les contrôleurs walli n'ont pas de endpoint logique pour stocker l'état renvoyé par la lampe ou le BSO géré. => donc si plusieurs contrôleurs walli sont impliqués dans le contrôle d'un appareil il n'y a pas de synchro possible en direct entre eux, et les opérations depuis l'interface domotique (Yubi ou HC3 ou ....) ne sont pas reportées sur le contrôleur walli - 2ème : l'acquittement du contrôleur walli lors d'une action physique se fait avec une lumière annulaire verte (ou rouge si ce n'est pas ok) et cela pour n'importe quel ordre physique (clic) => pendant ce laps de temps aucun réglage de la lumière annulaire ne peut être effectué, ils sont perdus ou appliqués de manière incomplète, donc si vous réglez la lumière annulaire dans ce laps de temps, ce réglage est perdu - 3ème : les contrôleurs walli (même filaires) ont des performances capricieuses lorsqu'ils sont inclus avec un niveau de sécurité => délai pour exécuter la commande, refus de l'opération (retour rouge), couleur de l'anneau non définie, aucune réaction au clic - 4rt : l'association avec un appareil zwave direct est possible mais n'est pas synchronisée avec les ordres reçus via les applications => si le BSO est ouvert avec une application, le walli ne connait pas ce statut et le 1er clic sur le bouton n'a aucune action sur l'appareil distant grâce à toutes ces (petites) connaissances j'ai trouvé des astuces pour contourner le système capricieux installé conseils 1 - tous mes appareils gérés avec le contrôleur walli sont inclus sans paramètre de sécurité (j'ai dû reconstruire toute la configuration car j'ai utilisé la sécurité sur ma première implémentation) astuces 2 - pour la lumière et le BSO (autre que le variateur de lumière) je n'utilise pas l'association directe (zwave) pour contrôler un appareil distant (lumière ou BSO) (pb 1, 4) => je règle toujours le type de contrôleur walli sur "scenarii" et j'écris pour chaque lumière un bloc pour gérer la lumière astuces 3 - pour FGD212 (dimming light), pas besoin de se synchroniser avec le walli en raison de la façon dont le FGD212 est géré, chaque clic sur le walli envoie une action au FGD212 (simple, double, long) donc le type de walli est réglé sur "dimming" => l'association directe zwave (groupe 6) est autorisée pour chaque walli avec FGD212, mais reste qu'il n'y a pas d'association de walli entre eux astuces 4 - pour les BSO (volet et lame) sur le pb4 j'ai ouvert un case avec le support fibaro, la seule réponse a été: gérez votre BSO avec le bloc de scène, donc j'écris 4 blocs de scène * 1 clic sur le bouton supérieur pour ouvrir => le bloc scène doit effectuer 2 actions : régler la position des lames à 100 %, puis ouvrir le store * 1 clic sur le bouton inférieur pour fermer => le bloc scène doit effectuer 2 actions : régler la position des lames à 0%, puis fermer le store * double clic sur le bouton stop supérieur ou inférieur * appui long sur le bouton supérieur ou inférieur pour régler la lamelle en position préférentielle ==> 50% (ou n'importe quelle position selon votre besoin) Remarque : n'utilisez pas de triple clic, sinon vous ne pourrez pas exclure l'appareil astuces 5 - pour l'état de l'anneau de couleur (pb2) j'ai 2 blocs de scène (même avec une lumière tamisée) : * coloré avec la lumière XX ON => le déclencheur se produit lorsque la lumière est allumée et la valeur définie est « vrai pendant le temps défini » * coloré avec la lumière XX OFF => le déclencheur se produit lorsque la lumière est éteinte et que la valeur est définie sur « vrai pendant le temps défini » la solution de contournement pour le pb2 est d'ajouter un temps (vrai pendant le temps défini) dans la condition de déclenchement de la section (2s suffisent) => avec cette astuce l'accusé de réception du clic sur le walli est affiché et donc le réglage de la sonnerie est appliqué correctement. comme le déclencheur est sur la lumière et non sur le mur, le type de mur n'affecte pas la scène J'espère que tous ces conseils pourront aider, car ce n'est pas évident de tous les trouver et de laisser le système stable et réactif avec la grosse config.

j'arrive en retard , mais c'est une super nouvelle que de savoir que c'est Boris qui a ouvert une nouvelle boutique en ligne sur les meme bases que feu domotique-store avant son rachat. bon chance , bon vent et surtout plein de commande pour cette année 2025

bonjour, as-tu trouvé une solution ? sinon , je ne vois pas dans ton explication ou schema à quoi correspond le module qui a remplacé le télérupteur ? (c'est quoi le modèle ? ) les interrupteurs sont des walli switch ? ou des interrupteurs standard et c'est quoi des boutons poussoirs ou des bistables ? En fonction de tes réponses les configs peuvent être différentes

j'ai eu la même chose réseau zwave bloqué par un module qui trop loin pour obtenir un dialogue correct, venait spammer les 3 ou 4 modules les plus proches et entrainait une surcharge de communication sur le réseau, tu type je ne vois pas mes voisins, y a t il quelqu'un , la réponse était tous les voisins oui moi , puis quelques secondes ou dixième après, de nouveau je ne vois pas mes voisins , ..... ça pollue même avec un module sur secteur et avec rien derrière. la solution a été d'arrêter le module de l'inclure en étant proche du contrôleur et de le remettre sur place une fois inclus.

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 ?

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.

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 .

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.

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

ok merci pour tes explications , donc à priori pas de sujet de ce côté edit: et pas de module bavard qui inonderait le réseau, le seul qui a une activité plus importante que les autres, est le module de captation/déclencheur de la luminosité extérieur, qui le matin et le soir envoi une série d'info toutes les minutes pour donner la nouvelle valeur en lux de la luminosité, ce dont j'ai besoin pour pouvoir gérer l'automate de la lumière sur seuil dans l'escalier extérieur (mais comme c'est toutes les minutes ça ne me semble pas se mettre dans la partie inondation !) .

oui ce que tu dis est parfaitement compréhensible , je pensais que la case à cocher dans la configuration de la HC3 pour chaque module était un moyen de faire dialoguer le module et le gestionnaire z-wave pour demander au module de ne pas envoyer de rapport du tout. Par ailleurs dans les paramètres HC3 pourr le walli controller il n'y a aucun paramètre qui permet de régler les envois de rapport non sollicité par le gestionnaire réseau, donc ceux déclenchés par le module j'ai l'impression que ces modules (walli controller) sont paramétrés en dur pour envoyer un rapport (dont la température) avec un seuil de delta ou / et avec une récurrence toutes les xx minutes. Je constate ces envois avec ne nouveau z-wave monitor pour tous les modules interrupteurs walli controller. Il faut que je regarde dans la doc parce que je crois me souvenir qu'il y a une séquence avec le bouton (et les couleurs des anneaux) dans laquelle on modifie ces rapports, même si c'est spécifié que cela est pour les modules qui sont sur batterie. Je vais fouiller de ce côté edit : je viens de regarder dans la doc : https://manuals.fibaro.com/wp-content/uploads/2024/07/FGWCEU-201-T-EN-f1.2-15.07.24.pdf plusieurs choses ne me semblent pas claires : indicator CC : je n'ai pas compris - 1 quoi ça sert , 2 comment on le modifie , 3 si la valeur pour la partie température est modifiable ?

pour ceux que ça branche je viens de faire un monitoring sur quelques heures et je m'aperçois que mes interrupteurs "walli controller" sur secteur (24v) qui ont un capteur de température intégré , remontent périodiquement la température alors que dans le paramétrage Z-wave dans l'onglet avancé j'ai désactivé tout pour cet Id du périphérique: - appareil masqué - appareil desactivé - Appareil exclu de l'interrogation et enregistrer dans l'historique n'est pas coché

bonjour, je commence ici un nouveau fil pour ouvrir les échanges au sujet d'un portage de HC2 vers HC3 du programme qui permet de monitorer Z-wave le fil de discussion est sur le forum anglais : https://forum.fibaro.com/files/file/184-z-wave-monitor/?do=findComment&comment=897 et les instructions de fonctionnement sont dans le 1er post : https://forum.fibaro.com/files/file/184-z-wave-monitor/ version courante : V3.2.1 installation: (rudimentaire) Téléchargement 1 - téléchargez les 2 programmes .lua Traitement du fichier Z-wave Viewer 2 - ouvrir le fichier Z-wave Viewer-vx.x.x.lua dans 1 éditeur (par exemple Notepas++) 3 - copier le contenu dans le presse-papier 4 - ouvrir un nouveau scénario LUA ==> nom suggéré "Z-wave Viewer" mais vous pouvez mettre ce que vous voulez 5 - copier (copier/coller) le contenu du fichier Z-wave Viewer-vx.x.x.lua dans la partie "ACTIONS" 6 - sauvegardez et notez l' Id du nouveau scénario ainsi créé Traitement du fichier Z-wave Monitor 7 - ouvrir le fichier Z-wave Monitor vx.x.x.lua dans 1 éditeur (par exemple Notepad++) et changez la valeur dans les variables d'entête de viewer_sceneId=322 par l'Id que vous avez noter pour le scénario "Z-wave Viewer" 8 - sauvegardez et copier le contenu dans le presse-papier 9 - ouvrir un nouveau scénario en mode LUA ==> nom suggéré "Z-wave Monitor" mais vous pouvez lui donner le nom que vous voulez 10 - coller le contenu du presse-papier dans la partie ACTIONS 11 - sauvegardez notez l'Id du scénario Lanceur Z-wave Monitor 12 - ouvrir un nouveau scénario en mode Block ==> nom suggéré "Lanceur Z-wave Monitor" mais vous pouvez lui donner le nom que vous voulez 13 - dans la partie "Puis faites" sélectionnez sur la gauche Scénario et coller dans "Puis faites" sélectionner "Z-wave Monitor" 14 - sauvegardez Variable globale (nota: les variables globales du système ne se créées pas automatiquement - ou alors je n'ai pas trouvé) 15 - aller dans paramètres/général/variables 16 - créer une variable standard avec le nom zwave_"Id-du-scénario-Z-wave Monitor" (sous la forme zwave_318) NB: si vous changez de scénario il faudra mettre à jour le nom de la variable globale ou en créer une autre avec le bon nom Voilà c'est terminer pour la partie installation Exécution: lancer le scénario "Lanceur Z-wave Monitor" Voir les résultats dans la console Les fonctions de lancement du viewer et d'arrêt du monitor sont intégrés dans les restitutions de la console NB: - à chaque nouvelle version du Monitor, il faudra mettre à jour la variable viewer_sceneId et il suffira de copier coller le contenu du fichier vx.x.x dans le scénario "Z-wave Monitor" , sauvegarder, arrêter le scénario et le relancer - à chaque nouvelle version du Viewer, il suffira de copier coller le contenu du fichier vx.x.x dans le scénario "Z-wave Monitor" , sauvegarder, arrêter le scénario et le relancer Z-wave Monitor-v3.2.1.lua Z-wave Viewer_v3.2.1.lua

j'ai très rapidement fait un portage sur HC3 des 2 programmes c'est basique et on a les résultats sous la console mais a ce stade les progs ne plantent plus vous trouverez les 2 progs : https://forum.fibaro.com/files/file/184-z-wave-monitor/?do=findComment&comment=897 @Lazer lorsque je regarde le monitor (tel qu'il est maintenant dans la console) j'ai énormément d'events de type "transfert OK" , est-ce normal ?