Aller au contenu

Messages recommandés

Posté(e) (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é par MAM78
  • Like 1
Posté(e)

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à :)

 

Posté(e)

Oups. J'avais effectivement loupé l'étape de l'update de la dernière version du Main. C'était pourtant clairement écrit. :94:

Posté(e)

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.
Posté(e)

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 :P

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à.

 

Posté(e)

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à

 

Posté(e)

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

 

Posté(e) (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é par 971jmd
Posté(e)

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

 

 

 

 

  • Like 1
Posté(e)

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.

  • Like 1
Posté(e)

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
  • Like 1
Posté(e)

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 

Posté(e)

@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

 

Posté(e)

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)

 

 

Posté(e)

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.

 

Posté(e)

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 ?

Posté(e)

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é :ph34r:) 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)

Posté(e)

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

 

 

 

 

Posté(e)

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 :D

 

×
×
  • Créer...