Fredmas

Je réponds tardivement, mais partant des QuickApp de @couillerot : https://www.domotique-fibaro.fr/topic/15134-quick-app-prévisions-météo-weatherbit-v12/ https://www.domotique-fibaro.fr/topic/15135-quick-app-météo-weatherbit-v12/ encore merci à lui j'ai découvert le fonctionnement de WeatherBit, et surtout j'en ai créé un deuxième actuellement en test parallèle avec OpenWeather. Donc @eric_le_belge si encore besoin, je pourrais éventuellement te partager certains appel API vers leur JSON, ou partager mutuellement quelques bonnes pratiques. Et sinon c'est que tu t'en es sorti, que tu n'as plus besoin, donc content pour toi

Bon, et bien résultat des courses quelques temps plus tard : - Je n'ai plus de variable globale persistante dans l'onglet Variable dans Général - Je n'ai qu'une seule variable persistante (que je ne réécris quasiment jamais) dans l'onglet Variable de chaque QA automatique, qui me permet simplement de savoir si j'avais éteint la boucle automatique ou pas en cas de redémarrage afin de ne pas la redémarrer involontairement - La quasi totalité de mes variables à l'intérieur des QA est passée en local. Mais je n'ai pas encore terminé de réduire leur portée au stricte nécessaire Donc tout simplement merci les gars pour tous les conseils que vous nous apportez en partageant votre savoir qui nous fait comprendre et progresser

Merci beaucoup pour l'explication. Ca répond et c'est clair OK Haaaaaa même en cours d'apprentissage, celle-ci je la connais déjà et je l'utilise dans mes QA

c'est exactement ce que j'ai testé entre midi et deux, et ça fonctionnait "visuellement" effectivement. Je m'apprêtais à en discuter ici ce soir. Le truc auquel je ne savais pas répondre et que je comptais te demander ce soir @Lazer c'est : au-delà du visuel, quel est la conséquence pour le QA de passer ses propriétés en "Dead". C'est un état en attente qui pourrait changer tout seul suivant des conditions précisées ? ou par exemple le QA se met en veille attendant une action manuelle par exemple ?

Bonjour, et bienvenu sur ce très bon forum Bonne ambiance, grosse expertise pour certains, et partage du savoir pour la plupart  Au plaisir de te lire 

J'improvise une réponse sans tester pour vérifier. WalliLu est une variable de ton QA (dans l'onglet variable), pas une déclarée à l'intérieur de ton code, puisque tu écris un setVariable. Ce type de variable s'appelle avec un getVariable... Pas uniquement avec son nom. Donc dans ton updateView tu appelles WalliLu qui n'est pas la variable à laquelle tu penses, et qui est donc probablement nil... donc 0 pour ton slider... Soit tu fais un getVariable, soit tu utilises une variable déclarée dans ton code (local ou pas).

Bon ben je n'ai pas passé 45min hier soir à te chercher cette solution pour rien si ça fonctionne et te dépanne sur cet exemple C'est cool pour toi, et aussi pour moi car au passage ça m’a permis de commencer à investiguer et apprendre la manipulation des API Fibaro, que ce soit dans un navigateur ou dans le swagger, ce que je n’avais pas encore réellement utilisé jusque-là. En parallèle oui la solution de recherche est bien plus propre, et plus facile à adapter/maintenir. Avec l'indice donné par @Lazer j'ai failli m'y mettre hier soir pour essayer de sortir un bout de code alternatif

