jluc2808

oui mais j'aimerais bien que la puce change de chien !!!

oui, oui , la perte des modifs était attendue, mais effectivement ça a mis les modules et la db en mauvaise situation / position bancale, j'ai bien tenté dans l'ordre : - relecture complète par interrogation, - puis réinitialisation des paramètres, - puis reconfiguration douce, - puis reconfiguration sans succès après chaque action, par exemple impossible de lancer une calibration sur les BSO ou même sur les variateurs qui avaient été modifiés auparavant. donc comme tu le suggères état inadéquat entre eeprom module et la db box ==> seule solution exclusion , puis inclusion (lorsque ça marche) et là en l’occurrence ça marchait pas, mais pas que pour 1 module, après 5 reboot, j'ai craqué et mis à jour la version puis plus de soucis.

Dans 1 premier temps : j'ai finit par me résoudre à faire une restauration de la config avec l'ancienne version (et donc du paramétrage sans les modifications) pour voir mauvaise idée , après restauration, j'ai perdu toutes modifications que j'avais faites dont celles sur les BSO, mais ça je m'y attendait donc c'est normal mais j'ai eu la très mauvaise surprise d'une instabilité plus marquée que au moment de l'ancien fonctionnement, ça c'était pas prévu. Dans les instabilités, quasi impossible d'exclure un périphérique ou d'ajouter un périphérique (ceux ajouté entre temps, bien entendu en passant d'abord par exclusion), symptôme de blocage de la fonction exclusion ou inclusion qui ne se termine jamais et enfin impossible de relancer la fonction (message : le réseau est déjà pris pour cette action) ==> obligation de faire un reboot pour retrouver la fonctionnalité. En plus, un fonctionnement très aléatoire de certains interrupteurs (walli controller donc en association directe zwave avec les lampes) et un fonctionnement quasi impossible des témoins anneaux lumineux des walli. ==> donc à y être (dans la m....) : réinstallation (pas restauration) de la nouvelle version + exclusion / inclusions des quelques périphériques qui me posaient problème et là miracle tout est rentré dans l'ordre, y compris les paramétrages fantômes qui ont disparus. depuis ça semble stable, mais je n'ai que 24h de recul (rappel version 5.141.59 beta). j'ai ajouté une HC3L en esclave pour les périphériques qui ne fonctionnaient pas bien sous la piscine. Parfait j'avais ajouté un AP Ubiquiti à côté du local piscine avec une assez bonne couverture dans le local piscine, de ce fait la HC3L fonctionne parfaitement en esclave dans ces conditions. L'appairage des modules avec la HC3L à donc résolu les problématiques de couverture Zwave qui ne passait que très peu dans le local piscine.

oui je pense qu'une restauration soit le moyen , mais comme je le disais je ne voudrais pas perdre toutes les modifications sur les BSO qui sont dans cette dernière release j'ai ouvert un ticket chez fibaro https://support.fibaro.com/helpdesk/tickets/266245

c'est bien malheureux, dommage pour avancer parce que je ne peux pas rester comme cela, j'ai poussé un peu les investigations et je pense que je suis tombé sur un bug de la dernière release : 5.141 Beta j'ai désactiver tous les scénarios et n'est laissé que les 2 qui touchent à la couleur des anneaux du walli controller - vert quand FGD212 est allumé et blanc quand FGD212 éteint je retrouve mes 3 demandes de paramétrage sur 150, 150 et 151 dont 1 en blanc (valeur 1) pour pousser le test, j'ai aussi désactiver les 2 scénarios restants et regarder ce qui se passe à la console ==> plus de demande intempestive de paramétrage sur le 150 j'ai alors mis qu'une seule demande dans le scénario , soit 150 (anneau supérieur) à 3 (vert) ==> là ça marche j'ai refais avec juste le 151 (anneau inférieur) à 3 (vert) ==> là aussi ça marche c'est quand je mets les 2 avec un et que se produit le bug j'ai alors 3 demandes de paramétrage 150 à 3, 150 à 1, 151 à 3 le retour c'est 150 à 1 et 151 à 3 j'ai refais plusieurs fois pareil ==> donc il y a un bug introduit avec la 5.141 j'ai pas encore testé en LUA direct pour voir si c'est pareil et via GEA je ne suis pas parvenu à mettre au point cette séquence (c'est une autre discussion avec @lazer) ==> test en LUA demain j'ai fais 2 scénarios séparés avec chacuns le paramètre 150 et l'autre 151 , là ça fonctionne pour les couleurs des anneaux, malheureusement ça reset systématiquement le % de luminosité à 100%, alors qu'avec la release précédente je n'avais pas ces bugs . ce qui me semble bizarre c'est que ce bug je ne le retrouve qu'avec du FGD212 pas avec les lampes du FGS223 et comme pour faciliter j'ai noté que cette séquence perturbait les autres scénarios de type 1 clic pour baisser les BSO. question : y a t il un moyen de revenir sur l'ancienne version ? (à part une restauration complète, ce que je ne veux pas faire avec les modifs importantes sur les BSO qui sont avec cette nouvelle release)

bonjour , j'ai un souci avec un paramètre qui est modifié par quelquechose dont je n'arrive pas à savoir pourquoi, donc je viens ici pour savoir si sur le HC3 on a la possibilité de mettre des traces pour savoir quel est le module ou le scénario qui a déclencher un ordre - dans la console je vois bien ceci [29.06.2023] [17:08:59] [TRACE] [ZWAVE]: ID 386: Set parameter 150, value = 3 [29.06.2023] [17:08:59] [TRACE] [ZWAVE]: ID 386: Set parameter 150, value = 1 [29.06.2023] [17:08:59] [TRACE] [ZWAVE]: ID 386: Set parameter 151, value = 3 [29.06.2023] [17:09:00] [TRACE] [ZWAVE]: ID 386: Received parameter 150 report, value = 1 [29.06.2023] [17:09:00] [TRACE] [ZWAVE]: ID 386: Received parameter 151 report, value = 3 [29.06.2023] [17:29:28] [TRACE] [ZWAVE]: ID 386: Set parameter 151, value = 1 [29.06.2023] [17:29:28] [TRACE] [ZWAVE]: ID 386: Set parameter 150, value = 1 [29.06.2023] [17:29:28] [TRACE] [ZWAVE]: ID 386: Set parameter 151, value = 1 [29.06.2023] [17:29:29] [TRACE] [ZWAVE]: ID 386: Received parameter 150 report, value = 1 [29.06.2023] [17:29:29] [TRACE] [ZWAVE]: ID 386: Received parameter 151 report, value = 1 j'ai un interrupteur dont l'iD = 386 qui est association directe zwave avec un variateur FGD212 allume/éteint/dimmer et 2 scénarios qui sont déclenchés par l'allumage et l'extinction du FGD212 pour envoyer les set sur 151 et 150 , mais là je trouve 3 ordres, cela veut dire que l'ordre sur 150 = 1 est envoyé par quelquechose en plus de mes scénarios parce que pas dedans Je cherche depuis 2 jours en regardant tous mes scénarios 1 : 1 mais j'ai rien trouvé donc je voudrais savoir qui déclenche cet ordre en plus ==> d'ou ma question sur comment on peut faire avec une HC3 pour savoir qui envoi l'ordre ?

je reviens et complète ce post : 1 - j'ai enfin réussit à mettre au point le fonction de tous les BSO (non sans mal) la solution est ce qui suit: 2 - certains modules FGR223 ne répondait plus aux paramétrages - notamment la demande de calibrage ou les modifications de certains paramètres 155 - dans le cas le plus complexe - ne répond plus aux positionnement des paramètres - - tentative de reconfiguration douce ==> si KO - tentative de réinit des paramètres complet ==> si toujours KO - exclusion puis réinclusion 3 - paramétrage - paramètre de mode en store vénitien (151 = 2) - lancer une calibration (obligatoire même si on doit changer des valeurs après) (150 = 2) ==> attendre tout le cycle (descente / montée / descente / montée) - reprendre les paramètres 154 (motor operation detection) = 1 (le minimum) pour éviter d'avoir le phénomène de redescente de quelques centimètres après ouverture complète - paramètre 154 (delay motor stop after riching end) = 0 (permet de pas avoir d'attente pour refaire une action si position haute ou basse) 4 - utilisation d'un interrupteur non connecté (donc pas sur S1 ou S2) de type walli controlleur - mettre en mode scène (ne fonctionne pas complètement en mode association directe Zwave) - selection des scènes : 1 - appui court haut et bas pour monter ou descendre - 2 appui courts sur haut ou bas pour stopper le mouvement - 1 appui long sur haut ou bas pour orientation des lamelles (note j'ai noté que le relâché n'avait pas de conséquence donc je ne l'ai pas programmé) voilà avec cela toutes les fonctions sont disponibles - montée / descente / positionnement des lames - avec l'application ou avec les boutons note : il est possible (ce que j'ai remarqué) que suite à une série de manipulation avec l'application, le 1er appui court sur l'interrupteur ne déclenche rien , même si acquitté avec une lumière verte par l'interrupteur, je n'ai pas trouvé quand (pas tout le temps) ni comment y remédier (comme on est devant c'est pas trop génant) dans ce cas refaire un appui court pour déclencher (comme l'appui court haut ou bas n'a qu'une seule fonction, ce n'est pas génant) note 2: si vous avez positionné les lames à une position donnée (autre de fermée 0% ou ouverte 100%) via l'application ou une scène avec un favori alors ce positionnement sera mémorisé pour les actions qui suivront. cela a pour conséquence , repositionner le store pour lui permettre de redonner cet orientation en cas d'ouverture complète de ce dernier, donc il redescend un peu et positionne les lames à x%. Afin d'éviter ce comportement, ajouter aux scènes (appui court - donc monter ou descente) un positionnement des lames - donc avec montée position ouvertte = 100% et appui court descente - appui court fermer = 0% voilà j'espère que cela pourra servir à quelqu'un, mais j'ai tellement galéré avec ce couple que passer 10 mintes pour en faire la description complète n'est pas du luxe.

j'utilises des bornes ap ubiquiti pour le reseau donc je vais voir ce que donne celui-ci via le controleur qui est un dream router. sinon il me restera le cpl, mais comme tu le dis la hc3L n'est qu'en wifi, la chaine serait wifi ==> cpl ==> reseau éléctrique mal foutu ===> cpl ===> dream router (qui gère le reseau hc3) c'est pas génial donc je compte sur mes bornes ubiquiti pour faire le job

je galère toujours avec le pilotage de mes BSO via walli controller (les BSO sont gérés par des FGS223) y compris en faisant un ticket au support fibaro les réponses sont 'bof' - je n'arrive pas à faire fonctionner correctement l'association directe walli (en mode store vénitien) et FGS223 (en store bénitien) ==> nécéssite en fonction de l'état un appui double (pas un double clic) ou simple - le support me dit de passer par des scénarios ==> walli en mode scénario sauf que dans ce cas l'appui simple fait monter (ou descendre si haut ou bas) mais pas le stop qui doit être programmé sur un autre scénarion par exemple double appui - l'appui long est alors réservé à l'orientation des lamelles et galère avec le relâché - vient de rajouter le calibrage du FGS223 qui 'déconne' bon bref si vous être tatillon avec des BSO pour l'instant je déconseille la solution - si vous pouvez mettre des walli roller shutter , ça marche bien alors n'hésitez pas

si tu as ça il faut commencer par l'exclure et ensuite si l'exclusion est OK tu pourras l'inclure , j'ai déjà eu le coup. attention pour l'exclure bien suivre la procédure qui n'est pas la même que pour l'inclusion, activation par 3 appuis bref du menu du walli , tout de suite 1 autre appui bref pour commencer la séquence de déroulement du menu et lorsque tu es sur la fonction exclusion (voir la couleur de la fonction) un autre appui pour confirmer (je ne me rappelle plus la couleur de l'exclusion)

bonjour, j'ai une zone de la maison qui est particulièrement difficile a atteindre avec la HC3 malgré pas mal de modules fibaro walli (sur secteur) répartis dans la maison. Régulièrement je retrouve les 2 FGS223 qui sont supposés commandés 4 lampes en 'dead' et leur réactivation via GEA n'est pas non plus très performante. (Pour info ces modules sont dans le local piscine sous la piscine). Donc j'envisageais de mettre dans le local piscine une HC3L connectée en WIFI et en esclave de la HC3 (je n'ai pas la possibilité de relier en ethernet filaire) pour piloter ces 2 modules et par la suite 2 autres FGS224 pour la partie contact sec. 0 - le fonctionnement en wifi de la HC3L pose t il problème ? 1 - comme c'est la 1ere fois que je fais cela (ajouter une box esclave) voyez vous des recommandations ou précautions ou même contre-indications à me donner ? 2 - en lisant ce qui est décrit sur la fonction esclave j'ai cri comprendre que les modules 'récalcitrants' devaient être appairés à la box esclave ? ou il n'y a pas de distinctions dans l'appairage ? 3 - en corolaire du 2 dois-je exclure les modules existants 'récalcitrants' pour les réinclure ? 4 - les scénarios avec ces modules se font avec la box esclave ou il n'y a pas de distinctions ? désolé si ces questions vous semblent triviales voire inopportunes, mais je préfère demander avant de me planter.

@Lazer merci de ces explications pour les variables avec ton explication je pensais utiliser une variable 'locale' pour mettre: - donner un nom aux id plutôt que les id eux même, c'est plus parlant - stocker les valeurs de temps de montée des BSO et utiliser les VariableCache pour les changements d'état, après réflexion, le risque que la valeur 'MOUVEMENT' soit transformer en 'ATTENTE' si redémarrage de GEA en cours de mouvement d'un volet avec une action stop au milieu est suffisamment faible pour tester avec ce mécanisme. je verrais comment tester la différence entre scène et GEA, surtout sur la partie réactivité qui est le point end-user le plus sensible.

merci de cette syntaxe, pour ma gouverne - sera-t-il mieux ou plus efficace d'utiliser (comme suggéré) une VariableCache qu'une variable dite locale ? - si je ne veux pas que ma variable soit réinitialisée à chaque démarrage de GEA et si je veux conserver sa valeur dans tous les cas, dois-je plutôt utiliser une variable Globale ? dans la doc (très bien faite - merci @Lazer) il est mentionné la structure de GEA.add(condition , durée, notification, action) avec 4 arguments, alors je n'ai pas compris le 5ème argument "Démarrage GEA" En terme de performance et de réactivité, vaut-il mieux utiliser des scènes (j'en aurai 5 + 1 variable pour faire la gestion du BSO) ou le passage par GEA sera-t-il plus efficace (moins consommateur de ressource, plus réactif, plus fiable en exécution, ...) ?

@jojo oui c'est exact, j'ai implémenté au début avec GEA.add({"Deads"}, 30, "test de tous les modules pour savoir s'il y a un qui est mort", {"Deads"}) j'en ai régulièrement 1 qui se retrouve dans cette situation, j'ai mis une notification spécifique sur ce module. Il s'agit d'un FGS223 en limite du réseau zwave et qui ressort (via l'appli z-wave_network_hc3_correct.php) comme n'ayant pas de lien avec le reste (ce qui me semble bizarre) puisque une fois que j'ai pu le "reconnecter" il fonctionne, mais visiblement pas bien , puisque je le retrouve dans les Dead de temps en temps.

OK, la logique sera la suivante Pour la variable - une variable "statut_bso_dressing" qui va prendre les valeurs "ATTENTE" par défaut - qui prendra la valeur "MOUVEMENT" si on fait 1 clic haut ou bas sur l'interrupteur si sa valeur était ATTENTE - qui repassera dans tous les cas à "ATTENTE" après la valeur en seconde du temps de montée (paramètre 156 du BSO) Pour les actions - si 1 clic haut sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Open" et on passe la variable statut_bso_dressing à "MOUVEMENT" - si 1 clic haut sur inter et valeur de statut_bso_dressing = MOUVEMENT alors on déclenche l'action "Stop" et on passe la variable statut_bso_dressing à "ATTENTE" - si 1 clic bas sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Close" et on passe la variable statut_bso_dressing à "MOUVEMENT" - si 1 clic bas sur inter et valeur de statut_bso_dressing = MOUVEMENT alors on déclenche l'action "Stop" et on passe la variable statut_bso_dressing à "ATTENTE" - si 1 clic long haut sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Value2 (position des lamelles)" à 99 (ouverte) et on passe la variable statut_bso_dressing à "ATTENTE" - si 1 clic long bas sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Value2 (position des lamelles)" à 0 (fermée) et on passe la variable statut_bso_dressing à "ATTENTE" sur la base de cette logique (merci de me dire si j'ai omis quelque chose ou fait une erreur) @lazer me propose d"utiliser VariableCache pour la variable - même en regardant la documentation j'ai un doute sur comment déclarer cette VariableCache ? pour déclarer la variable est-ce que je dois mettre GEA.add("VariableCache", "statut_bso_dressing", "ATTENTE") ou GEA.add(true, -1, "déclaration VariableCache statut_bso_dressing", {"VariableCache", "statut_bso_dressing", "ATTENTE"}) ou tout simplement local statut_bso_dressing = "ATTENTE" et ensuite utiliser GEA.add({"VariableCache", "statut_bso_dressing", "ATTENTE"}, -1, "", {Action}) dans tous les cas est-ce que ma variable repassera à ATTENTE toutes les 30 secondes ? (cycle GEA) désolé si tout cela est trivial pour vous et d'avance merci pour vos réponses

ce qui m'a induit en erreur c'est que dans le json on trouve "CentralSceneSupport" et pas "CentralSceneEvent" et que le LUA met "Property=CentralSceneEvent", comme tu le dis trompeur! merci de cette rectification.

bonjour , je reviens vers ce topic avec quelques infos et pas mal de galères et tests - mes FGR223 sont utilisés pour gérer des BSO avec des moteurs filaires, mais dont les fils arrivent au tableau électrique et pas au niveau des interrupteurs - pour l'histoire les interrupteurs sont des Walli controller alimentés en 24VDC, pour utiliser les anciens fil bus legrand SCS. après installation du FGR223 et paramétrage en store vénitien, j'ai lancé une calibration ==> 1er déboire - suite à la calibration les BSO, lorsque l'on ouvre complètement le BSO après être arrivé en butée position ouverte, il s'arrêt quelques secondes redescend de quelques cm avant de s'arrêter définitivement - j'ai pu faire la correlation entre le nombre de cm de redescente et le paramètre 152:Venetian blind - time of full turn of the slats plus le temps est long et plus le volet redescend, par exemple : si 1,5s ==> redescente de 5cm, si 3s ==> 10cm, si 6s ==> 20 cm comme on ne peut pas mettre 0s il faut chercher un autre paramètre pour régler le pb - Paramètre 155: Motor operation detection par défaut il est à 10W là aussi il y a correlation entre ce paramètre et le nombre de cm de redescente : 5w ==> 2cm, 10W ==> 10cm, 20W ==> 20cm par contre ce paramètre peut être mis à 1W , ce qui supprime la redescente tout autant que le paramètre 152 ne soit pas trop grand (par exemple 1,5s) - fort de tous ces tests, j'ai donc réinitialisé tous les paramètres du FGR223 et gardant en mémoire les paramètres 156 et 157 qui donnent les durée de descente et montée - puis remis les paramètres 156 et 157 aux valeurs de montée et descente, mis le 152 à 1,5s (durée de rotation des lamelles) et mis le 155 à 1W (detection de fonctionnement du moteur) avec cela j'ai un comportement acceptable , même si je ne peux plus fait de rotation intermédiaire des lamelles, elles peuvent être ouvertes ou fermées.

bon pour l'instant avec le code déjà en place je n'ai pas de déclenchement -- si appui 1x sur bouton haut id=521 inter fenêtre dressing, alors ouvre le BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed"},-1,"ouverture du BSO dressing",{"Open", 148}) déjà cette partie ne fonctionne pas, je ne vois aucun déclenchement sur appui court de l'inter en question via la console. c'est donc que mon code n'est pas bon. j'ai essayé de transposer en GEA une scène qui fonctionne { conditions = { { id = 521, isTrigger = true, operator = "==", property = "centralSceneEvent", type = "device", value = { keyAttribute = "Pressed", keyId = 1 } } }, operator = "all" }

bonjour, je voudrais votre retour sur ce code -- test pour bso -- si appui 1x sur bouton haut id=521 inter fenêtre dressing, alors ouvre le BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed"},-1,"ouverture du BSO dressing",{"Open", 148}) -- si appui 1x sur bouton bas id=521 inter fenêtre dressing, alors ferme le BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "Pressed"},-1,"fermeture du BSO dressing",{"Close", 148}) -- si appui 2x sur bouton haut ou bas id=521 inter fenêtre dressing, alors stop le BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed2"},-1,"stop du BSO dressing",{"Stop", 148}) GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "Pressed2"},-1,"stop du BSO dressing",{"Stop", 148}) -- si appui long sur bouton haut id=521 inter fenêtre dressing, alors ouvre les lamelles du BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "HeldDown"},-1,"ouverture lamelle du BSO dressing",{"Value2", 148, 99}) -- si appui long sur bouton bas id=521 inter fenêtre dressing, alors ouvre les lamelles du BSO id=148 BSO dressing GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "HeldDown"},-1,"fermeture lamelle du BSO dressing",{"Value2", 148, 1}) -- fin test bso Pour l'instant j'ai mis 2 clics pour faire un stop, ce qui n'est pas très intuitif pour l'utilisateur, mon objectif serait de n'avoir qu'un clic pour ouvrir (bouton haut) ou fermer (bouton bas) et si en court de mouvement le même clic fait un stop pour faire cela je pensais ajouter une variable avec l'état "ATTENTE" qui change d'état si il y a déjà eu 1 clic (haut ou bas) "MOUVEMENT", dans ce cas je ne sais pas comment remettre la variable à "ATTENTE" parce que le retour d'état/position du BSO n'est pas fiable et surtout met un certains temps aléatoire avant d'être remonté, quand c'est remonté, donc je peux pas m'en servir pour repasser la variable à "ATTENTE" débutant avec GEA j'aurais besoin de votre aide pour ce sujet. NOTA: le BSO est géré par un FGR223 au tableau électrique et les boutons sont des Walli controller sur secteur dans les plots d'encastrement dans les murs, je n'ai pas la possibilité de lier l'inter avec les commandes en filaire et avec la fonction association directe zwave ça ne fonctionne pas correctement.

