Lazer

Mais ça n'a pas de sens pour les Children, si le développeur du QuickApp a bien fait son boulot, lis sont bien typés (binary sensor, multlevel sensor, etc), donc le changement d’icône est en standard dans l'interface Web Le problème ne se pose que pour les QuickApps parents de type Générique et Device Controler, pour lesquels on ne peut pas changer l’icône via l'interface (d'où l'astuce que tu as partagé)

C'était prévisible, l'abandon du Python 2 était annoncé de longue date Perso dès que j'ai vu l'annonce de Kodi v19 stable, je me suis empressé de bloquer les mises à jour automatiques des applications dans le Play Store. Ce que tu peux faire pour downgrader, car je me suis fait piéger lors du passage à Kodi 18 (qui s'est mis à jour tout seul), c'est de télécharger l'archive APK de la version précédente (v18.9 de mémoire) et tu forces son installation, ça te permettra de revenir en arrière. Et dans le Play Store, tu bloques les mises à jour automatiques jusqu'à ce que l'add-on soit mis à jour en Python 3. Le seul truc pénible, c'est de devoir mettre à jour les autres application manuellement pendant ce temps là (bien que ça ne soit même pas obligatorie)

Beau boulot de récapitulation ! Si tu cherches un tutoriel complet de A à Z Pour GEA, j'ai peur que ça n'existe pas. GEA est un outil qui a considérablement évolué, entre la toute première version (qui s’appelait différemment... WTDSSO : What To Do If Still Open), les nombreux ajouts suites aux demandes utilisateurs, et les réécritures multiples. Pour la dernière en date, le portage sur HC3, je me suis attaché à ce que les règles restent le plus possibles identiques à la syntaxe sur HC2 (la seule différence, ce sont les valeurs que prennent les devices, car comme dit plusieurs fois, sur HC3 les valeurs sont correctement typées ce qui n'a jamais été le cas sur HC2... donc un détecteur prend les valeurs true/false, un multilevel sensor prend une infinité de valeurs numériques, etc.... sur HC2 tout était sous forme de string) Bref, du coup les utilisateurs de GEA ont suivi les évolutions au fil de l'eau, sans révolution majeure à chaque fois, donc il était facile de s'adapter au fur et à mesure. En revanche, pour un nouvel utilisateur, je comprends qu'on puisse être vite sous l'eau. Il faudrait un motivé pour rédiger un tuto de GEA "pour les nuls", mais c'est chronophage... perso je préfère passer du temps sur les développements LUA que de rédiger de la doc. La documentation de référence la plus complète et à jour est effectivement syntaxe_GEAV6_11.lua par @pepite Mais il va falloir que je la mette à jour, car dans la prochaine version il y aura une tripotée de nouvelles fonctions, dont il faudra bien documenter la syntaxe.

La nouvelle version du QA pour l'EcoDevice ça sera pour juste après, la prochaine version de GEA... donc disons courant mars

Un QuickApp ? Oui complètement. Mais ce dont on parle, à savoir l'appel des fonctions des QA depuis n'importe où, ça serait équivalent aux méthodes publiques des classes/Objets. En fait, toute fonction appartement aux QA est automatiquement exportée et accessible à tous. Aussi bien pour les fonctions perso qu'on crée nous même que les fonctions prédéfinies (QuickApp:debug() par exemple)

Et oui, l'appel direct des méthodes des QuickApps, c'est fantastique, je le clame haut et fort depuis des mois sur le forum

oui voilà mais sans sleep, c'est inutile

Ah ben oui mais là c'est normal, et si tu regardes la zone de debug tu vas comprendre pourquoi Tes 3 règles sont exécutée séquentiellement, lors du premier clic : - BOUTON = A donc la première règle est remplie => exécution BOUTONB prend la valeur B - BOUTON = B (il vient d'être mis à jour par la 1ère ligne) donc la première règle est remplie => exécution BOUTONB prend la valeur C - BOUTON = C (il vient d'être mis à jour par la 2nde ligne) donc la première règle est remplie => exécution BOUTONB prend la valeur OK Donc en 1 seul clic, ta variable est passée de A à OK directement en passant par les valeur intermédiaires B et C pendant quelques millisecondes Bref, c'est juste logique, GEA fait ce que tu lui dit de faire EDIT : maintenant je comprends ton Sleep Mais il y a plus simple, il te suffit d'écrire tes lignes à l'envers, de bas en haut

Voilà Pour info c'est l'ancienne API qui date de la v3 sur HC2. Elle fonctionne toujours, Fibaro l'a conservé, même si ce n'est plus documenté, et c'est indispensable pour les vieux appareils qui ne savent pas faire de requêtes POST/PUT, comme l'IPX800, le Rabiit, et pleins d'autres.

ben non justement, ce n'est pas l'inverse, c'est exactement la même chose en GET : /api/callAction?deviceID=93&name=push&arg1=10&arg2=power

Cool D'ailleurs dans la prochaine version on pourra appeler les profils par leur nom, j'ai réussi à l'intégrer dans GEA (idem pour les noms des partitions d'alarme)

Ben oui, j'ai une idée, mais elle va pas te plaire. Ajoute le neutre (débrouille toi pour le passer dans la gaine) Sinon au pire du peux tenter avec le bypass, mais j'y crois guère

Cool Tu veux appeler quoi dans le QA ? Parce que j'ai le même problème avec l'IPX800 v4 qui ne sait faire que des requêtes GET, et pourtant je peux tout faire (appeler une fonction d'un QA avec passage de paramètres), donc tu peux t'en sortir normalement.

Non mais je connais, mais ils ont pas de Nodon, et de toute façon c'est pas intéressant sur de petites commandes à cause des frais de réexpédition

Les parenthèses autour de la condition "(Global)", oui voilà parfait. Ainsi le changement de valeur de la variable globale ne déclenchera pas une instance instantanée de GEA Pour tes 2 lignes, j'ai du mal à voir la finalité.... vu que tu joues des Sleep de 2 secondes, il doit y avoir des effets de bords dans la vérification des paramètres

Bon bah j'arrive toujours pas à commander sur Domadoo en payant par Paypal, après la saisie de mon mot de passe Paypal puis le choix de la CB, quand je suis redirigé sur le site de Domadoo j'ai ce superbe message : Et comme je suis geek et que j'espère qu'ils nous font pas le coup de la blague du texte blanc sur fond blanc, le code HTML n'indique rien de plus : Magnifique

Yes, c'est normal, quand tu utilises #profile# pour récupérer la valeur du profil courant, en fait ce raccourci n'existe pas dans GEA Je l'ai rajouté dans la prochaine version 7.20 de GEA. J'ai testé tes lignes, elles fonctionneront. En attendant, il faudrait récupérer la valeur du profil avec #value# : GEA.add({{"(Profile!)", 3}, {"Value", "Présence Belette", false}}, 30, "&-1&GEA HC3 : Personne à la maison, activation du mode AWAY", {{"Profile", 2}, {"VariableCache", "Previous_Profile", "#value#"}})

Non, le onInit() c'est juste la première fonction appelée lors de la création du QA (pas tout à fait, mais pour simplifier on va dire que c'est le cas) Ensuite chaque fonction va se déclencher sur événement. Par exemple un utilisateur qui a cliqué sur un bouton/slider du QA, une fonction qui est appelée en asynchrone par un setTimeout() dans le cas d'une pseudo boucle infinie, ou bien encore une fonction appelée depuis l'IHM ou un autre QA, etc. Le reste du temps, le QA ne fait rien. C'est tout simple en fait.

Voilà, le déclenchement par trigger, c'est bien là la seule fonctionnalité exclusive aux scènes. Et encore, avec un QuickApp, on peut utiliser l'API refreshStates et arriver au même résultat (voir exemple d'implémentation dans GEA, tout en bas du fichier main) Mais ça reste plus complexe à mettre en œuvre, donc pour le semi-débutant qui veut juste coder quelques lignes de LUA rapides, il reste plus simple de créer une scène avec un trigger.

Ce n'est pas vraiment indispensable, le getdevice est effectué automatiquement toutes les nuits. J'ai laissé le bouton pour les impatients qui veulent voir leurs premiers graphs tout de suite ... Et par la même occasion vérifier que tout fonctionne bien.

Je réessaierai demain Sinon au pire je paierai en CB, mais c'est compliqué, faut aller la chercher pour taper le code... c'est tellement vintage

En Allemagne en passant par un service de boite aux lettres locale et de réexpédition On en a pas mal parlé en décembre dernier dans le topic des bons plans, pour les supers promos Fibaro : modules et HC3 J'essaye de passer commande chez Domadoo depuis cet après-midi, et impossible, après le paiement Paypal ça me renvoie sur le site de Domadoo avec juste le message erreur sans aucun détail. Pfff.... ils sont en faillite ou quoi ? C'est inquiétant là...

Ben déjà, vu que tu n'as pas entouré tes conditions Global par des parenthèses, elles vont être prises en compte en tant que déclencheur (-1), donc tu as créé un beau serpent qui se mort la queue : à chaque fois que tu modifies la variable, ça déclenche immédiatement une nouvelle instance de GEA, etc.... Bref.... relis la doc

Perso j'en suis arrivé à la conclusion que les scènes ne servent quasiment plus à rien sur HC3 (contrairement à la HC2) Les QuickApps savent faire tout ce que savent faire les scènes, et même bien plus... donc le choix est vite fait. Même GEA est devenu un QA pour le coup !! En tout cas tu as raison de tester, c'est pas évident au début, ça permet de se familiariser, d'explorer les possibilités, découvrir les limites. Les Fake-devices, clairement ça n'a plus aucun intérêt, il suffit de se faire autant de QuickApp qu'on veut, avec le bon type, la bonne unité, etc. Intégration native dans la HC3 Et tous les QA sont pris en compte par DomoCharts, ça simplifie tout.

Je n'ai rien défini non plus, mais ça revient à chaque reboot (le bouton en haut à droite se réactive) :