jluc2808

alors prenons le point du vue courageux, plusieurs choses me tracassent : 1 - j'ai commencé à regarder la solution sniffer zwave et je t'avoue être un peu perdu , parce que je n'ai pas compris si la solution étaient materiel (avec zwave.me) ou logiciel avec un pc ou même les 2 et comment tout cela communique avec la HC3 , sur ce point je ne suis pas à l'aise 2 - imaginons que je passe un peu plus de temps et que le point 1 soit maitrisé, ce que j'ai vu c'est que le sniffer te donne une tétrachiée de trame / log et du détail qui doit être interprété, la aussi je ne me sens pas à l'aise pour me plonger dans les trame et protocoles zwave 3 - imaginons que j'y arrive et que le point 2 soit acquis, il va falloir que je cherche une aiguille dans une botte de foin, je ne suis pas sur place pour voir ce qui se passe, constater les moments ou actions qui provoquent des latences, donc savoir dans la masse de trame ou, quoi, et quand chercher et je ne peux rester chez les clients en permanence, sachant que quand je teste, le fait même de tester provoque un comportement qui n'est plus aléatoire et ne me permet pas de constater ces problèmes diffus, présents, aléatoires dans le temps et dans l'espace. 4 - je réfléchis déjà à la suite: - déplacer les modules actionneurs du tableau pour les répartir ailleurs me sera impossible - déplacer les interrupteurs , la aussi impossible ou relier les inter aux modules actionneurs impossible - me reste simplifier les actions sur appuis interrupteurs enlever les changements de couleur par exemple ==> j'ai déjà discuté avec le client, là j'ai un refus de Mme qui est encore plus problématique que le déplacement des modules simplifier le fonctionnement des BSO ==> la réponse de fibaro pour lequel j'avais ouvert un ticket a été strictement la même plusieurs fois - seule la gestion par scénario est possible avec ma config (bouton en 24v et actionneur en 230v sans lien physique entre eux) transposer tous les automatismes de groupe sur les lumières et BSO dans home assistant plutôt que dans Home center ==> c'est déjà partiellement fait, mais je peux aller plus avant donc pour reprendre ton propos, la solution fainéante, si toutefois elle peut régler le problème des latences, ce dont je ne suis pas certains et qui fait l'objet de mes interrogations le démaillage va t il être pire que mieux mettre les box en slave ou les laisser indépendante le boulot de tout défaire et tout reprendre

Quand je parle de mettre une autre box, c'est pas remplacer celle existante, mais ajouter 1 hc3l et 1 hc3 pour couper le réseau en 3 et alléger chaque box avec 1/3 des composants. Sachant que les scénarios interbox se feront via mon ha ou en utilisant la fonction esclave des box ajoutées (solution maître esclave dont je ne suis pas fan)

Merci @lazer pour ces pistes, pour l'instant mon interval de polling est de 440s (ce qui est préconisé par la plateforme avec 110 modules) ==> à quelle valeur faut-il que je le mette ? je n'ai qu'un seul wall Plug dans la plateforme , donc je ne pense pas que ce soit lui qui genère le traffic , d'autant que ces latences existaient avant que je ne le rajoute la quasi totalité de mes modules et inter ont dans avancé : appareil exclu exclus de l'interrogation je vais voir pour la clé aeotec ? quand tu dis le forum officiel tu parles de quel forum ? et la solution de mettre d'autres box ?

