fel-x Posté(e) le 23 février Signaler Posté(e) le 23 février Salut, Encore besoin d'un coup de main avec GEA Je voudrais que le debug ou le push affiche une phrase contenant la valeur d'une variable globale. J'essaye d'exploiter "Function" mais sans succès. Peut-être que je ne cherche pas du bon côté ? Par exemple pour avoir un push : "Il y a eu xx passages aujourd'hui" où xx est la valeur (nombre) de la variable globale "PassToday" j'ai essayé plusieurs combinaisons comme: GEA.add ( {CONDITIONS}, 30, "", {"Push", 840, {"Function", function() local pass = fibaro.getGlobalVariable("PassToday") or "?" return "Il y a eu " .. pass .. " passages aujourd'hui" end} } ) Je suis sur la bone piste? C'est possible de lire la variable en temps réel pour l'inclure dans le push ? merci
Lazer Posté(e) le 23 février Signaler Posté(e) le 23 février "Push" ça va t'envoyer une notification sur ton téléphone, si tu veux juste afficher dans la fenêtre de debug tu peux utiliser l'action non documentée "Test". GEA.add ( {CONDITIONS}, 30, "", {"Test", {"Function", function() return "Il y a eu " .. (fibaro.getGlobalVariable("PassToday") or "?") .. " passages aujourd'hui" end} } ) Ou encore mieux directement avec "Function" uniquement : GEA.add ( {CONDITIONS}, 30, "", {"Function", function() print("Il y a eu " .. (fibaro.getGlobalVariable("PassToday") or "?") .. " passages aujourd'hui") end}) Et si tu mets ta variable globale dans les conditions, il y a même moyen de récupérer sa valeur directement avec #value# ce qui permet de l'inclure simplement dans le texte de l'action "Test" ou bien d'une notification. Un truc dans le genre : GEA.add ( {{"Global+", "PassToday", 0}, AUTRES_CONDITIONS}, 30, "", {"Test", "Il y a eu #value# passages aujourd'hui"}) 1
fel-x Posté(e) le 23 février Signaler Posté(e) le 23 février merci @Lazer tout devient plus simple avec ton aide Ca fonctionne très bien avec "Global+" c'est le plus simple pour récupérer la valeur de la variable plutôt que de faire appel à une fonction. Et je sais que tu n'aimes/emploies pas trop les Push mais dans mon environnement et pour mon usage c'est super pratique. Et pour le coup je découvre l'action "Test" en bonus.
fel-x Posté(e) dimanche à 20:39 Signaler Posté(e) dimanche à 20:39 Et maintenant, je voudrais construire une date de toutes pièces, et plutôt que de faire des essais-erreurs, je viens demander si cela est possible ? Je m'explique : il faudrait que la condition d'une règle GEA soit "Dates" La syntaxe de base est claire : GEA.add( {"Dates", "01/01"} , 30, "", {ACTIONS} ) Mais je voudrais que la date soit construite au départ de 2 variables locales (AlertDay, CurrentMonth) appartenant à une QA (941). Par exemple AlertDay = 27 et CurrentMonth = 3 et donc je souhaite la règle suivante : GEA.add( {"Dates", "27/03"} , 30, "", {ACTIONS} ) Est-ce que je peux la générer dynamiquement comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"VariableQuickApp+", 941, "CurrentMonth", 0}, {"Dates", "#value#/#value#"}} , 30, "", {ACTIONS} ) Déjà je ne suis pas certain que GEA va récupérer une #value# d'une condition à la suivante, mais en plus je ne sais pas s'il va gérer 2 #value# consécutifs dans la même condition et les distinguer d'office par leur ordre ? Les variables AlertDay et CurrentMonth changent en début de mois dans la QA, et déterminent le jour où une certaine action devra être lancée. AlertDay vaut toujours entre 1 et 31, et CurrentMonth est évidemment toujours le mois en cours (de 1 à 12). Sans doute on pourrait simplifier puisque CurrentMonth est logique à déduire et j'aurais volontiers employé {"Monthly", <num_jour>} comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"Monthly", #value#}}, 30, "", {ACTIONS} ) mais "Monthly" ne fonctionne pas comme prévu. Je suis preneur de tout bon conseil
Lazer Posté(e) dimanche à 21:04 Signaler Posté(e) dimanche à 21:04 Je ferais ça avec "Function" en condition, qui fait le test de la date en LUA "à la main" et retourne true/false pour déclencher les actions de la règle. 1
fel-x Posté(e) il y a 19 heures Signaler Posté(e) il y a 19 heures c'est plus long à programmer, mais ça fonctionne ! Merci @Lazer
fel-x Posté(e) il y a 19 heures Signaler Posté(e) il y a 19 heures Il y a 10 heures, fel-x a dit : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"VariableQuickApp+", 941, "CurrentMonth", 0}, {"Dates", "#value#/#value#"}} , 30, "", {ACTIONS} ) Déjà je ne suis pas certain que GEA va récupérer une #value# d'une condition à la suivante, mais en plus je ne sais pas s'il va gérer 2 #value# consécutifs dans la même condition et les distinguer d'office par leur ordre ? Par curiosité, @Lazer sais-tu m'indiquer le comportement attendu de #value ? Il peut être employé directement dans la règle GEA dès qu'il est "généré" ? Comme par exemple dans une seconde condition ? Je sais qu'on peut l'employer plusieurs fois dans la même règle, mais qu'en est-il s'il y a 2 values générées comme dans ma citation ci-dessus ? Est-ce possible ou il est envisageable d'employer #value1 et #value2 par exemple ? Ou c'est seulement la dernière qui sera reprise par #value ? J'ai fait quelques tests mais avec 2 #value générées dans les conditions, il n'y a ni crash ni exécution de la règle.
jojo Posté(e) il y a 15 heures Signaler Posté(e) il y a 15 heures Il y a 13 heures, fel-x a dit : Et maintenant, je voudrais construire une date de toutes pièces, et plutôt que de faire des essais-erreurs, je viens demander si cela est possible ? Je m'explique : il faudrait que la condition d'une règle GEA soit "Dates" La syntaxe de base est claire : GEA.add( {"Dates", "01/01"} , 30, "", {ACTIONS} ) Mais je voudrais que la date soit construite au départ de 2 variables locales (AlertDay, CurrentMonth) appartenant à une QA (941). Par exemple AlertDay = 27 et CurrentMonth = 3 et donc je souhaite la règle suivante : GEA.add( {"Dates", "27/03"} , 30, "", {ACTIONS} ) Est-ce que je peux la générer dynamiquement comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"VariableQuickApp+", 941, "CurrentMonth", 0}, {"Dates", "#value#/#value#"}} , 30, "", {ACTIONS} ) Déjà je ne suis pas certain que GEA va récupérer une #value# d'une condition à la suivante, mais en plus je ne sais pas s'il va gérer 2 #value# consécutifs dans la même condition et les distinguer d'office par leur ordre ? Les variables AlertDay et CurrentMonth changent en début de mois dans la QA, et déterminent le jour où une certaine action devra être lancée. AlertDay vaut toujours entre 1 et 31, et CurrentMonth est évidemment toujours le mois en cours (de 1 à 12). Sans doute on pourrait simplifier puisque CurrentMonth est logique à déduire et j'aurais volontiers employé {"Monthly", <num_jour>} comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"Monthly", #value#}}, 30, "", {ACTIONS} ) mais "Monthly" ne fonctionne pas comme prévu. Je suis preneur de tout bon conseil j'espère ne pas racconter de bêtise, mais je suis du style "KISS" (keep it simple & stupid)) : pourquoi dans GEA ne pas simplement tester la valeur de la variable de ton QA ou encore plus KISS, ton QA génère "quand il faut" un variable Booléenne GEA, qui est testée par GEA et qu'ensuite GEA remet à false.
jojo Posté(e) il y a 15 heures Signaler Posté(e) il y a 15 heures Il y a 3 heures, fel-x a dit : Par curiosité, @Lazer sais-tu m'indiquer le comportement attendu de #value ? Il peut être employé directement dans la règle GEA dès qu'il est "généré" ? Comme par exemple dans une seconde condition ? Je sais qu'on peut l'employer plusieurs fois dans la même règle, mais qu'en est-il s'il y a 2 values générées comme dans ma citation ci-dessus ? Est-ce possible ou il est envisageable d'employer #value1 et #value2 par exemple ? Ou c'est seulement la dernière qui sera reprise par #value ? J'ai fait quelques tests mais avec 2 #value générées dans les conditions, il n'y a ni crash ni exécution de la règle. cfr ligne 1390 de la syntaxe GEA.add({{"WeatherLocal!", "Temperature", ""}, {"WeatherLocal!", ""}}, 30, "La température ext. est de #value[1]# ° - météo : #value[2]#") 1
fel-x Posté(e) il y a 14 heures Signaler Posté(e) il y a 14 heures il y a 48 minutes, jojo a dit : cfr ligne 1390 de la syntaxe Ha ben zut alors, j'ai loupé ça ! Alors que la syntaxe est ouverte dans ZeroBrane en permanence sur mon ordi et que je plonge dedans sans arrêt Par contre soit tu as raccourci/customisé ta syntaxe, soit tu es dyslexique car chez moi c'est la ligne 1930
fel-x Posté(e) il y a 14 heures Signaler Posté(e) il y a 14 heures il y a une heure, jojo a dit : j'espère ne pas racconter de bêtise, mais je suis du style "KISS" (keep it simple & stupid)) : pourquoi dans GEA ne pas simplement tester la valeur de la variable de ton QA ou encore plus KISS, ton QA génère "quand il faut" un variable Booléenne GEA, qui est testée par GEA et qu'ensuite GEA remet à false. Tu as parfaitement raison @jojo je pourrais faire tous les calculs dans ma QA et simplement dire à GEA de vérifier une seule variable "aujourd'hui c'est le jour J" ! Mais tu sais comment ça marche... j'ai écrit une QA qui fonctionne.. j'ai plus envie de la modifier ... je cherche à l'exploiter depuis GEA sans la changer... je m'embourbe dans mes idées de contournement pour pas changer ma QA... Au final ça fonctionne et en bonus j'ai appris des trucs ! Si j'étais un programmeur/codeur professionnel je pense que je serais déjà viré pour avoir fait si compliqué alors qu'une solution simple existait Heureusement c'est juste un hobby Mais maintenant que ça fonctionne de façon complexe, je vais trouver un moment pour simplifier ma logique. merci pour cette autre perspective du KISS
jojo Posté(e) il y a 14 heures Signaler Posté(e) il y a 14 heures en effet, je trouve important de simplifier (et documenter) aux max pour une future maintenance par toi ou la personne qui devra reprendre le brol
fel-x Posté(e) il y a 14 heures Signaler Posté(e) il y a 14 heures Pour info c'est une QA "Edenred" qui calcule le nombre de jours ouvrables du mois prochain (via une API publique), et l'antépénultième jour ouvrable du mois en cours. Ce jour-là, une alerte est envoyée en Push pour rappeler de commander un certain nombre de chèques Ederend (= n jours ouvrables du mois suivant) pour le mois suivant. Je ne pense pas que ça intéressera beaucoup de monde.. ou alors quelques rares utilisateurs en Belgique ? J'ignore si la France ou d'autres pays emploient aussi ce système de "chèques-repas" ou un équivalent.
jojo Posté(e) il y a 11 heures Signaler Posté(e) il y a 11 heures il y aurait alors encore bcp plus simple : tu crées dans ton Google calendar un recuring event avec un mail de notif. La commande de tes chèques TS par virement bancaire n'est pas à 1 jour prêt (encore un exemple de KISS ...)
Lazer Posté(e) il y a 10 heures Signaler Posté(e) il y a 10 heures Il y a 3 heures, fel-x a dit : J'ignore si la France ou d'autres pays emploient aussi ce système de "chèques-repas" ou un équivalent. Si, en France aussi (malheureusement j'ai envie d'ajouter, car c'est un système bourré de limitations... plafonds quotidiens, reports annuels, etc) En plus c'est facturé fort cher aux commerçants (plus que les CB), donc au final on paye notre repas plus cher, car faut pas rêver, le surcout est réintégré dans le prix des plats. Il y a 8 heures, fel-x a dit : Il peut être employé directement dans la règle GEA dès qu'il est "généré" ? Comme par exemple dans une seconde condition ? Je sais qu'on peut l'employer plusieurs fois dans la même règle, mais qu'en est-il s'il y a 2 values générées comme dans ma citation ci-dessus ? Est-ce possible ou il est envisageable d'employer #value1 et #value2 par exemple ? Ou c'est seulement la dernière qui sera reprise par #value ? Je ne suis pas sûr d'avoir la réponse à toutes tes interrogations... il faudrait aller lire le code de GEA pour bien comprendre... il faut du temps... et de la motivation. Déjà @jojo t'a donné une bonne indication sur la possibilité d'exploiter les #value[1]#, #value[2]# etc Cependant, pour moi, ce sont des alias destinés à être remplacés par leur valeur correspondante uniquement dans les messages textuels, c'est à dire ce qui est affiché / envoyé en notification. Et donc... pas dans les conditions (ce que tu cherches à faire). Moi j'utilise de plus en plus "Function", tant en condition qu'en action, car c'est ultra puissant, ça permet de lever toutes les limitations des conditions et actions de GEA. Dans une Function, on code en LUA traditionnel, littéralement comme dans un QuickApp. On peut aussi récupérer les valeurs des conditions de GEA. Exemple, c'est bidon car ça retourne la température de la météo divisée par 2, mais c'est pour montrer un exemple simple d’imbrication des options : {"Function", function(a, b) return (a+b)/2 end, {"Weather", "Temperature"}, 20} L'étape d'après, c'est créer ses propres options (conditions et/ou actions) à décrire dans function config(GEA) Et là c'est no-limit, on peut littéralement écrire l'équivalent d'un QuickApp complet sur plusieurs dizaines ou centaines de lignes. Par exemple j'ai toute ma gestion d'optimisation du chauffage (en fonction du surplus solaire disponible) qui fonctionne comme ça. C'est expliqué brièvement dans la doc de syntaxe au chapitre "PLUGINS INTERNES GEA" (lignes 2069 et suivantes)
Messages recommandés