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

[Dragoniacs]

Bonjour !

 

Petite question en relisant la DOC de GEA. Cette consigne :

GEA.add({"Climate-", "Salon", "Heat", 19}, 30, "#value# il fait frais dans #name#", {ACTIONS}) -- Vérifie si la température de consigne de la zone du Salon est inférieure à 19 degrés

 

Est-ce qu'il faut comprendre "inférieur ou égal" ou "strictement inférieur" ?

 

[Lazer]

C'est strictement supérieur ou inférieur.

Extrait :

											if type(num1) == "number" and type(num2) == "number" then
												if plus then
													checked = num2 > num1
												else
													checked = num2 < num1
												end
											else
												checked = false
											end

 

[Dragoniacs]

Ok merci
Du coup, est-ce que la commande "climate!" existe ?

Envoyé de mon M2012K11AG en utilisant Tapatalk

[Lazer]

A priori oui ça devrait fonctionner, j'ai retrouvé une syntaxe que j'avais testé :

GEA.add({"Climate!", "Default Room", "Mode", "xxx"}, 0, "", {{"Test", "Zone #name# mode : #value#"}})

Règle toujours valide dans cet exemple vu que le Mode ne peut jamais avoir la valeur "xxx".

[Dragoniacs]

Ok, je teste ça, merci encore

Envoyé de mon M2012K11AG en utilisant Tapatalk

[jojo]

Salut,

Je me demande s'il n'y a pas un petit bug avec l'instruction "Deads".

Voici ma règle

GEA.add ({"Deads"}, 0, "",
         {{"QuickApp", id["DEADS"], "Deads"},
          {"Email", "admin", "Réveil des noeuds morts via QA\nle #date# à #time#.", 
                             "Réveil des noeuds morts via QA"}})

or j'ai un nœud mort, confirmé par le json

object		{19}
id	:	1140
name	:	Chauf_SdBRdC_Vanne
roomID	:	224
view		[2]
type	:	com.fibaro.hvacSystem
baseType	:	com.fibaro.device
...
properties		{62}
...		
configured	:		true
dead	:		true
deadReason	:	unknown
...

et je ne reçois pas le mail...

[Lazer]

La condition "Deads" recherche les modules correspondant à l'aide de la requête suivant sur l'API :

/devices?property=[dead,true]&enabled=true&interface=zwave&parentId=1

Peux-tu la tester sur ta box, et confirmer que le module n'est pas listé ?

 

Tu constates qu'il y a 3 conditions, il faut que le module soit "enabled", qu'il dispose de l'interface Z-Wave, et qu'il soit Parent.

 

L'extrait de ton JSON ne montre pas ces 3 paramètres, tu peux vérifier cela ? Car ça pourrait être une explication de sa non prise en compte.

[jojo]

1) Merci de te pencher sur le problème.

Le module qui était mort hier

• avait une interface z-wave
• n'était pas parent, mais je suppose que son parent était mort également
• était enable

mais maintenant, il s'est réveillé tout seul ...

 

Mais j'ai d'autres modules morts, donc j'ai pu tester ta requête:

http://192.168.x.y/api/devices?property=[dead,true]&enabled=true&interface=zwave&parentId=1

dont voici le json :

array		[5]
	0		{19}
	1		{19}
	2		{19}
	3		{19}
	4		{19}
id	:	701
name	:	FGS223_Circulateurs
roomID	:	239
view		[0]
type	:	com.fibaro.zwaveDevice
baseType	:	com.fibaro.device
enabled	:		true
visible	:		false
isPlugin	:		false
parentId	:	1
viewXml	:		false
hasUIView	:		false
configXml	:		false
interfaces		[6]
	0	:	polling
	1	:	zwave	
	2	:	zwaveAssociation
	3	:	zwaveConfiguration
	4	:	zwaveMultiChannelAssociation
	5	:	zwaveSlaveRouting