bonjour, j'ai une HC3 ( avec une HC3L indépendante juste pour la partie du côté piscine elle est donc anecdotique, puisque avec 3 modules isolés sur la HC3L, donc dans mon propos je vais volontairement oublier cette partie) avec 110 dispositifs et 195 scénarios. la maison est à 3 niveaux de environs 120m² chacun. Tous les modules installés sont des fibaro. L'installation est composée : - des interrupteurs walli controller en filaire 24v alimentés par un transformateur 24v répartis sur toute la maison (pas de 230v dans les interrupteurs, mais un ancien 2 fils BUS SCS legrand) - les modules actionneurs FGS223 pour les lumières, FGR223 pour les BSO et FGD212 pour les lumières variables regroupés dans le tableau électrique au sous-sol (tous les anciens retours lampes et anciens BSO arrivent là) - les walli shutter + walli dimmer + walli switch sont regroupés au niveau R+1 dans 1 seule pièce. - la box fibaro HC3 est dans le même local au R+1 que les walli shutter/switch/dimmer (parce que c'est l'endroit qui a été créé et dédié aux raccordements technique - tableau secondaire, arrivée des prises Ethernet, onduleur, modules directement sur HomeAssistant, .... - au moment des travaux de rénovation) Lorsque cela a été possible (1 seul interrupteur pour 1 seule lumière) j'ai privilégié l'association directe zwave plutôt que les scènes. j'ai aussi énormément de scénarios pour mettre à jour les walli controller en fonction de la lumière qu'ils commandes (vert quand allumé et blanc quand éteint). j'en arrive à mon propos : - tous les modules fonctionnent individuellement et tous les interrupteurs actionnent les lampes ou BSO individuellement , lors de mes différents tests sans problèmes particuliers, s'ils sont testés unitairement ou après plusieurs actions sur les même dispositifs - par contre de manière aléatoire et significative, dans l'usage quotidien on se retrouve avec des latences significatives relativement importantes pour perturber les utilisateurs. ceci sur les BSO ou sur les lumières ON/OFF ou sur les lumières variables, principalement lorsque l'on utilise les interrupteurs. - Cette situation peut aller jusqu'à bloquer une action (mouvement d'un BSO ou allumage / extinction d'une lumière pendant plus de 30 secondes voire 1 minutes) même en utilisant Yubii ou directement l'application HC3. comme actuellement tout ce monde est piloté par la même HC3 et que je n'arrive pas à stabiliser le système pour supprimer les latences je me posais la question d'une évolution de la configuration pour remédier à cela ? solution ? : 1 - ajouter plusieurs HC3 ou HC3L pour répartir les charges sur plusieurs réseaux zwave en mettant les HC3(L) par étage. (HC3L ou HC3 si plus de 40 dispositifs) ce qui me retient ou me fait poster pour avoir votre avis c'est que tous les modules actionneurs sont actuellement au sous-sol R-1 dans un tableau dédié (modules montés en rail DIN avec eufix) parce tous les retours lampes arrivent là et il est inenvisageable de les déplacer pour les mettre ailleurs. De ce fait tous les interrupteurs du R+1 (ou RDC dans une moindre mesure) ne seraient plus relayés par le maillage zwave du RDC pour discuter avec les actionneurs qui resteront au R-1. Idem pour actionneurs des lumières externes qui sont aussi au R-1 et sont relayés par maillage divers sur la HC3 du R+1. 2 - mettre les HC3L en esclave ou les laisser chaque box indépendantes sachant que si je dois mettre en place des scénarios qui mobilisent plusieurs HC3(L) ceux-ci peuvent être mis dans mon HomeAssistant qui me sert d'hyperviseur et interface utilisateur. Sachant que ma dernière expérience avec une HC3L esclave m'a causé pas mal de souci - blocage complet de la HC3L et impossible à solutionner sans un reset usine et des modules fantômes qui trainent toujours dans ma HC3 ex-maitre sans pouvoir les supprimer. merci de vos avis et commentaires sur l'existant et les solutions pour le faire évoluer ci-jointe la couverture zwave

pour poursuivre la conversation sur ce comportement, si on fait un association directe (pour palier aux problèmes du serveur zwave absent) mais que l'on veut aussi avoir la fonction sur interaction avec l'application, le paramétrage du module en gestion de scène avec appui court 1 et 2 (scenario ouvrir et fermer les volets) et appui long 1et 2 (scénario position ouverte et fermée des lames) est-il possible ? dans ce cas qu'est-ce qui se passe sur appui bouton 1 / 2 ? - les 2 fonctions sont déclenchées (celle associé à l'association de groupe et le scénario adhoc) ou une seule qui vient bypasser l'autre ou il y a conflit et ça fait ce que ça veut ?

pour la seconde scène, qui va éteindre la lampe, je ne vois pas comment la déclencher, sauf à passer par une variable globale en plus sinon en lua ça donnerait quoi comme code pour attendre 5 minutes avant de faire un OFF ? @jojo je ne veux pas l'utiliser parce que les lampes sont aussi actionnables manuellement si on veut éclairer l'allée le soir pour une période plus longue, le scénario n'a son utilisation que pour le cas ou l'on veut éclairer le passage lorsque l'on rentre le soir.

bonjour, je cherche en mode block (et si pas possible en LUA) à faire scénario assez simple - j'ai un détecteur d'ouverture en zwave (en l'occurence un zooz détecteur d'ouverture) qui me permet de savoir si mon portail est ouvert ou fermé - sur ouverture si c'est la nuit je vaux allumer les lampes de l'allée extérieur (cablées sur FGS223 donc en ON/OFF simple) j'ai donc utilisé sur ma HC3 un mode block cependant dans ce mode je n'arrive pas à trouver comment mettre un délai de 5 minutes pour ensuite éteindre la lampe allée une idée ? merci