comme ça fonctionne correctement avec les scènes et que j'ai un autre sujet plus épineux , je vais laisser en l'état (des scènes) et je reprendrais quand j'aurais réglé le sujet lui plus embêtant que je poste après.

en fouiillant j'ai trouvé dans la partie déclencheur il ne faut pas utiliser le module BSO en tant que tel, mais dans les enfants la telco associée au BSO qui elle supporte les scènes qui sont validées dans le paramétrage du module (parent / enfant)

bonjour , avec les walli roller shutter FGWREU-111, on peut dans les paramètres activer les scènes (1,2,3 appui et appui long) pour chaque bouton. je voudrais récupérer ces infos dans les scénarios, cependant quand je suis en mode bloc, dans la partie déclencheurs, si je sélectionne le walli roller shutter je n'ai pas, dans la liste des choix possibles, la partie scène bien entendu je suis sorti de l'interface scénario ou j'avais tout invalidé et je suis revenu en mode éditer pour choisir le walli roller shutter, qui auparavant avait été paramétré avec l'activation des scènes boutons 1 et 2 - valeur 11 (1 clic, 2 clic , clic long) et sauvegarde soit j'ai loupé quelque chose, soit c'est pas la bonne méthode merci de m'éclairer jean-luc

Pour répondre exactement a tes interrogations légitimes : - oui j'ai déjà mis la couleur et l'allumage sur cet anneau et tous ceux du groupe via une scène block - en mode bloc transformée en LUA, j'ai ce code qui fonctionne et qui éclaire l'anneau en vert lorsque la lumière est allumée du côté condition: { conditions = { { id = 84, isTrigger = true, operator = "==", property = "state", type = "device", value = true } }, operator = "all" } du côté action : hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","green") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","green") et ce code LUA (transformation mode block) qui fonctionne lorsque la lumière est éteinte condition: { conditions = { { id = 84, isTrigger = true, operator = "==", property = "state", type = "device", value = false } }, operator = "all" } action: hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","white") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","white")

