mprinfo Posté(e) le 4 décembre 2020 Signaler Posté(e) le 4 décembre 2020 Ça va te coûter chère en bières Envoyé de mon BLA-L29 en utilisant Tapatalk
Dragoniacs Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 On les boira ensembles Envoyé de mon RMX1993 en utilisant Tapatalk 2
MAM78 Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 (modifié) Je viens d'installer la QA GEA et j'ai l'erreur suivante. [05.12.2020] [18:24:02] [ERROR] [QUICKAPP67]: QuickApp crashed [05.12.2020] [18:24:02] [ERROR] [QUICKAPP67]: main.lua:728: attempt to index a nil value (field 'globalvalue') Est-ce normal, je suppose que c'est lié à la variable globale : GEA_Tasks Petite question sans aucune espèce de critique. Pourquoi ne pas avoir mis les variables ci-dessous dans l'onglet des variables de la QA ? Ce ne serait-ce pas plus dans la philosophie des QA afin de ne pas avoir à modifier le code de l'onglet config pour agir sur l'exécution ? Je dis ça, je ne dit rien. Puisqu'en plus je n'y connais encore rien en matière de QA sur HC3 -- =================================================== -- Configuration générale -- =================================================== GEA.debug = true GEA.checkEvery = 30 GEA.portables = {} GEA.globalvariables = "GEA_Tasks" GEA.language = "fr" Modifié le 5 décembre 2020 par MAM78 1
Lazer Posté(e) le 5 décembre 2020 Auteur Signaler Posté(e) le 5 décembre 2020 Tu as quelle version de GEA ? Le QA en première page est la version beta, il faut ensuite installer la dernière beta en copiant/collant le code LUA donné également en première page. Actuellement c'est la 7.03 la dernière. Concernant tes remarques, en théorie tu as raison et je suis le premier à le dire. Mais dans le cas de GEA, il faut : - configurer des dizaines (ou centaines) de lignes de codes GEA.add(), donc on n'est pas à 5 lignes d'options près - je préfère avec toute la config dans un seul fichier, que je copie/colle depuis mon Notepad, plutôt que de me dire... ah mes attention, il y a aussi des options ailleurs. - et surtout : je voulais maintenir la compatibilité avec le code GEA existant sous HC2, pour faciliter les migrations. Cependant, ta remarque sur les variables globales m'amène à penser que GEA_Tasks n'a rien à faire dans les variables globales, mais devrait simplement être stockée dans les variables du QuickApp lui-même. Je n'y avais pas pensé, c'est idiot... à venir dans une prochaine version. De même que les variables SuspendreGEA et GEA_History. D'ailleurs je n'ai jamais compris l'utilité de GEA_History, elle sert en dehors de GEA lui-même ? Si un expert passe par là
MAM78 Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 Oups. J'avais effectivement loupé l'étape de l'update de la dernière version du Main. C'était pourtant clairement écrit.
MAM78 Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 Quelques petites suggestions qui ne vas pas révolutionner GEA mais qui pourraient être cool : Ajout d'un label : Version actuelle de GEA Ajout d'un label : Etat du mode Debug Ajout d'un Label : Etat de la variable globale : SuspendreGEA Disponibilité d'une nouvelle version : (lecture d'un fichier json présent dans un Git) avec le ChangeLog correspondant et pourquoi pas une notification par mail au compte d'administration.
Lazer Posté(e) le 5 décembre 2020 Auteur Signaler Posté(e) le 5 décembre 2020 Mouais, pas convaincu de la pertinence des labels.... tu vas faire comme mprinfo en fait, tu veux une HC3 mais tu veux l'utiliser comme une HC2 Cela dit c'est facile à rajouter... alors pourquoi pas. Pour le suivi des versions, mouais, je suis pas assez rigoureux pour ça, j'ai déjà mis des trucs sur Github mais je ne fais aucun suivi. Puis c'est dangereux, car : - le mec qui utilise activement GEA suit le topic et est au courant des dernières mises à jour - le mec qui ne s'en préoccupe pas, va voir la notification, va s'empresser de télécharger, et casser son GEA fonctionnel, parce qu'entre temps il y a aura un nouveau bug ou un changement de comportement voulu. Bref, pas super fan pour ce coup là.
MAM78 Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 Pas forcément dangereux. Tu nous feras des versions bêtas stables et des stables en bêtas. Tu feras sûrement mieux que Fibaro sur ce coup là
MAM78 Posté(e) le 5 décembre 2020 Signaler Posté(e) le 5 décembre 2020 Sans vouloir insister lourdement. Avec une notion de versions Stables et de Bêtas, les gars frileux ou qui ne suivent pas trop ils auraient le choix d’upgrader que les stables. Envoyé de mon iPhone en utilisant Tapatalk Pro
971jmd Posté(e) le 6 décembre 2020 Signaler Posté(e) le 6 décembre 2020 (modifié) salut Je pense qu'il y a un bug, je m'explique ---- c'est ici le PROBLEME ----pourquoi le VL PRINCIPAL s'ouvre une fois que VL BAR à dépasser les 70%, sans que j'appuie sur le bouton 3 GEA.add({{"Global", "VL", "ok"}, {"SceneActivation", id["MINITELECOM"] , 3}} , -1, "", {{"Open", {id["VL_PRINCIPAL"]}, 100} }) Quand on regarde les conditions, elle n'est son pas toute remplie car je n'ai pas appuyé sur le bouton 3 et pourtant le VL_PRINCIPAL s'ouvre ---exemple ----j'appuie sur le bouton 3 ouverture du VL bar -----***Jusque la PAS DE PROBLEME*** GEA.add({"SceneActivation", id["MINITELECOM"] , 3}, -1, "", {{"Open", id["VL_BAR"] } }) --quand le VL dépasse les 70% la variable VL passe à OK -----***Jusque la PAS DE PROBLEME*** GEA.add({{"Value+", id["VL_BAR"], 70 }} , -1, "VLBAR OUVERT", {{"Global", "VL", "ok"} }) ---- c'est ici le PROBLEME ----pourquoi le VL PRINCIPAL s'ouvre une fois que VL BAR à dépasser les 70% ---pourtant je n'ai pas appuyé sur le bouton 3 GEA.add({{"Global", "VL", "ok"}, {"SceneActivation", id["MINITELECOM"] , 3}} , -1, "", {{"Open", {id["VL_PRINCIPAL"]}, 100} }) Modifié le 6 décembre 2020 par 971jmd
Dragoniacs Posté(e) le 6 décembre 2020 Signaler Posté(e) le 6 décembre 2020 Si tu as mis VL_BAR dans les déclencheur en entête mais que tu ne veux pas qu'il active certaines lignes, alors il faut utiliser des parenthèses sur ta condition : GEA.add({{"(Global)", "VL", "ok"}, {"SceneActivation", id["MINITELECOM"] , 3}} , -1, "", {{"Open", {id["VL_PRINCIPAL"]}, 100} }) Envoyé de mon RMX1993 en utilisant Tapatalk 1
Lazer Posté(e) le 6 décembre 2020 Auteur Signaler Posté(e) le 6 décembre 2020 Absolument, méfiance avec les déclenchements instantanés à plusieurs conditions, il faut bien entourer de parenthèses toutes les conditions qui ne doivent pas être prises comme déclencheur. C'était déjà important sur HC2, mais ça l'est encore plus sur HC3 car maintenant GEA détecte tout seul les déclencheurs (il n'est plus nécessaire de définir soit-même les déclencheurs de scènes) @MAM78 ok on verra plus tard, beaucoup plus tard, j'ai plein d'autres choses autrement plus utiles à développer sur HC3 avant de penser à ce genre d'améliorations. Pour l'instant, je cherche déjà à résoudre tous les bugs pour rendre GEA stable pour tous. 1
Dragoniacs Posté(e) le 6 décembre 2020 Signaler Posté(e) le 6 décembre 2020 La bière est au frais@Lazer Envoyé de mon RMX1993 en utilisant Tapatalk 1
mprinfo Posté(e) le 6 décembre 2020 Signaler Posté(e) le 6 décembre 2020 Voir j'y crois pas juste une bière. La tu connais mal@Lazer Envoyé de mon BLA-L29 en utilisant Tapatalk
Dragoniacs Posté(e) le 6 décembre 2020 Signaler Posté(e) le 6 décembre 2020 J'ai un beertender sinon Envoyé de mon RMX1993 en utilisant Tapatalk 1
Lazer Posté(e) le 7 décembre 2020 Auteur Signaler Posté(e) le 7 décembre 2020 Bon je pense que j'ai corrigé les bugs, tu peux tester la version 7.04 Beta ci-jointe GEA.add({{"Value", "Réserve Némo", true}, {"Value", "Osmolateur Némo", false}}, 30, "&-1&OSMOLATEUR : Mise en marche de l’osmolateur", {"TurnOn", "Osmolateur Némo"}) GEA.add({{"Value", "Réserve Némo", false}, {"Value", "Osmolateur Némo", true}}, 30, "&0&OSMOLATEUR : Réserve vide - Arrêt de l’osmolateur", {"TurnOff", "Osmolateur Némo"}) Remarque : j'ai remplacé les apostrophes dans le message par leur version typographique, car sinon la HC3 bloque les messages Push vers l'application mobile. Tu ne t'en étais peut être pas rendu compte si tu utilises toujours ton GEA.output personnalisé. A priori ça fonctionne maintenant bien comme attendu : [07.12.2020] [12:50:40] [TRACE] [QA_GEA_214]: [Démarrage] #2 [Value, ["Réserve Némo",true]][Value, ["Osmolateur Némo",false]][TurnOn, ["Osmolateur Némo"]] [07.12.2020] [12:51:40] [TRACE] [QA_GEA_214]: [Démarrage] #3 [Value, ["Réserve Némo",false]][Value, ["Osmolateur Némo",true]][TurnOff, ["Osmolateur Némo"]] [07.12.2020] [12:52:40] [TRACE] [QA_GEA_214]: [Démarrage] #2 [Value, ["Réserve Némo",true]][Value, ["Osmolateur Némo",false]][TurnOn, ["Osmolateur Némo"]] [07.12.2020] [12:53:40] [TRACE] [QA_GEA_214]: [Démarrage] #3 [Value, ["Réserve Némo",false]][Value, ["Osmolateur Némo",true]][TurnOff, ["Osmolateur Némo"]] J'ai simulé le capteur et l'actionneur avec des QuickApps, que j'ai nommé à l'identique des tiens. GEA v7.04.lua Corrige la mauvaise détection de la "value" des devices 1
971jmd Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 Salut Pour moi ça fonctionne, merci bien Je ne connaissais pas l'astuce des parenthèses et effectivement l'utilisation des -1 sur HC3 son délicate
Dragoniacs Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 Merci@Lazer je vais tester ça et je te ferai un retour.Envoyé de mon RMX1993 en utilisant Tapatalk
Dragoniacs Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 @Lazer, mauvaise nouvelle, cela ne fonctionne pas du tout.... il ne se passe absolument rien en fait... Pourtant cela doit pouvoir se faire, car en attendant je le pilote parfaitement via une scène : Status_Reserve = fibaro.getValue(36, "value") Status_Osmolateur = fibaro.getValue(38,"value") if Status_Reserve and not Status_Osmolateur then fibaro.call(38, "turnOn") fibaro.setGlobalVariable("Pushover", "&-1&OSMOLATEUR : Réserve OK, pompe activée.") end if not Status_Reserve and Status_Osmolateur then fibaro.call(38, "turnOff") fibaro.setGlobalVariable("Pushover", "&0&OSMOLATEUR : Réserve vide, pompe arrêtée.") end if not Status_Reserve and not Status_Osmolateur then fibaro.setGlobalVariable("Pushover", "&0&OSMOLATEUR : Réserve vide, pompe arrêtée.") else fibaro.debug("OSMOLATEUR", "Osmolateur running...") end
Lazer Posté(e) le 7 décembre 2020 Auteur Signaler Posté(e) le 7 décembre 2020 ah... "absolument rien" ? Il va falloir m'en dire plus, sinon impossible de deviner. Que se passe-t-il si tu tests unitairement chacun des modules, comme par exemple : GEA.add({{"Value", "Réserve Némo", true}}, 0, "&0&OSMOLATEUR : Réserve pleine") GEA.add({{"Value", "Réserve Némo", false}}, 0, "&0&OSMOLATEUR : Réserve vide") Si tu veux éviter d'aller tremper le détecteur pour chaque test, tu peux forcer son changement d'état avec les commandes curl suivantes depuis un Shell : curl --write-out "HTTPSTATUS:%{http_code}" --request PUT --user 'Login:Password' --data '{"properties":{"value":false}}' http://192.168.1.1/api/devices/36 curl --write-out "HTTPSTATUS:%{http_code}" --request PUT --user 'Login:Password' --data '{"properties":{"value":true}}' http://192.168.1.1/api/devices/36 (il doit t'afficher en retour le JSON du module modifié ainsi que le code HTTP 200)
Dragoniacs Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 On progresse : ça marche ça GEA.add({{"Value", "Réserve Némo", true}}, 0, "&0&OSMOLATEUR : Réserve pleine") GEA.add({{"Value", "Réserve Némo", false}}, 0, "&0&OSMOLATEUR : Réserve vide") A sec et dans l'eau, je reçois bien les 2 messages.
Dragoniacs Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 Bon, ça fonctionne avec des "true / false" sur l'ID de l'osmolateur. Un peu étrange car c'est une prise Fibaro toute simple... Pourquoi le "1 / 0" ne fonctionne pas ? [07.12.2020] [19:44:51] [TRACE] [QA_GEA_26]: [Démarrage] #10 [Value, ["Réserve Némo",true]][Value, ["Osmolateur Némo",false]][TurnOn, ["Osmolateur Némo"]] [07.12.2020] [19:44:51] [DEBUG] [QA_GEA_26]: [action] [TurnOn, ["Osmolateur Némo"]] [07.12.2020] [19:44:52] [DEBUG] [QA_GEA_26]: @120s [Validation] #12 [Value, ["Réserve Némo",false]] Autre question : lorsque GEA détecte que l'osmolateur est coupé alors que la réserve est pleine, il réalise le "turnOn". Et le cycle suivant, cette ligne apparait en "stoppé" dans le debug. Est-ce normal ?
Lazer Posté(e) le 7 décembre 2020 Auteur Signaler Posté(e) le 7 décembre 2020 OK donc tu t'es heurtée à l'API de la HC3 qui a changé par rapport à la HC2. Les modules de type binaire (actionneur comme capteur) prennent value = true | false maintenant Et c'est très bien ainsi, c'était une aberration les valeurs 0 et 1 sur la HC2. Donc pour te répondre, les "0" et "1" ne peuvent pas fonctionner, puisqu'il ne matchent jamais avec les valeurs booléennes true et false des modules qui nous intéressent. A l'époque, dans le code de GEA, @Steven avait bidouillé pour prendre en compte les status 0 et 1, car la HC2 stockait toutes les value en mode String. Je me suis justement appliqué à supprimer ces bidouilles, afin de coller exactement à l'API de la HC3, car comme je disais au dessus, les modules prennent enfin des valeurs logiques. Soit Booléennes, soit Numériques, soit Érotiques (String... désolé ) selon le type de module. Tu peux regarder le JSON des différents modules (Z-Wave ou QuickApps) et tu verras. Ces modifications dans GEA ont justement été à l'origine d'un bug que tu m'as aidé à identifier dans cette dernière version. De façon générale, que ça soit en LUA ou dans GEA, quand tu exploites les valeurs des modules, il faut que tu fasses attention à leur valeur réelle... à vérifier dans le JSON de chaque module. Je ne suis pas certain de savoir te répondre pour le "stoppé", mais je suppose que c'est parce que l'action a déjà été réalisée. Si tu mettais un "Repeat", il devrait re-déclencher l'action (si la valeur de l'osmolateur n'a pas changé pour une raison ou une autre)
Dragoniacs Posté(e) le 7 décembre 2020 Signaler Posté(e) le 7 décembre 2020 Mdrrr les valeurs érotiques ! Cest pas plus mal si on colle aux valeurs des modules. Surtout que les json sont accessibles directement depuis l'interface de la HC3. Il faudra juste mettre à jour le wiki Le stoppé ne le gène pas, je n'ai pas besoin que cela boucle avec un on/off toutes les 30s, cela n'arrive pas (je mets plus de 30s a voir que la réserve est vidée et remettre de l'eau) Envoyé de mon RMX1993 en utilisant Tapatalk
Lazer Posté(e) le 7 décembre 2020 Auteur Signaler Posté(e) le 7 décembre 2020 En fait je pense que le stop apparait parce que tu es probablement en mode debug = true, sinon il ne devrait pas apparaitre. Pour le Wiki, oui je pense que je finirai par m'y coller. Mais @pepite m'avait dit qu'il était motivé.... il est en mode fantôme en ce moment. Pourtant il a du temps libre le temps la nuit... très tôt le matin
Messages recommandés