OK ça je ne sais pas s'il y a une fonction qui "superpose" le petit symbole vert sur l'icone au besoin en fonction de l'état. Car j'avais imaginé (que ce soit pour un QA perso ou un QA Fibaro (y compris pour les modules natifs Fibaro), tout simplement uploder les 2 icones, et faire l'updateProperty en fonction des conditions.

Clear, thanks @jang As my main QA which is checking automatically daily actions to be done is stable now and growing, this week I've started to modify it for code improvement. And as an example, I started by variables definition and localisation. At the beginning, I put main of them as global ones in the onInit. Now they are all as local ones at the very beginning of the code. I didn't measure the performances, and I don't care really, but I am trying to reduce the reach of them as you and @Lazer advised. Next step, probably, to move much of them directly in the local functions in the code, to reduce again the reach. But not sure yet, because they would be more disseminated in the code, thinking about the maintenance.

Si j’ai bien compris ta question normalement tu devrais trouver la réponse ici :

alors ça je n'en sais rien du tout si j'ai fait mieux ou pas, je n'avais jamais vu du LUA de ma vie il y a à peine 6 mois, et encore moins un QA, donc niveau débutant j'en suis. Et puis on s'en fiche d'ailleurs ce n'est pas de la compétition mais de l'entraide. Je ne voulais pas te dire quoi faire juste faire attention à ne pas t'avoir donné de mauvais conseils Bref ça fonctionne comme tu le voulais et c'est le plus important

Donc lorsque tu appuies sur le bouton B2H ça fait : 1. Dans 1s exécute ON24_S1_C1() 2. Dans 5s exécute ON24_S1_C2() 3. Définit d'un timer de 30s pour les extinctions à exécuter par test1() et test2() 4. Dans 5s exécute test1() 5. Dans 10s exécute test2() 1. Pourquoi tu définis un timeout de 1s pour ON24_S1_C1() ? Je ne vois pas l'utilité car il ne se passe rien pendant cette seconde. 4. Pourquoi tu définis un timeout de 5s pour test1() ? Je ne vois pas l'utilité car tu veux décaler le deuxième OFF (donc test2) par rapport au premier, pas décaler le premier par rapport à rien. Après je me permets de te rappeler que même si je t'ai répondu pas mal de fois (et parfois beaucoup cherché) j'ai essayé de répondre à tes questions les unes après les autres pour te faire comprendre, pas à faire ton QA à ta place Désormais je trouve que tu enchaines beaucoup de timeout, avec des risques de décalage ou autres crash (notamment avec ton histoire de plusieurs OFF en même temps que ta clim n'aime pas). Sur le papier ça a l'air de fonctionner, mais dans la vraie vie avec des aléas, je ne suis pas sûr qu'il soit secure à toute épreuve. Je maintiens que je ferais autrement, par exemple (mais il faudrait y réfléchir plus longtemps) en ayant une seule boucle temporelle régulière façon intervalRunner, qui contrôle ce qui se passe et qui incrémente des variables lors des passages de la boucle, faire des comparaisons de ces variables, etc. Je pense que les timer seraient plus fiables, les fonctions moins nombreuses (ou pas) et la maintenance de ton code plus facile. Par contre niveau perf HW je ne peux pas te dire. Mais bon comme déjà dit, tu as ta première étape, et celle-ci terminée tu auras tout le temps de repartir d'une page blanche si tu en as le courage et l'envie

A la place de ça : decal1 = setTimeout(function() test2(self) end, 5000) tu dois pouvoir écrire ça : setTimeout(function() test2(self) end, 5000) Mais j'ai pris "la bonne ou mauvaise" habitude de toujours mettre le setTimeout dans une variable, ce qui permet de tester l'indexation de cette variable de sorte à pouvoir faire par exemple un clearTimeout si besoin...

J'ai fait une faute de frappe dans mon précédent message, il manque le "e" à setTimeout Et dis-donc, tu aurais pu le voir tout seul ça

Je pense avoir trouvé A la place de ça : Brillance = fibaro.getValue(Walli, "lastSetValue") Essaie avec ça : Brillance = api.get("/devices/"..Walli).properties.parameters[13].lastSetValue Mais en remplaçant le 13 par la réelle position de ton id:13 dans la liste de tes paramètres. Par exemple dans ta citation page précédente ça a l'air d'être le 1. Mais à toi de vérifier. Chez moi avec un Wall Plug ça marche. Et avec toujours Walli qui est une variable contenant ton ID du module.