properties		{42}
	categories		[1]
	configured	:		true
    dead	:		true
    deadReason	:	power
    deviceControlType	:	1
    deviceIcon	:	28
    deviceRole	:	Other
    deviceSpecificData	:	h'0000000000000c16
    deviceSpecificIdType	:	Serial Number
    deviceState	:	Configured
    endPointId	:	0
    icon		{0}
    lastWorkingRoute		[0]
    lastWorkingRouteRequestStatus	:	ok
    lastWorkingRouteRequestTimestamp	:	0
	lastWorkingRouteResponseTimestamp	:	1712044837
    log	:	
    logTemp	:	
    manufacturer	:	
    markAsDead	:		true
    model	:	
    neighborList		[4]
    neighborListRequestStatus	:	ok
    neighborListRequestTimestamp	:	0
    neighborListResponseTimestamp	:	1712044837
    nodeId	:	89
    parameters		[36]
    parametersTemplate	:	781
    pollingInterval	:	-1
    pollingTimeSec	:	0
    productInfo	:	1,15,2,3,16,0,3,4
    saveLogs	:		true
    securityLevel	:	
    securitySchemes		[0]
    serialNumber	:	h'0000000000000c16
    supportedDeviceRoles		[1]
    useTemplate	:		true
    userDescription	:	33\nCirculateurs chaufferie\nChaufferie\nON = On / OFF = Off\n20 40 41 42 43\nen fait installé avec 224\n
    zwaveCompany	:	Fibargroup
    zwaveInfo	:	3,4,5
    zwaveSoftwareVersion		{0}
    zwaveVersion	:	3.4
actions		{7}
created	:	1661610677
modified	:	1702381061
sortOrder	:	427

J'espère que cette info t'aidra. => merci

 

N.B. quand je teste si un module spécifique (même s'il n'est pas parent) est mort, ca fonctionne avec

{"Dead", <id module>}

 

[Lazer]

Du coup, j'ai envie de dire "work as designed", il n'y a pas de problème.

Maintenant que tu connais le filtre utilisé par la conditions "Deads" pour détecter les modules morts... ça devrait être bon.
Il faudra juste que tu sois vigilant la prochaine fois que ton module problématique passe en nœud mort, bien vérifier le statut du module parent.

 

De son coté, "Dead", ne fait pas de recherche avec un filtre, il vérifie uniquement la propriété dead du module indiqué en paramètre, donc peu importe qu'il soit parent, enfant, Z-Wave Zigbee ou QuickApp, etc...

[jojo]

ok, mais alors pourquoi il n'a pas réagit à un des 5 modules parents qu'il a détecté comme mort ?

