Lazer

certes.... mais ça n'a d'intérêt que parce que tu as plus de 12 enfants identiques et pour lesquels du mets la même icône. C'est quand même un cas particulier.

C'est très bien, mais je pense que ce que veut faire @Kana-chan tient en une seule ligne avec api.put(), car il n'a pas besoin de passer par la méthode compliquée avec l'authentification pour juste modifier les propriétés d'un device Pas testé, mais un truc dans le genre doit faire l'affaire : local deviceID = fibaro.getGlobalVariable("IdWallPlug") local mycolor = 0 local data = { id = tonumber(deviceID), properties = { parameters = { { id = 62, size = 1, value = mycolor } } } } local response, status = api.put("/devices/"..deviceID, data) print("status : " .. status) print("response : " .. response)

Euh... j'aime bien coder en LUA, mais quand même, proposer de changer l'icône via du LUA alors que c'est faisable en standard en cliquant sur un bouton dans l'interface Web, faut être un peu maso Puis : Et encore, cette seconde étape ce n'est que la première fois, les fois suivantes il suffit juste de cliquer sur l’icône déjà présente, comme dans mon premier screenshot. Pourquoi faire simple quand on peut faire compliqué

Tu ne peux pas juste faire une ligne GET .... d'ailleurs tu l'as mis où cette ligne ? Il faut coder la requête HTTP en quelques lignes de LUA. (dont la syntaxe diffère un peu du PHP auquel tu dois être habitué sur eedomus... mais perso pour pratiquer les 2, je trouve que le LUA est plus simple, plus lisible, et facile à écrire) Tu peux regarder ce mini tuto, dont la syntaxe est utilisable sur HC3, dans une scène ou bien dans un bouton d'un QuickApp :

En direct non, il faudra passer par une passerelle. Quelque soit le protocole, RTS ou IO, c'est le même combat... Remarque, c'est un peu mieux en IO, avec le KLF-050 et un module FGS-224, tu peux avoir une intégration native et relativement simple à mettre en place (tuto sur le forum) Si RTS, je pense que tu seras obligé de passer par une passerelle "intelligente". Tu parles de RF Player, j'en déduis que tu doit être en RTS ? Du coup, il faut brancher le RFPlayer sur une box domotique que tu utilises en passerelle, comme Jeedom ou autre (on eedomus peut faire l'affaire, mais tu resteras dépendant de leur cloud)

Bienvenue sur le forum

Bienvenue sur le forum

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.