Aller au contenu

Recommended Posts

J'adore @jojo et je passe la tête par la fenêtre :lol: j'en peut plus. 

Partager ce message


Lien à poster
Partager sur d’autres sites

en réponse à 

 

"ChECSEco" est en effet le nom ve la variable.

Cfr doc GEA :

-- "VariableQuickApp" - "VariableQA" : Teste/modifie une variable d'un QuickApp

	-- SYNTAXE :
	{"VariableQuickApp!", <id_module>, <"nom_variable">, <"valeur">}

	-- CONDITIONS :
	GEA.add( {"VariableQuickApp!", 73, "MaVariable", ""}, 0, "Variable QuickApp #name# = #value#", {ACTIONS} )      -- Vérifie si la variable MaVariable du QuickApp 73 est différente d'une chaine vide
	GEA.add( {"VariableQuickApp+", 73, "MaVariable", 29}, 0, "Variable QuickApp #name# = #value# > 29", {ACTIONS} ) -- Vérifie si la variable MaVariable du QuickApp 73 est supérieure à 29

	-- ACTIONS :
	GEA.add( {CONDITIONS}, 30, "", {"VariableQuickApp", 73, "MaVariable", "Ma Valeur"} )                            -- Affecte la valeur "Ma Valeur" à la variable MaVariable du QuickApp 73

 

  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

@jojo top ! Jojo

je ne comprenais pas la syntaxe c'est plus clair

le declencheur -1 ne fonctionne plus ?

 

function setEvents()
	-- ==========================================================
	-- Règles utilisateur
	-- ==========================================================

	local id = {
 QA_PLUIE_1H = 182
	}
    -- TRIGGER sur variable local "pluie_ds_lheure" oui/non

GEA.add({"VariableQuickApp",id["QA_PLUIE_1H"], "pluie_ds_lheure", "oui"}, -1, "Variable QuickApp #name# = #value#") 
GEA.add({"VariableQuickApp",id["QA_PLUIE_1H"], "pluie_ds_lheure", "non"}, -1, "Variable QuickApp #name# = #value#") 
end

 

Modifié par flamalex

Partager ce message


Lien à poster
Partager sur d’autres sites

non, c'est encore plus simple sur HC3 :

Il ne faut plus définir en début les triggers comme avant sur HC2 (c'est expliqué pat @Lazer dans l'autre topic)

=> oui, les -1 fonctionnent toujours (heureusement !)

Partager ce message


Lien à poster
Partager sur d’autres sites

Attention, "VariableQuickApp" n'est pas utilisable en Trigger, toujours bien penser à RTFM :D (la doc de syntaxe)

Partager ce message


Lien à poster
Partager sur d’autres sites

Ah pas de bol

alors comment faire?

je pousse, via une requête http exterieur, le changement de variable du QA et souhaite, sur changement de celle ci, modifier l’état d’un label. (Instantanément)

comment faire si ce n’est plus possible?

avec une VG ?

 

GEA.add({"VariableQuickApp",id["QA_PLUIE_1H"], "pluie_ds_lheure", "oui"},-1, "Variable QuickApp #name# = #value# ",{"QuickApp", id["QA_PLUIE_1H"],"affichage_pluie"}) 
GEA.add({"VariableQuickApp",id["QA_PLUIE_1H"], "pluie_ds_lheure", "non"},-1, "Variable QuickApp #name# = #value# ",{"QuickApp", id["QA_PLUIE_1H"],"affichage_pluie"}) 

 

Modifié par flamalex

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, Lazer a dit :

Attention, "VariableQuickApp" n'est pas utilisable en Trigger, toujours bien penser à RTFM :D (la doc de syntaxe)

j'ai des cou.... à la place des yeux, car je ne vois rien dans la doc ?