retour test avec 1 seul ID dans le calll rappel le code généré dans le scénario en mode block puis transformé en LUA est : hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") même après exécution du scénario précédent le json du module id 452 donne "ringLightMode": "off", donc comme je suis à distance je ne peux pas contrôler si l'anneau s'est allumé ou non ? j'ai quand même fait l’exécution du code GEA GEA.add({"Property", 84, "state" , true},-1, "", {"Call", 452, "setRingsLightMode", "on"}) GEA.add({"Property", 84, "state" , false},-1, "", {"Call", 452, "setRingsLightMode", "off"}) le report console est OK [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:13:47] [DEBUG] [QA_GEA_592]: [Démarrage] #7 : ["Property",[84,"state",false]] => ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:13:47] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:14:20] [DEBUG] [QA_GEA_592]: [Démarrage] #6 : ["Property",[84,"state",true]] => ["Call",[452,"setRingsLightMode","on"]] [28.05.2023] [00:14:20] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","on"]] [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:15:00] [DEBUG] [QA_GEA_592]: [Démarrage] #7 : ["Property",[84,"state",false]] => ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:15:00] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","off"]] maintenant je verrais quand je serais sur place pour dire si l'anneau est allumé et éteint , parce comme je l'ai mentionné au dessus je ne vois rien avec le json du module 452 un autre point qui m'interpêle, comme tu l'as expliqué (@Lazer) plus avant, les actions sont listées dan le json avec derrière chaque action possible le nombre d'argument de l'action et pour setRingsLightMode il y a 0 , cela veut dire pas d'argument ? actions": { "abortUpdate": 1, "reconfigure": 0, "retryUpdate": 1, "setIndicatorValue": 1, "setRingsLightMode": 0, "startUpdate": 1, "updateFirmware": 1

oui le module 462 est un parent, pas un enfant le message d'erreur est : Erreur, vérifier : ["Parameter",[462,150,3]] j'ai mis le debug que tu m'as conseillé résultat: Ajout immédiat #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: @0s [Validation*] #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: [Démarrage] #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: [action] ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [ERROR] [QA_GEA_592]: [27.05.2023] [01:05:35] [ERROR] [QA_GEA_592]: Erreur, vérifier : ["Parameter",[462,150,3]]