971jmd Posté(e) le 21 avril 2022 Signaler Posté(e) le 21 avril 2022 Dans le cas de volet roulant: exemple GEA.add( {"CentralSceneEvent", id["TELECO_CH2"], 1, "Pressed1"}, -1, "" ,{{"OpenStopCloseStop", 73}}) 1 click ouvre , 1 click STOP , 1 click Fermeture
Lazer Posté(e) le 21 avril 2022 Auteur Signaler Posté(e) le 21 avril 2022 Hum, je pense que pour un scénario complexe comme celui-ci, il faut que tu fasses 3 règles distinctes. Il y a peut être déjà des exemples qui correspondent à ce que tu veux faire dans les showroom GEA. En tout cas ça ne se fera pas avec une nouvelle action comme tu le demandes, puisque ta problématique touche à la prise en compte des conditions au déclenchement (est-ce que le volet est déjà ouvert, ou en cours de mouvement)
971jmd Posté(e) le 21 avril 2022 Signaler Posté(e) le 21 avril 2022 (modifié) pour info Voilà comment je fais pour le moment ---OPEN TELECO_CHP GEA.add( { {"CentralSceneEvent", id["TELECO_CHP"], 1, "Pressed3"}, {"(Global)", "VAR_VL_F", "A"}}, -1, "" ,{{"Open", id["VL_CHP"]}, {"Global", "VAR_VL_F", "B"}}) ---STOP GEA.add( {{"CentralSceneEvent", id["TELECO_CHP"], 1, "Pressed3"}, {"(Global)", "VAR_VL_F", "B"}}, -1, "" ,{{"Stop", id["VL_CHP"]}, {"Global", "VAR_VL_F", "C"} }) ---FERMETURE GEA.add( {{"CentralSceneEvent", id["TELECO_CHP"], 1, "Pressed3"}, {"(Global)", "VAR_VL_F", "C"}}, -1, "" , {{"Close", id["VL_CHP"]}, {"Global", "VAR_VL_F", "D"} } ) ---STOP D GEA.add( {{"CentralSceneEvent", id["TELECO_CHP"], 1, "Pressed3"}, {"(Global)", "VAR_VL_F", "D"}}, -1, "" ,{{"Stop", id["VL_CHP"]}, {"Global", "VAR_VL_F", "A"} }) --RESET SI OUVERT GEA.add({"Value+", id["VL_CHP"], 95}, -1, "" , { {"Sleep", 6, {"Global", "VAR_VL_F", "C"}}}) --RESET SI FERMER GEA.add({"Value-", id["VL_CHP"], 5}, -1, "" , { {"Sleep", 6, {"Global", "VAR_VL_F", "A"}}}) Modifié le 21 avril 2022 par 971jmd
Lazer Posté(e) le 21 avril 2022 Auteur Signaler Posté(e) le 21 avril 2022 ça me parait pas mal, même si je pense qu'il serait plus judicieux de remplacer les variables "Global" par des "VariableCache" ça évite des écritures inutiles en DB, et donc c'est plus performant.
971jmd Posté(e) le 23 avril 2022 Signaler Posté(e) le 23 avril 2022 ok merci, je vais essayer mais j'avoue que ça reste quand même assez complexe à mettre en place quand on a une dizaine de VL
971jmd Posté(e) le 24 avril 2022 Signaler Posté(e) le 24 avril 2022 (modifié) Le 19/11/2020 à 14:44, Lazer a dit : OK, dans ce cas on va conserver le comportement actuel qui utilise le pont Hue. Pour les childs, on va ajouter des nouvelles options. La luminosité devrait déjà pouvoir se régler de façon traditionnelle comme pour tout dimmer avec "Value" et la valeur en numérique, je pense que ça doit fonctionner : GEA.add( {CONDITIONS}, 30, "", {"Value", 21, 50} ) Dans le JSON de ton child, je vois qu'il y a une méthode "setColor" avec 1 seul paramètre, mais je n'ai aucune idée de la valeur qu'il faut donner à se paramètre. Tu pourrais faire des tests directement en LUA avec fibaro.call(...) pour comprendre le fonctionnement ? Il semble que la valeur soit stockée dans le champ properties.color. Si ça se trouve, le paramètre à passer est littéralement la chaine "255,255,255,0" qui semble indique du blanc (les 3 composantes RGB à 255), mais que signifie le dernier paramètre à 0 ? EDIT : laisse tomber, j'ai compris, c'est la même API que pour les modules RGBW. Donc tu peux utiliser directement sur un child Hue : GEA.add( {CONDITIONS}, 30, "", {"RGB", 21, 100, 0, 100, 100} ) Elle est géniale cette HC3, l'intégration native des modules externes, comme pour les modules Z-Wave, ça simplifie tout Du coup je pense que je vais ajouter un alias pour "RGB" qui sera "Color", tout simplement, et ça sera plus parlant, et l'usage de l'un ou l'autre sera au choix de l'utilisateur Je suis preneur d'autres suggestions bien sûr salut j'ai une question concernant le changement de couleur d'un WALLI Est-ce qu'il est possible à partir de juin de changer la couleur du bouton d'un Walli ? j'ai tester setRingOnColor ou setRingOffColor est cà fonctionne bien. Mais voilà mon problème c'est que je cherche à changer la couleur selon une condition exemple: GEA.add({"Power+", 353, 10} , -1, "", { changer la couleur bouton N° 1 (haut de bouton) N°2 (bas du bouton ) ou integralement Modifié le 24 avril 2022 par 971jmd
jojo Posté(e) le 13 mai 2022 Signaler Posté(e) le 13 mai 2022 hello, (mon premier post de suggestion GEA) l'action {"Inverse"} inverse la première condition, idem pour {"Inverse", 2}, la seconde ... Ne pourrait-on pas envisager l'action {"Inveres"} pour inverser TOUTES les conditions ?
jojo Posté(e) le 13 mai 2022 Signaler Posté(e) le 13 mai 2022 bug ? L'instruction GEA.add (id["CHAUF_SDBRDC_RADIATEUR"], -1, "", {{"Inverse"}, {"TurnOff", id["CHAUF_CIRCUL_RDC"]}}) fonctionne parfaitement. Mais l'instruction GEA.add (id["CHAUF_SDBRDC_RADIATEUR"]!, -1, "", {"TurnOff", id["CHAUF_CIRCUL_RDC"]}) refuse d'activer GEA (=Running Yes) lorsque je sauve
Lazer Posté(e) le 13 mai 2022 Auteur Signaler Posté(e) le 13 mai 2022 "Inverses", oui pourquoi pas, mais il faudrait que j'étudie la faisabilité (la complexité de mise en œuvre...), je n'en ai aucune idée. Mais en as tu réellement besoin ? Attention à la logique inverse, à vouloir tout négationner, ne vas tu pas rendre ta configuration illisible et difficile à maintenir ? Pour la seconde, tu as une erreur de syntaxe, il y a un point d'exclamation collé derrière le crochet fermant de l'ID de ta condition. Dans le log tu dois probablement avoir une erreur LUA, ou bien GEA qui te le signale par un message (pas forcément très clair, je n'ai jamais vu cette erreur)
jojo Posté(e) le 14 mai 2022 Signaler Posté(e) le 14 mai 2022 Il y a 17 heures, Lazer a dit : Attention à la logique inverse, à vouloir tout négationner, ne vas tu pas rendre ta configuration illisible et difficile à maintenir ? je t'voue ne pas avoir bien lu la doc dans un premier temps et avoir mis {"Inverse"} en étant persuadé que cela s'appliquait à toutes les conditions. S'il ne fallait pas garantir la rétrocompatibilité, j'aurais {"Inverse"} pour tous, et {"Inverse", 1} pour le premier ... Perso, je trouve cela plus facile à maintenir : plutôt qu'enchainer les {"TurnOff", ...}, je mes juste l'ID et inverse dans les actions. Maintenant s'il fallait rajouter un TurnOff dans les conditions, juste rajouter son ID, et il ne faut plus s'occuper de rien. Au niveau de la logique de programmation, {"Inverses"} n'est "que" une boucle sur {"Inverse"} (d'ailleurs cela ne fait pas le même chose/la même fonction que {'Inverse", 1} .), ("Inverse", 2}, ... Il y a 18 heures, Lazer a dit : Pour la seconde, tu as une erreur de syntaxe, il y a un point d'exclamation collé derrière le crochet fermant de l'ID de ta condition. mais justement, je voulais faire l'{"Inverse"} de cette condition. Je devrais alors écrire GEA.add ({id["CHAUF_SDBRDC_RADIATEUR"]}!, -1, "", {"TurnOff", id["CHAUF_CIRCUL_RDC"]}) mais la doc dit ceci -- ALIAS : GEA.add(101!, 30, "", {ACTIONS} ) équivaut à GEA.add(101, 30, "", {"Inverse"} )
jojo Posté(e) le 14 mai 2022 Signaler Posté(e) le 14 mai 2022 Il y a 18 heures, Lazer a dit : Mais en as tu réellement besoin ? voici mon code GEA.add ({id["CHAUF_CIRCUL_RDC"], id["CHAUF_CIRCUL_ETAGE"], id["CHAUF_ECS_RADIATEUR"]}, -1, "", {{"Inverse"}, {"Inverse", 2}, {"Inverse", 3}, {"TurnOff", id["CHAUF_CHAUDIERE"]}})
Lazer Posté(e) le 14 mai 2022 Auteur Signaler Posté(e) le 14 mai 2022 Effectivement dans ce cas particulier, un "Inverses" serait bien utile. Je regarderai à l'occasion, mais sans garantie, la gestion du "Inverse" est quelque chose à laquelle je ne n'ai pas du tout touché dans GEA, je n'ai aucune idée de la façon dont Steven l'a implémenté.... et le code de GEA est ultra complexe. Certaines modifications sont très simples à faire, tandis que c'est l'enfer pour d'autres. Je ne connaissais pas du tout la syntaxe avec le point d'exclamation derrière l'ID ! Mais je ne vois pas comment ça pourrait fonctionner, c'est syntaxiquement incorrect en LUA, on ne peut pas coller un tel caractère derrière un nombre. Exemple simple et rapide : > print(101) 101 > print(101!) stdin:1: ')' expected near '!'
jojo Posté(e) le 14 mai 2022 Signaler Posté(e) le 14 mai 2022 Il y a 3 heures, Lazer a dit : Je regarderai à l'occasion, mais sans garantie, la gestion du "Inverse" est quelque chose à laquelle je ne n'ai pas du tout touché dans GEA, je n'ai aucune idée de la façon dont Steven l'a implémenté.... et le code de GEA est ultra complexe. Certaines modifications sont très simples à faire, tandis que c'est l'enfer pour d'autres. no stress, c'est tout sauf essentiel. Il y a 3 heures, Lazer a dit : Je ne connaissais pas du tout la syntaxe avec le point d'exclamation derrière l'ID ! Mais je ne vois pas comment ça pourrait fonctionner, c'est syntaxiquement incorrect en LUA, on ne peut pas coller un tel caractère derrière un nombre. à supprimer de la doc alors (lignes 1860 & 1861)
Lazer Posté(e) le 14 mai 2022 Auteur Signaler Posté(e) le 14 mai 2022 Yes.... En attendant, tu pourrais me donner le log que tu avais quand tu as tenté avec ce fameux point d'exclamation derrière l'ID. Si ça a été documenté, c'est que ça a fonctionné à un moment donné, ce que je trouve étrange, il doit y avoir une explication.
jojo Posté(e) le 15 mai 2022 Signaler Posté(e) le 15 mai 2022 --GEA.add (id["CHAUF_SDBRDC_RADIATEUR"], -1, "", {{"Inverse"}, {"TurnOff", id["CHAUF_CIRCUL_RDC"]}}) GEA.add (id["CHAUF_SDBRDC_RADIATEUR"]!, -1, "", {"TurnOff", id["CHAUF_CIRCUL_RDC"]}) [15.05.2022] [15:38:12] [ERROR] [QUICKAPP167]: QuickApp crashed [15.05.2022] [15:38:12] [ERROR] [QUICKAPP167]: config.lua:73: ')' expected near '!'
Lazer Posté(e) le 15 mai 2022 Auteur Signaler Posté(e) le 15 mai 2022 OK merci, donc maintenant c'est clair, tu as la même erreur que moi lors de mon test quelques messages plus haut. C'est LUA qui refuse d'exécuter le code, le point d'exclamation n'est pas accepté. C'est donc normal. Mais cela n'explique pas pourquoi ça a été documenté ainsi dans GEA, comme si ça avait pu fonctionner sur HC2...
jojo Posté(e) le 15 mai 2022 Signaler Posté(e) le 15 mai 2022 keep it simple, on supprime de la doc, et basta
Lazer Posté(e) le 15 mai 2022 Auteur Signaler Posté(e) le 15 mai 2022 Oui ça va finir comme ça Dans la prochaine mise à jour... (pas tout de suite)
Fred.domotique Posté(e) le 26 mai 2022 Signaler Posté(e) le 26 mai 2022 Bonjour, Je sollicite votre aide sur le code ci dessous, je ne comprend pas pourquoi cela ne fonctionne pas sur GEA suite à la migration sur HC3. Enfaite la variable passe bien à 1 mais la partie après le sleep s'execute dans le debug mais la variable ne bouge pas elle reste à 1 ?? GEA.add({id["PORTE_SALON"]}, -1, "", {{"Global","EtatPorteTerrasse", "1"},{"Sleep", 10, {"Global","EtatPorteTerrasse", "2"}}}) Merci d'avance.
Lazer Posté(e) le 26 mai 2022 Auteur Signaler Posté(e) le 26 mai 2022 La syntaxe semble correcte. Tu peux activer le mode GEA.lldebug = true et relancer, et surtout regarder les logs que tu as pour cette ligne, puis 10 secondes plus tard.
Fred.domotique Posté(e) le 27 mai 2022 Signaler Posté(e) le 27 mai 2022 (modifié) Lazer, après plusieurs test, j'ai créer un instance GEA Test pour vérification. Lorsque la ligne est seul dans l'instance elle fonctionne, du coup j'ai essayé plusieurs choses et je me rend compte que ce qui créer le disfonctionnement est l'ajout d'un déclenchement immédiat positionné après le code .?? 1er exemple ligne seul --GESTION DES OUVRANTS GEA.add({id["PORTE_SALON"]}, -1, "", {{"Inverse"},{"Global","EtatPorteTerrasse", "0"}}) GEA.add({id["PORTE_SALON"]}, -1, "", {{"Global","EtatPorteTerrasse", "1"},{"Sleep",7,{"Global","EtatPorteTerrasse", "2"}}}) La variable passe à 1 puis à 2 2ème exemple je rajoute un déclenchement -1 --GESTION DES OUVRANTS GEA.add({id["PORTE_SALON"]}, -1, "", {{"Inverse"},{"Global","EtatPorteTerrasse", "0"}}) GEA.add({id["PORTE_SALON"]}, -1, "", {{"Global","EtatPorteTerrasse", "1"},{"Sleep",7,{"Global","EtatPorteTerrasse", "2"}}}) --ECLAIRAGE-- -- Allumage sur ouverture des portes uniquement la nuit GEA.add({id["PORTE_SALON"],nuit,present}, -1, "", {{"turnOn",id ["APPLIQUE_TERRASSE"]}}) Et là, rien la variable bloque sur 1 Par contre je ne vois pas d'élément dans les 2 cas via le debug = true Modifié le 27 mai 2022 par Fred.domotique
Fred.domotique Posté(e) le 27 mai 2022 Signaler Posté(e) le 27 mai 2022 Lorsque je reprend mon code global. Si je positionne ma ligne en début de code => Nok la variable reste à 1 Si je positionne ma ligne en fin de code => Ok la variable passe à 1 puis à 2 ?? il faut que je regarde si le reste est impacté mais je ne comprend pas pourquoi?
Lazer Posté(e) le 27 mai 2022 Auteur Signaler Posté(e) le 27 mai 2022 cette histoire d'ordre des règles ressemble à un effet de bord dans la logique de gestion des statut des devices, mais je n'arrive pas à comprendre. Quelques remarques cependant : - je vois dans ton log que GEA est suspendu, c'est normal ça ? Parce que s'il est suspendu, il ne va pas gérer les règles correctement. - tu as mal dû positionner le GEA.lldebug = true, car il doit être dans la fonction config()
jojo Posté(e) le 27 mai 2022 Signaler Posté(e) le 27 mai 2022 Il y a 2 heures, Lazer a dit : GEA.lldebug = true c'est quoi la diffférence avec GEA.debug = true qui se trouve également dans config ?
Lazer Posté(e) le 27 mai 2022 Auteur Signaler Posté(e) le 27 mai 2022 debug => affichage de messages basiques, pour aider l'utilisateur à comprendre le fonctionnement (ou non) de ses propres règles lldebug (pour Low-Level) => affichage de messages supplémentaires pour aider les développeurs (= moi et quiconque voudrait bien se joindre à l'aventure) à comprendre les bugs dans GEA 1
Messages recommandés