-- "VariableQuickApp" - "VariableQA" : Teste/modifie une variable d'un QuickApp

	-- SYNTAXE :
	{"VariableQuickApp!", <id_module>, <"nom_variable">, <"valeur">}

	-- CONDITIONS :
	GEA.add( {"VariableQuickApp!", 73, "MaVariable", ""}, 0, "Variable QuickApp #name# = #value#", {ACTIONS} )      -- Vérifie si la variable MaVariable du QuickApp 73 est différente d'une chaine vide
	GEA.add( {"VariableQuickApp+", 73, "MaVariable", 29}, 0, "Variable QuickApp #name# = #value# > 29", {ACTIONS} ) -- Vérifie si la variable MaVariable du QuickApp 73 est supérieure à 29

	-- ACTIONS :
	GEA.add( {CONDITIONS}, 30, "", {"VariableQuickApp", 73, "MaVariable", "Ma Valeur"} )                            -- Affecte la valeur "Ma Valeur" à la variable MaVariable du QuickApp 73

 

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est dans le tableau récapitulatif, colonne Trigger :

-- ┌────────────────────────────────────────────────────┬───────────┬─────────┬────────┐
-- │ Option                                             │ Condition │ Trigger │ Action │
-- ├────────────────────────────────────────────────────┼───────────┼─────────┼────────┤
-- │ "Global"                                           │     X     │    X    │   X    │ Teste/modifie une variable globale
-- │ "CopyGlobal"                                       │           │         │   X    │ Copie la valeur d'une variable globale dans une autre
-- │ "CheckVG"                                          │     X     │         │        │ Teste l'existence d'une variable globale
-- │ "VariableCache"                                    │     X     │         │   X    │ Teste/modifie une variable en cache
-- │ "VariableQuickApp" "VariableQA"                    │     X     │         │   X    │ Teste/modifie une variable d'un QuickApp
-- ├────────────────────────────────────────────────────┼───────────┼─────────┼────────┤

