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

[Dragoniacs 435]

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 8 473]

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 435]

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

Envoyé de mon M2012K11AG en utilisant Tapatalk

[Lazer 8 473]

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 435]

Ok, je teste ça, merci encore

Envoyé de mon M2012K11AG en utilisant Tapatalk

[jojo 2 612]

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 8 473]

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 2 612]

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 8 473]

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 2 612]

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 8 473]

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

[jojo 2 612]

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 8 473]

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 2 612]

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 8 473]

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 2 612]

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.