c'est pas == mais >= ou <= qu'il faut utiliser dans la partie déclencheur pardon j'avais vu toute la discussion, donc grilled par l'auteur lui-même

avais-tu essayé de faire une association avec autre chose que ton FGS223 vers FGS213 ?

A tout hasard as tu essayé de faire une association avec autre chose que le FGS223 avec tes fgs213 pour voir si c'est pas du côté fgs213 que le problème peut venir ?

essaye param 20 switch type : 2 assures-toi que les param 28 et 29 sont à 0 param 27 sans security mode après si marche pas il te faudra peut-être passer ton inter en bipilaire et pas en bouton poussoir compte tenu des param 31 / 32 et 35 /36 en bout du bout si toujours ko alors tu passes par les scènes ou sur clic du S1 FGS223 tu allumes / éteins le FGS213

les associations ne sont pas bonnes : il te faut associer le endpoint 0 utilisant groupe 2 vers ton 1er FGS213 pour S1, et endpoint 0 utilisant groupe 4 vers ton 2ème FGS213 pour S2 supprime d'abord les associations endpoint1 et endpoint2

Si c'est cela, c'est que ton associatio' n'est pas correcte ou pas effective, peux tu faire une copie d'écran de la partie association du FGS223 Nota No c'est normal ouvert et NC normal close

plusieurs points à contrôler : - ton câblage: est-ce ton inter (bouton poussoir) est correctement alimenté sur la phase (et pas le neutre) et est en mode raccordé sur le FGS223 via le NO - test1 une lampe du FGS223: raccorde une lampe sur le FGS223 (Q1) et assures-toi que le poussoir S1 fait fonctionner la lampe - association : tu as 2 associations groupe 2 (S1 en ON/OFF) et groupe 4 (S2 en ON/OFF) - il me semble qu'il faille utiliser l'association multi-channel et pas l'association simple , regarde aussi si les association lifeline du FGS223 sont OK pour remonter les interrupts aux contrôleur de réseau - test2: une fois les associations faites test si quand tu allumes la lampe (du FGS223) ça déclenche l'allumage / extinction de ton FGS213 - via l'interface et via le bouton poussoir en dernier sur une autre box (eedomus) il me semble me rappeler que le S2 ne fonctionnait que sur le polling, c'est à dire que les status ne remontait que lors des pollings , je ne sais pas si c'est le cas avec la HC fibaro et si ça une incidence