Un tableau que j'ai créé spécifiquement lors du portage de GEA sur HC3, car j'avais toujours un doute sur quelle option était "triggable" ou non (et si on pouvait l'utiliser en condition ou en action). Maintenant l'information est tout de suite visuelle.

 

  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

ah, ok, merci j'avais zappé ces colonnes du tableau.

En fait je n'utilisais que la première colonne pour voir le nom des options et j'allais directement dans le détail plus bas.                                            

 

Cool, on en apprend tous les jours sur GEA !

Partager ce message


Lien à poster
Partager sur d’autres sites

Il y a une raison particulière (technique (dev))

sur le fait de ne pouvoir trigger une variable QA?

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui, je n'ai pas trouvé de message relatif à la modification de la variable QA dans l'API RefreshStates.

 

Il faudrait jeter un nouveau coup d'oeil maintenant que plusieurs firmwares sont passés, peut être que des modifications ont été apportées, mais je manque de temps, d'autant plus que tout cela est assez loin pour moi maintenant.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

 

Je rencontre une difficulté à la mise en oeuvre d'une condition qui me parait totalement prévue et supportée par GEA. Je dois rater quelque chose. Je sollicite votre aide.

 

Je souhaite ouvrir mes volets, le matin, lorsque les 2 conditions suivantes ont remplies :

  • il est l'heure
  • le soleil se lève (NB : ma traduction de "soleil levant", en GEA, est : Sunrise - 15)

Par exemple, un jour de semaine, l'heure qui me va est 7h. Eh bien, je souhaite que :

  • l'été, les volets s'ouvrent à 7h seulement - bien qu'il fasse jour depuis 6h30 par exemple (pour ne pas être réveillé en avance),
  • l'hiver, les volets s'ouvrent au lever du soleil, vers 7h30 par exemple - pour préserver l'intimité (volets ouverts, lumière allumée, mes voisins voient super chez moi)

le tout sans qu'une relance de GEA ou de la box, en journée, n'ouvre ou ne ferme les volets* (GEA est en autostart),

et sans changer la condition entre les saisons, bien sûr :P

 

* j'ai une règle similaire, pour fermer les volets le soir : dès qu'il fait nuit (l'hiver) ou à 21h

 

Il y a quelques mois (c'était quand je testais GEA sur ma HC3, et avait encore toute ma domotique sur la HC2), j'avais testé avec succès (pour autant que je me souvienne), la condition suivante :

{"Time", "07:00", "Sunrise - 15 > 07:00"}

mais actuellement, elle m'ouvre les volets à 7h00 :(

 

J'avais un peu galéré à aboutir à cette condition, et étais noté :

-- NB : ne semblent pas fonctionner ou produire le résultat attendu
--  les syntaxes sans heures de début et de fin - ex : {"Time", "Sunrise - 15 > 07:00"}
--  les créneaux horaires sans test sur l'heure de levé/couché du soleil - ex : {"Time", "Sunrise - 15", "07:00"}

 

Qu'est-ce que je rate ?

 

Modifié par Bebitoo

Partager ce message


Lien à poster
Partager sur d’autres sites

tu es un lève tôt ...

 

d'après la doc (car je n'utilise pas ce genre de conditions)

-- "Time" : Teste l'heure courante

	-- SYNTAXE :
	{"Time", <from>, <to>}

	-- CONDITIONS :
	GEA.add( {"Time", "Sunrise>07:30", "Sunset<21:00"}             , 30, "", {ACTIONS} ) -- Si tranche horaire : AU lever du soleil SI après 7h30, sinon à 7h30; Au coucher du soleil SI AVANT 21h SINON à 21h \\ Check if Sunrise is after 7:30 otherwise 7:30 ; check if Sunset is before 21:00 otherwise 21:00

j'essayerais ceci :

GEA.add ({"Time", "Sunrise>07:00", "10:00"}, 0, "", {ACTIONS} )

Quand ok pour ce qui précède, on regardera pour

il y a 38 minutes, Bebitoo a dit :

le tout sans qu'une relance de GEA ou de la box, en journée, n'ouvre ou ne ferme les volets* (GEA est en autostart),

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour

 

J'utilise ce genre de conditions chez moi il faut utiliser ce genre de chose :

{"Time", "Sunrise>7:30","Sunrise+15>7:45"},

pour une ouverture entre le lever du soleil mais entre 7h30 et 7h45. J'utilise aussi la condition DST NODST pour faire la distinction entre l'heure d'été et l'heure d'hiver. ça oblige à faire 2 règles mais ça marche très bien chez moi depuis plus de 3 ans sur ma HC2.

 

Attention je pense que le espaces entre les options posent ton problème, il faut mettre :

Citation

Sunrise-15>07:00

 

et non :

Citation

Sunrise - 15 > 07:00

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonsoir,

Le 20/11/2022 à 18:50, jojo a dit :

d'après la doc {"Time", <from>, <to>}

Oui, mais comment comprendre ce test dans l'heure de début et/ou de fin ?

 

Le 20/11/2022 à 18:50, jojo a dit :

j'essayerais ceci :  

{"Time", "Sunrise>07:00", "10:00"}

Je comprends qu'ainsi j'obtiendrais une ouverture des volets si je relance GEA entre 7:00 et 10:00, ou entre Sunrise et 10:00, mais comme tu le proposes dojo, je verrais cette partit plus tard. J'essaie.

 

Il y a 10 heures, nasp a dit :

{"Time", "Sunrise>7:30","Sunrise+15>7:45"}

J'essaie aussi :)

 

NB : d'après mes précédents tests, les espaces n'influent pas. J'ai d'ailleurs les règles suivantes, qui fonctionnent très bien :

  -- gestion de la variable globale Soleil
  GEA.add({"Time", "Sunrise - 15", "Sunrise"     }, 0, "", {"Global", "Soleil", "levant"  }, "Soleil : [levant] levé  couchant  couché ")
  GEA.add({"Time", "Sunrise"     , "Sunset"      }, 0, "", {"Global", "Soleil", "levé"    }, "Soleil :  levant [levé] couchant  couché ")
  GEA.add({"Time", "Sunset"      , "Sunset  + 15"}, 0, "", {"Global", "Soleil", "couchant"}, "Soleil :  levant  levé [couchant] couché ")
  GEA.add({"Time", "Sunset  + 15", "Sunrise - 15"}, 0, "", {"Global", "Soleil", "couché"  }, "Soleil :  levant  levé  couchant [couché]")

Mais j'essaie sans espaces désormais.

 

Résultats des tests demain matin :)

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 22 heures, Bebitoo a dit :

Je comprends qu'ainsi j'obtiendrais une ouverture des volets si je relance GEA entre 7:00 et 10:00, ou entre Sunrise et 10:00, mais comme tu le proposes dojo, je verrais cette partit plus tard.

si période de temps entre ... et "10:00" (qqch qui est après ...

pour ... (d'après la doc)

AU lever du soleil SI après 7h00, sinon à 7h00

 

Partager ce message


Lien à poster
Partager sur d’autres sites

je pose une question (que je trouve stupide)/

d'après la doc

-- <ID Module> : Teste l'état d'un module

	-- SYNTAXE :
	73
	id["Module"]

	-- CONDITIONS :
	GEA.add( id["TV"]    , 30, "", {ACTIONS} ) -- Si la TV est allumée depuis 30 secondes \\ If TV is ON since 30 seconds
	GEA.add( {72, 73, 74}, 30, "", {ACTIONS} ) -- Si les modules 72, 73 et 74 sont ON depuis 30 secondes \\ If devices 72, 73, 74 are ON since 30 seconds

cela devrait fonctionner aussi bien pour 

  • les modules ON/OFF (FGSxxx, WP, ...) que
  • pour les e,trées IN1 et IN2 des FGBS et autres.

Mon interprétation est-elle correcte ?

Car pour les FGS, .... cela fonctionne parfaitement quelle que soit le paramètre temps introduit (-1, 0, x*60) :60:

Mais pour les IN1/2 des FGBS (par exemple) seul le -1 fonctionne systématiquement.

Pour ces mêmes modules, cette règle fonctionne parfaitement :

GEA.add ({"Value",id["GA_OUVERT"], "True"}, 0, "", {"OnOff", id["BUREAU_PRISE"]})

alors que celle-ci (qui selon mon interprétation est identique) ne fonctionne pas (= n'est jamais déclenchée)

GEA.add (id["GA_OUVERT"], 0, "", {"OnOff", id["BUREAU_PRISE"]})

Bug ou mauvaise interprétation de ma part ?

Partager ce message


Lien à poster
Partager sur d’autres sites

La syntaxe abrégée devrait tout le temps fonctionner, y compris pour les FGBS si ceux-ci renvoie la value true.

 

Mais il y a un truc bizarre dans ta règle, tu testes la valeur "true" et non true (soit string versus boolean), c'est normal ?

Partager ce message


Lien à poster
Partager sur d’autres sites

justement, je m'était posé la même question : avec ou sans string ?

Et comme avec le string ça faisait le job, je l'ai laissé.

Et le plus étrange c'est que çà ait fonctionné avec "True", alors que le json dit true.

J'ai retiré le string, et ça marche également ! (et après on se demande pourquoi je suis un inconditionnel de GEA ...)

 

Ceci dit, je confirme, après de multiples tests,que la syntaxe abrégée ne fonctionne qu'avec -1 (et pour rendre ceci plus complexe, il y a des GHBS pour qui 2*60 fonctionne tout le temps, d'autres pour qui 0 fonctionne parfois, et d'autres pour qui 0 n'a jamais fonctionné = c'est le mystère du bit à moitié fermé ?)

 

Modifié par jojo

Partager ce message


Lien à poster
Partager sur d’autres sites

Normalement il faut comparer la value à l'identique de ce que contient la propriété value visible dans l'API JSON du module.

Donc sur HC3 (car ce n'était pas le cas sur HC2), pour un capteur binaire, c'est toujours un booléen, donc true/false.

Pas de string donc.

 

Sinon pour ton test, je ne sais pas... peut être un bug dans GEA... il faudrait reproduire, analyser les logs détaillés, etc... désolé mais pas trop le temps/courage de m'y remettre.
Si ça fonctionne avec l'écriture complète, fait comme ça.

Partager ce message


Lien à poster
Partager sur d’autres sites

ok, je vais tous les traduire avec l'écriture complète, histoire d'être consistant.

Je comprends parfaitement ton point de vue (je fais le même chose), si ce n'est pas bloquant ...

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

 

Le 21/11/2022 à 13:40, nasp a dit :

{"Time", "Sunrise>7:30","Sunrise+15>7:45"}

Le 22/11/2022 à 22:44, jojo a dit :

d'après la doc


AU lever du soleil SI après 7h00, sinon à 7h00

 

J'avais raté cette portion de la doc :wacko:

Si ça peut en aider d'autres, la voici (en v7.36) :

-- "Time" : Teste l'heure courante

	-- SYNTAXE :
	{"Time", <from>, <to>}

	-- CONDITIONS :
	GEA.add( {"Time", "22:00", "23:00"}                            , 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes dans la tranches horaires \\ Check only if in schedule
	GEA.add( {"Time", "07:00", "08:00"}, {"Time", "22:00", "23:00"}, 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes dans LES tranches horaires \\ Check only if in THE schedule
	GEA.add( {"Time", "Sunrise+30", "Sunset-15"}                   , 30, "", {ACTIONS} ) -- Si tranche horaire : lever du soleil + 30 mins, coucher du soleil - 15 minutes \\ Check only if Sunrise more than 30 mins and sunset less 15 mins
	GEA.add( {"Time", "Sunrise>07:30", "Sunset<21:00"}             , 30, "", {ACTIONS} ) -- Si tranche horaire : AU lever du soleil SI après 7h30, sinon à 7h30; Au coucher du soleil SI AVANT 21h SINON à 21h \\ Check if Sunrise is after 7:30 otherwise 7:30 ; check if Sunset is before 21:00 otherwise 21:00
	GEA.add( {"Time", "Sunrise-10>07:30", "Sunset+10<21:00"}       , 30, "", {ACTIONS} ) -- Si tranche horaire : AU lever du soleil moins 10 minutes SI après 7h30, sinon à 7h30; Au coucher du soleil plus 10 minutes SI AVANT 21h SINON à 21h \\ Check if Sunrise less 10 minutes is after 7:30 otherwise 7:30 ; check if Sunset more 10 minutes is before 21:00 otherwise 21:00
	GEA.add( {"Time", "22:00"}                                     , 30, "", {ACTIONS} ) -- Équivaut à {"Time", "22:00", "22:00"} \\ Idem to {"Time", "22:00", "22:00"}

	-- ACTIONS : Ne peut pas être utilisé comme ACTION

 

Et j'ai bien aimé la proposition de nasp, en exprimant l'horaire de fin également avec Sunrise, et un test. Du coup, j'ai ça :

{"Time", "Sunrise - 15 > 07:00", "Sunrise > 07:15"}

et cela fonctionne bien depuis quelques jours, avec actuellement (en hiver) une ouverture des volets vers 7:45. A confirmer (mais y'a pas de raisons) que cela continuera de fonctionner cet été, avec une ouverture à 7:00 seulement, bien que le le soleil se lève bien avant .

Et il n'y a que sur les 15 minutes suivant l'ouverture des volets qu'un redémarrage de la box ou de GEA provoquerait une (nouvelle) ouverture des volets : ça va (et rien ne m'empêche de réduire cette durée).

Merci pour ces aides collectives :)

 

 

Modifié par Bebitoo

Partager ce message


Lien à poster
Partager sur d’autres sites

Je galère aussi pour jouer avec Hiver/été et les heures.

Je ne comprends rien, les jours bougent toujours en hiver/été mais comme je galère !!

Partager ce message


Lien à poster
Partager sur d’autres sites

c'est vrai que GEA offre trop de possibilités :98:

Partager ce message


Lien à poster
Partager sur d’autres sites

Suis certain que @jojo tu n'as pas testé ça dans le doc de syntaxes ! :P

ça retourne 1

	-- #sunrise# - #sunset# : {Sunrise} / {Sunset}
	GEA.add(true, 0, "Le levé du soleil est prévu à {Sunrise} et le couché à {Sunset}")

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×