Je pense que c'est ton "lastSetValue" qui ne va pas dans ton code : Brillance = fibaro.getValue(Walli, "lastSetValue") Dans la liste des properties que tu as partagée, c'est d'abord parameters qu'il faut atteindre, qui est une table. La table semble être indexée (le [ m'y fait penser), et pour chaque index tu as une nouvelle table. Et c'est là que je bloque. J'ai pensé : Brillance = fibaro.getValue(Walli, "parameters[13].lastSetValue") pensant que les paramètres seraient dans l'ordre, mais ça renvoie toujours nil. si tu laisses uniquement parameters pour vérifier ça renvoie une table, normal Au pire il faudrait faire une recherche de ton id13 dans la table parameters, mais je ne sais pas faire...

Non pas du tout car je n'ai pas installé GEA bien qu'il ait l'air puissant Au risque d'y passer énormément d'heures, comme tu l'as compris dans ce sujet depuis le début, apprenant étape par étape j'ai choisi de développer mon propre QA de gestion automatique des actions en partant de zéro, mais avec une maintenance que je maitrise car j'ai écrit le code (avec l'aide du forum). C'est long, c'est peut-être moins bien fait, moins puissant, mais il grossit, il s'améliore et j'apprends

#1. Ou alors tu lances tes 3 fonctions test1, test2, et test3 en décalage de 5s par exemple --2H function QuickApp:buttonClim2() self:debug("BOUTON 2H") duration = (value)*1000 test1(self) decal1 = setTimeout(function() test2(self) end, 5000) decal2 = setTimeout(function() test3(self) end, 10000) -- self:DH() self:updateView("etat", "text", "Dernière action >> 2 Heurs") end En déclarant tes variables decal1 et decal2 où tu veux comme tu veux. #2. Ou alors tu augmentes le timeout de tes OFF comme ça par exemple : timeoutClim2 = setTimeout(function() self:OFF_S1_C2() end, duration2+5000) Bref des idées il y en a plein

Tu n'aurais pas oublié les " " autour de lastSetValue par hasard ? Brillance = fibaro.getValue(Walli, lastSetValue) au lieu de : Brillance = fibaro.getValue(Walli, "lastSetValue") Et Walli correspond bien à une variable dans laquelle tu a indiqué précédemment l'ID de ton module ?

Un truc que je ne comprends pas, pourquoi as-tu mis le ON en commentaire ? ---self:ON24_S1_C1() Ton but n'étais pas d'allumer, puis d'éteindre X secondes plus tard ? Sinon pour ton debug, avec de petits extraits de codes, c'est compliqué de savoir te dire sans voir ce que tu as mis dans la fonction OFF_S1_C1() ou ailleurs. Au pire histoire de chercher à comprendre, remplace "function() self:OFF_S1_C1() end" par un banal print("toto"), et tu sauras si l'erreur vient bien du contenu de OFF_S1_C1()

L’ID de ton icône est 1006 il me semble

Histoire de garder le fil sans multiplier ni disperser les réponses : https://www.domotique-fibaro.fr/topic/15182-questions-de-débutant-en-quick-apps-sur-hc3/?do=findComment&comment=243036

C’est parce que event est une table, qui contient values qui est aussi une table. Le 1 est pour la première donnée à utiliser dans la table values. Enfin dans ton écriture tu remplaces event de mon explication par val… https://www.domotique-fibaro.fr/topic/15376-slider/?do=findComment&comment=243049

Tout à fait. C’est ce que j’ai voulu te montrer avec mon exemple toto pour une lecture plus facile de la mécanique du calcul. Tu voudrais modifier l’unité de valeur visuelle du slider dans l’IHM de ton QA ? Si c’est ça je ne sais pas si c’est faisable.

Là ce n'est pas compliqué si j'ai bien compris le sens de ta phrase. Petit exemple : local value local toto function QuickApp:onSliderChanged(event) value = event.values[1] self:debug("value", value) self:updateView("etat", "text" , "slider - " .. value .." W " ) toto = value * 2 print(toto) end