@Bartim oui avec un switch et un dimmer ce que tu décris fonctionne très bien, je n'ai pas un switch mais un walli controller parce que je n'ai pas du 220v à la prise, seulement du 24v ce qui me limite un max, l'association entre controller et dimmer marche que dans un seul sens controller vers dimmer pas dans l'autre ce qui fait que le controller ne sait pas si la lumière est ON/OFF (à part passer par des scénarios, ce que j'ai été obligé de faire), d’où le double appui pour simuler le ON même si déjà ON. Après de très longues recherches j'en suis arrivé à la conclusion que seul les scénarios peuvent répondre, ON appui haut et OFF appui bas dans tous les cas ça fonctionne sauf si le gestionnaire de réseau n'est plus là et malheureusement de temps en temps j'ai de la latence en fonction de l'occupation du gestionnaire réseau.

Je pensais juste.a un Ping pour m’assurer que le device était vivant et on. pour répondre à tes interrogations légitimes je ne voulais pas ni de Zigbee ni de Z-Wave ni de DIo , ni io ni rts pour permettre de rendre la prise indépendante de toute box , puisque je peux en cas de pb box consulter directement via le wifi et via le cloud et relancer mon équipement sur la prise en faisant un off/on de la prise , pour être plus précis sur la prise j’ai un Homeassistant qui me sert uniquement d’hyperviseur mais qui intègre des périphériques qui ne sont pas intégrables à homecenter. J’ai déjà eu besoin de faire une relance physique du ha. pour le coup ça m’a semblé plus simple de mettre une prise sans box, mais c’est comme tout en Domotique on a tellement de possibilités qu’il faut choisir . donc pour en revenir à nos moutons . Est il possible de faire un Ping toutes les 5 minutes pour voir si le périphérique répond?

Bonjour, j’ai installé un prise wifi (meross mss310) pour pouvoir redémarrer un équipement en cas de problème si je suis à distance , mon wifi est stable (Ubiquiti) et ma est sur onduleur (15 minutes d’autonomie garantie , voire plus mais je garde un sécurité) Je souhaite contrôler que cett prise est en vie via ma hc3. pouvez vous me guider pour cela. si nécessaire je peux utiliser gea merci

j'ai déjà essayé http ou https et c'est pareil - erreur ATTENTION: je ne suis pas en train de demander comment se connecter en local sur la HC3 , mais bien sur la HC3L Nota: j'ai l'impression que la HC3L ne peut être accédée que via le cloud ? (la coche connection à distance dans la partie utilisateur est grisée et semble être sur ON) - mais je me trompe peut-être

j'ai par acquis de conscience demandé au support fibaro comment supprimer les modules fantômes sur la master (HC3) qui restaient après suppression de la slave (HC3L) ou je suis complètement noeuneud dans la question ou c'est eux qui me prennent pour un noeunoeud - la solution : faire un reset factory de la HC3 (master) pour supprimer les 4 modules fantômes sur 200 installés !!!!!

j'ai donc ma HC3 et ma HC3L qui sont maintenant opérationnelle, le superviseur HA fait son boulot et me permet d'avoir tous les modules / équipements remontés sous 1 seule interface, les automatismes entre les modules sur la HC3 et la HC3L sont maintenant gérés directement sous HA et fonctionnent correctement . C'est concluant et je vais donc rester dans cette situation, qui me va et ne nécessite pas d'ajout d'autres logiciel ou développements. j'ai malgré tout 1 souci avec la HC3L (probablement parce que je ne sais pas m'en servir complètement) - j'ai via l'interface home.fibaro.com la possibilité de me connecter sur la HC3L (https://home.fibaro.com/fghc3-beta/5.141/app/dashboard) ce qui m'ouvre la boite de login à la HC3L - je souhaitais pouvoir m'y connecter en directe sur le réseau local avec son adresse IP que je trouve sous réseau de la config sauf que j'ai un refus de tous les navigateurs (y compris après vidage des caches et cookies) - chrome, firefox, opéra, .... avec la menton ce site est inaccessible j'ai tenté avec http ou https://IP_de ma_HC3L j'ai même essayé https://hc3l-00052244.local et ça ne marche pas non plus j'ai loupé quelque chose ?

oui pardon, même si je n'ai pas fait de reset des modules, mais 5 modules qui tombent en panne en même temps avec le même symptôme, 1 des modules qui a été appairé correctement sur une autre box et le process d'appairage de la HC3L qui détecte bien le module mais qui reste en rade sur la partie interrogation des voisins, tu as peut-être raison mais ...... je verrais demain si la mise en service avec HA comme superviseur me donne satisfaction sinon j'irais vers AOQ, mais comme je suis chat noir je crains de tomber sur encore un truc chelou

@lazer , tout d'abord merci de consacrer du temps et de prendre du tiens pour me répondre - l'exclusion / inclusion des modules n'a pas réglé les problèmes, parce que visiblement c'est la HC3L qui avait un problème - oui j'ai utilisé la procédure standard de maitre / esclave pour faire le couplage entre les 2 box - je suis en version beta sur la HC3 (j'aurais peut-être pas dû, mais les difficultés avec mes BSO m'ont poussés à voir si cette version ne réglait pas ces soucis, ce qui semble quand même être le cas, en tout cas pour les BSO). Avec ma tentative de retour en version stable qui s'est soldée par beaucoup de problème (entre la db de la box et les paramètres des modules), je suis donc condamné à rester sur cette version pour la HC3. - si je laisse les 2 box indépendante je peux avec des version différentes entre le HC3 et la HC3L, alors que si je les remets en maitre / esclave je dois obligatoirement les avoir avec la même version. ==> après réflexion, le fonctionnement maitre / esclave ne va pas m'apporter grand chose puisque je n'ai en bout de course qu'un seul module de la HC3 et 1 seul module de la HC3L qui nécessite un automatisme, que je peux gérer par HA, donc je vais rester avec les 2 box qui ne se connaissent pas et gérer l'intégration dans HA, qui héberge l'interface utilisateur courante pour les utilisateurs quotidiens. Cela aura aussi pour avantage d'éviter d'utiliser une fonction qui pourrait interférer, si d'aventure la HC3L revenait à 'bloquer' le fonctionnement des modules qui lui sont accrochés. Nota: le problème avec le support FIBARO, quand on ouvre un ticket, c'est qu'ils mettent trop de temps à prendre en compte et répondre, ne serais-ce que pour comprendre ce qui se passe, j'ai constaté entre 3 jours et 5 jours pour la 1ère réponse voire plus de 8 jours sur une relance, ce que je ne peux attendre avec une box qui ne fonctionne plus.

dans le feuilleton, je suis maudit les problèmes s'accumulent (les puces ont décidé de rester sur le même chien ) - avec le dernier firmware 5.141.59 j'avais mis un HC3L en esclave de ma HC3 pour palier à un manque de couverture du réseau Zwave sous la piscine (la couverture wifi est OK, mais pas la couverture zwave de la box principale) - inclusion des modules FGS223 et FGS224 avec la HC3L (donc en esclave) - intégration du tout sur HA - test ==> tout fonctionne et je peux commander les lampes + contact sec avec HA ou Nubi après 10 jours de bon fonctionnement et sans aucune modification les modules (tous) appairés via la box esclave, tout d'un coup ne sont plus opérationnels (plus de ON/OFF, pas de statut remonté, impossible d'aller au bout d'une inclusion d'un nouveau module) toutes les tentatives suivantes se sont avérées inefficaces : - interrogation des paramètres - reconfiguration douce - reconfiguration complète - exclusion puis inclusion du module (échec de l'inclusion que ce soit avec ou sans sécurité S0, S2, sans ou même avec que détection locale) - reboot de la HC3L (inclusion impossible) - restauration d'une sauvegarde avant bug (inclusion impossible) - recovery sans perte de données (inclusion impossible) la seule solution : reconfiguration complète usine de la HC3L (procédure pas évidente avec la HC3L) - les autres donnent les même erreurs - reboot hardware en maintenant le bouton R (à oui comme dans la doc il est pas préciser que le R est le bouton à droite et que la gravure n'est pas simple à lire, je précise pour ceux qui n'ont pas de bons yeux que c'est le bouton droit en regardant les 2 boutons) - se connecter sur le wifi de la box HC3L (met un certains temps avant d'apparaitre, le mdp wifi c'est celui écrit derrière la box) - se connecter avec le compte admin et le mdp qui avait été donné en tant qu'esclave - là choisir recovery complet avec perte de données - ça prend un certains temps - on perd toutes les sauvegardes locales et je n'ai jamais trouvé comment récupérer la sauvegarde cloud après bataille et reconfiguration complète - test inclusion - OK à ce stade je me pose la question : 1 - si le fonctionnement en maitre/esclave est la bonne solution (compte tenu des restrictions d'usage que cela amène - pas toutes les fonctionnalités disponibles sur la box en esclave) 2 - ou si je ne laisse pas les 2 box HC3 et HC3L avec les 2 réseaux Zwave indépendants, que je fasse l'intégration et le couplage des modules qui le nécessite via le pont HA en utilisant les automatismes via les automates / scènes dans HA en direct ? 3 - ou si il y a une autre solution que je ne connais pas ? 4 - Une solution qui m'a été proposée sur le forum fibaro officiel est d'utiliser AOQ (https://forum.fibaro.com/files/file/376-hc3-all-in-one-qa/) mais là j'avoue humblement que je n'ai pas compris ce que faisait cet applicatif et comment l'utiliser (et comme je suis chat noir, si je ne vais pas tomber sur un bug et une galère) nota: j'ai posté (reposté) ici parce que ce qui arrive me semble relever d'un bug de la HC3/HC3L

bon sur ton conseil , j'ai posté sur le forum officiel: https://forum.fibaro.com/topic/66764-module-state-with-hc3-when-hc3l-is-slave/ maintenant pour ceux qui ont déjà mis en œuvre une box en slave, est-ce que vous avez (ou pas) la notion de connecté / déconnecté pour les modules inclus sur la box esclave qui remonte sur la box maitre ? en complément, est-ce que je peux dans GEA tester la notion de "dead" comme sur les modules inclus dans la box maitre ?

bonjour, Pour rappel ma HC3L est maintenant esclave de ma HC3. Elle est accessible via home.fibaro.com j'ai un souci avec les modules qui sont connectés sur la HC3L. est-ce normal que je n'ai aucun retour d'info sur la vie / ou non vie des modules qui sont sur la HC3L (pas d'info de type déconnecté) , j'ai l'impression qu'ils ne sont plus accessibles mais comme je ne vois rien sur la HC3 et qu'ils ne sont plus listés sur la HC3L , comme fait-on pour avoir un statut de ces modules ? le symptôme: quand je veux allumer les lampes associées à ces modules (2 FGS223) rien ne se passe.