Aller au contenu
Lazer

Quick App - Gestionnaire d'Événements Automatique - GEA pour HC3

Recommended Posts

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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)

Partager ce message


Lien à poster
Partager sur d’autres sites

 

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é par 971jmd

Partager ce message


Lien à poster
Partager sur d’autres sites

ç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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites
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 :D

 

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+"35310} , -1"", { changer la couleur  bouton N° 1 (haut de bouton) N°2 (bas du bouton ) ou integralement
 
 
 

 

 

 


 

 

 

 

 

Modifié par 971jmd

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

"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)

Partager ce message


Lien à poster
Partager sur d’autres sites
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"} )

 

Partager ce message


Lien à poster
Partager sur d’autres sites
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"]}})

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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 '!'

 

Partager ce message


Lien à poster
Partager sur d’autres sites
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)

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites
--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"]})

image.png.f702cf2936a301ea18f4a3dfba522db5.png

[15.05.2022] [15:38:12] [ERROR] [QUICKAPP167]: QuickApp crashed
[15.05.2022] [15:38:12] [ERROR] [QUICKAPP167]: config.lua:73: ')' expected near '!'

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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...

Partager ce message


Lien à poster
Partager sur d’autres sites

keep it simple, on supprime de la doc, et basta :60:

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui ça va finir comme ça :)

Dans la prochaine mise à jour... (pas tout de suite)

Partager ce message


Lien à poster
Partager sur d’autres sites

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"}}})

 

image.thumb.png.14882d231f8426a39d0e33869aadf8a5.png

 

Merci d'avance.

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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"}}})

image.thumb.png.51a582590e17c52edf2065a6f8ccc114.png

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 :angry:

image.thumb.png.f01fa37b35a26725b4bcb97f5400f26b.png

 

 

Par contre je ne vois pas d'élément dans les 2 cas via le debug = true

 

Modifié par Fred.domotique

Partager ce message


Lien à poster
Partager sur d’autres sites

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?

Partager ce message


Lien à poster
Partager sur d’autres sites

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()

Partager ce message


Lien à poster
Partager sur d’autres sites
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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 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
  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

×