(dans mon message initial, je parlais en effet d'un child, mais GEA aurait du réagir pour les autres parents vus comme mort. En effet, je suis le premier surpris d'un tel bug, mais pourquoi n'ai-je pas de notif pour les autres ?)

[Lazer]

Je ne sais pas, il faut attendre que le cas se reproduise pour analyser la situation.

[jojo]

dans mon post de ce matin, c'était du direct : pas de notif, et le json que j'ai posté ... Que dois-je faire de plus ?

[Lazer]

Comme je t'ai dit, attendre que le bug se reproduise pour analyser le résultat de l'API.
Gea n'est pas en cause à ce niveau là.

[jojo]

suite au redémarrage de GEA cette nuit (backup hebdo), le règle "Deads" m'a bien envoyé une notif => cool.

 

Cela m'a fait pensé à un truc du coup.

GEA n'exécute les actions que s'il y a modification dans les conditions (normal).

=> pour "Deads", il va regarder s'il y a un json de généré, mais, question, regarde-t-il si les id retournés sont différentes ? Cela expliquerait que si ids 100 et 101 sont rapportés comme morts, si ces ids deviennent 101 et 102, il ne voit pas de modif, donc pas d'actions ? une piste ?

[Lazer]

Je t'avoue que là je ne sais pas trop... car "Deads" retourne une table (celle issue de l'appel à l'API), donc derrière je ne sais pas trop comment il faut sa comparaison des différents éléments du tableau en interne... il faudrait relancer GEA avec toutes les traces de debugs activées pour essayer de comprendre... je ne suis pas vraiment motivé...

[jojo]

ok, je comprends. Donc comme GEA-Deads me servait de déclencheur pour mon QA Deads, je ferai tourner mon QA en boucle toutes des heures et il sera 100% indépendant.

[jojo]

Salut @Lazer,

Dans un autre post, tu disais que tu n'avais pas le temps car tu faisais beaucoup de choses (inutiles).

Je viens d'avoir une idée d'une évolution (inutile aussi) de GEA.

 

Rajouter un paramètre à la fonction email de GEA : temps minimum (en sec) depuis le dernier démarrage de GEA pour envoyer le mail : j'utilise énormément cette fonction pour me notifier de différentes actions prises, et du coup, à chaque redémarrage de GEA, je reçois pleins de mails inutiles.

Pour assurer la rétrocompatibilité avec les versions précédentes, s'il n'est pas précisé, il est à 0 (comme actuellement).

 

C'est juste une idée pour faire de la domotique inutile ...

(que la communauté like cette proposition, histoire de motiver @Lazer )

[Lazer]

Je ne suis pas certain d'avoir compris ce que tu veux faire.... car il me semble qu'il te suffit de mettre l'action Email dans une action Sleep pour la déclencher avec le retard que tu veux.

[jojo]

je ne connaissais pas cette action.

De ce que je lis de la doc, elle fera de toute façon l'action, mais avec un délais.

Ici, ce que je propose, c'est une condition supplémentaire d'exécution de l'action (temps depuis démarrage de GEA), sans devoir lourdement modifier les conditions de la règle GEA, condition qui du coup s'appliquerait à toutes les actions.

Est-ce plus clair maintenant ?

[Lazer]

Euh.... non désolé

 

Tu peux me faire un exemple de ce serait une règle "lourdement modifiée" pour que je comprenne ce que tu souhaites ?

 

[jojo]

voici la version(très) longue de mon idée.

J'espère du coup que je serai plus clair.

 

Lors de chaque redémarrage de GEA (suite à un Save, auto backup, ...), je reçois des mails "inutiles", mails qui proviennent des règles suivantes : (une seule règle en exemple).

GEA.add ({"TurnOff", id["PISCINE_MODEHIVER"]}, 0, "",
         {"Email", "admin", "Piscine \nMode Hiver OFF\nle #date# à #time#.",
                            "Piscine - Mode Hiver OFF"})

C'est un mail que je ne voudrais recevoir que si GEA tourne depuis (par exemple) 60 secondes.

Proposition de règle :

GEA.add ({"TurnOff", id["PISCINE_MODEHIVER"]}, 0, "",
         {"Email", "admin", "Piscine \nMode Hiver OFF\nle #date# à #time#.",
                            "Piscine - Mode Hiver OFF", 60})

 

Et cette règle doit rester (par exemple)

GEA.add (true, 0, "", 
         {"Email", "admin", "Démarrage de GEA\nle #date# à #time#.",
                            "Démarrage de GEA"})

donc (pour assurer la rétrocompatibilité) si on ne met pas de paramètre de temps, c'est comme si

GEA.add (true, 0, "", 
         {"Email", "admin", "Démarrage de GEA\nle #date# à #time#.",
                            "Démarrage de GEA", 0})

 

Ai-je été plus clair ?

[Lazer]

Oui c'est clair, c'est donc conforme à ma proposition, tu mets l'"Email" de ta première règle dans un "Sleep" et ça fera exactement ce que tu souhaites.

Et tu ne touches pas à la seconde, l'email partira donc normalement dès l'exécution de la règle, c'est à dire au démarrage de GEA.

[jojo]

Je vais tester, j'étais en effet plein d'espoir à la lecture de ta proposition initiale, mais ce qui a semé le doute dans mon esprit (tordu) c'est ceci dans la doc de syntaxe

-- "Sleep" : Exécute une action après une durée spécifiée

	-- SYNTAXE :
	{"Sleep", <duree_en_secondes>, {ACTIONS}}

	-- CONDITIONS : Ne peut pas être utilisé comme CONDITION

	-- ACTIONS :
	GEA.add( {CONDITIONS, 30, "", { {"QA", id["TELCO_TV"], telcotv_mute}, -- Appui sur bouton mute de la télécommande,
		{"Sleep", 2, {"QA", id["TELCO_TV"], telcotv_ok}}                    -- Attente de 2 secondes puis Appui sur OK de la télécommande
	})

et donc ma crainte est que l'exécution de l'action se fasse, mais juste avec un délais (c'est ce qui est mis dans l'exmple ?).

[Lazer]

Euh... ben... oui c'est ça.

Au final ça fera bien la même action que tu souhaites : "C'est un mail que je ne voudrais recevoir que si GEA tourne depuis (par exemple) 60 secondes."

à savoir envoyer l'action 60 seconde après le démarrage de GEA.

[jojo]

il y a 3 minutes, Lazer a dit :

à savoir envoyer l'action 60 seconde après le démarrage de GEA.

 

non, je n'ai pas du être clair dans l'explication de mon besoin :

Je ne souhaite recevoir le mail si au moment du test de la condition GEA ne tourne pas depuis un certain temps (= 60 sec dans mon exemple).

Donc, dans mon exemple, je ne veux pas recevoir le mail "Piscine - Mode Hiver OFF" à chaque démarrage de GEA, mais uniquement quand je fais l'action {"TurnOff", id["PISCINE_MODEHIVER"]} (si je l'ai fait 60 sec après le démarrage de GEA, sinon tant pis pour moi)