Lazer

Je pense que cette commande ne va modifier que la valeur (numérique) du slider, donc sa position gauche/droite J'ai l'impression que le texte n'est pas accessible directement. Tu peux tenter via un hack, c'est à dire en injectant le texte via l'API, mais le risque en faisant ça, c'est que tu ne puisses plus modifier l'apparence du QuickApp via l'interface graphique par la suite (problème connu quand on injecte une zone d'image, une liste déroulante, case à cocher, etc) Vivement que Fibaro nous permette en standard de personnaliser l'apparence des QuickApps, ça manque vraiment pour le moment.

Pour coller ton code dans le forum, il faut utiliser les balises </> dans la barre au dessus de la zone d'édition : Puis choisir LUA dans la liste pour obtenir la coloration du code : Car en l'état, c'est illisible, et il manque les numéros de ligne pour se repérer par rapport aux erreurs qui te sont remontées. Par ailleurs, sans même tenter de lire ton code, il y a un caractère étrange qui me saute aux yeux. Pas sûr que ça soit normal, et en tout cas l'interpréteur LUA n'en voudra pas si tu l'as collé tel quel sur la box :

Bienvenue sur le forum

J'aurais tendance à répondre le plus simplement possible, c'est à dire sans la HomeCenter ou la eedomus. Google peut communiquer en direct avec le pont Hue, c'est la meilleure solution. A paramétrer dans ton compte je suppose (je suppose car je n'utilise ni Hue, ni Google Assistant)

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