Dragoniacs Posté(e) le 19 février Signaler Partager Posté(e) le 19 février 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" ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 février Auteur Signaler Partager Posté(e) le 19 février 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 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dragoniacs Posté(e) le 19 février Signaler Partager Posté(e) le 19 février Ok merciDu coup, est-ce que la commande "climate!" existe ?Envoyé de mon M2012K11AG en utilisant Tapatalk Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 février Auteur Signaler Partager Posté(e) le 19 février 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". Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dragoniacs Posté(e) le 19 février Signaler Partager Posté(e) le 19 février Ok, je teste ça, merci encore Envoyé de mon M2012K11AG en utilisant Tapatalk Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 5 avril Signaler Partager Posté(e) le 5 avril 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... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 5 avril Auteur Signaler Partager Posté(e) le 5 avril 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 6 avril Signaler Partager Posté(e) le 6 avril 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>} Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 6 avril Auteur Signaler Partager Posté(e) le 6 avril 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... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 6 avril Signaler Partager Posté(e) le 6 avril 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 ?) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 6 avril Auteur Signaler Partager Posté(e) le 6 avril Je ne sais pas, il faut attendre que le cas se reproduise pour analyser la situation. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 6 avril Signaler Partager Posté(e) le 6 avril 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 6 avril Auteur Signaler Partager Posté(e) le 6 avril 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à. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 7 avril Signaler Partager Posté(e) le 7 avril 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 7 avril Auteur Signaler Partager Posté(e) le 7 avril 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é... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 7 avril Signaler Partager Posté(e) le 7 avril 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 3 août Signaler Partager Posté(e) le 3 août 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 ) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 3 août Auteur Signaler Partager Posté(e) le 3 août 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 4 août Signaler Partager Posté(e) le 4 août 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 4 août Auteur Signaler Partager Posté(e) le 4 août 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 5 août Signaler Partager Posté(e) le 5 août 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 5 août Auteur Signaler Partager Posté(e) le 5 août 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 7 août Signaler Partager Posté(e) le 7 août 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 ?). Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 7 août Auteur Signaler Partager Posté(e) le 7 août 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jojo Posté(e) le 7 août Signaler Partager Posté(e) le 7 août 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) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés