Fredmas

Je crois que nous en parlons un peu à partir d'ici dans différents post : https://www.domotique-fibaro.fr/topic/15182-questions-de-débutant-en-quick-apps-sur-hc3/?do=findComment&comment=240845 Sinon pour essayer de te répondre, si dans onInit() : - tu déclares une variable locale, elle n'existera que dans la fonction onInit() - tu déclares une variable globale, sera disponible dans tout ton QA - tu déclares une variable self, elle sera un élément de la table du QA, utilisable également dans tout ton QA Mais c'est mieux expliqué dans le lien que je t'ai donné Contrairement au début, désormais j'utilise majoritairement des variables locales déclarées dans le code du QA, en dehors de onInit() autant que possible que j'essaie de considérer uniquement que comme une fonction (avec son contenu) lancée automatiquement après le load du code. Uniquement lorsque le besoin est réel, j'utilise une variable gobale ou self.

Yes something like that. I didn't think exactly in this way, but why not. Most of conditions are not a single one, but more linked to others. But anyway this is not the issue about the size of conditions. The purpose of this discussion was more to understand if the interest I imagined to separate the long list of several different conditions from the long list of several different actions, was a good idea (or not) from pure code point of view. As an example, to have a place to check easily all conditions to be checked regularly, and a place with different actions in different function to be called, to modify them easily without touching conditions code. From pure architecture point of view, in a general way. ok so maybe I am reinventing my own GEA step by step without knowing the content of GEA... But anyway I learn and become more and more autonomous But until now my period configured is 60s Here I understand the philosopy of working of your example, a little bit different from the idea I mentionned in the prior post (putting conditions in main, and just calling action functions). But the idea to separate conditions and actions in the code is the same. Maybe I missed something, but what is the advantage of writting the content you put in local rules table (condition='condition1',action='action1'), instead of listing this same content directly in the mainCode(self) without using a function ipairs? Thanks for the advise. I don't know. I don't care to do it as QuickApp methods (or not) if it is a better way to code and to work, I can But I feel it a little bit heavy... Each new step is pushing me to do in a different better way, and this is good But for this reason, I wonder why not put all conditions as a list in mainCode(), only calling QuickApp:function() for actions... (able to be called from another QA if needed). I need to think more about it to clean my mind

#6 Question 6 : respecter de bonnes pratiques d'architecture logicielle pour le code d'un QA C'est davantage un sujet de partage, et à la rigueur de café-philo me concernant, qu'une question répondant à un besoin à proprement parler. Mais maintenant que mes QA sont stables et continuent d'être modifiés et améliorés, je me pose la question d'une meilleure architecture du code et de comment mieux le structurer tant pour la performance que pour sa compréhension et sa maintenance. Le sujet est vaste, mais ici je vais rester sur l'exemple discuté depuis le début du topic (libre à chacun d'étendre cette réflexion à d'autres exemples), un QA qui tourne en boucle pour agir quand il y a besoin. Je passe donc sur les déclarations des variables, la fonction onInit() et autres fonctions qui permettent de gérer la boucle, les boutons et le QA dans son ensemble, pour me concentrer sur la principale. Dans ce QA j'ai donc créé une fonction principale qui est exécutée avec une période définie (sur la base intervalRunner de @jang), et cette fonction contient en enchaînement de toutes les conditions à vérifier et les actions à réaliser en fonction. La structure visuelle de cette fonction (et ses centaines de lignes) est principalement réalisée par des commentaires, aujourd'hui. Réfléchissant à ce sujet, je me dis : qu'au lieu de coder cette fonction principale comme ça : function mainCode(self) conditions1 actions1 conditions2 actions2 conditions3 actions3 etc. end je pourrais, je devrais, la coder de cette manière là : function mainCode(self) conditions1 self:actions1() conditions2 self:actions2() end function QuickApp:actions1() --"QuickApp definition" if need to be called from out end function QuickApp:actions2() --"QuickApp definition" if need to be called from out end Qu'en pensez-vous les experts du code LUA et des QA ? C'est une bonne idée ou il serait mieux de faire encore autrement en considérant "le monde merveilleux de l'asynchronisme" (comme dirait @Lazer). Mais je me dis que cette architecture serait peut-être plus fonctionnelle et plus lisible. La boucle mainCode() vérifierait uniquement les conditions, et appellerait d'autres fonctions qui elles contiendraient uniquement les actions à réaliser, et si besoin qui peuvent être disponibles pour être appelées par d'autres QA. Je me trompe peut-être complètement, je ne suis pas informaticien et encore moins ingénieur logiciel. Je me base sur ma propre compréhension qui évolue au fil du temps depuis que j'ai adopté les QA

Merci @Lazer pour ton explication et pour les liens que j'ai commencé à lire hier soir Thank you @jang for you complementary explanation

Et afin de compléter ma réponse, perso j'ai testé les 3 (je continue les tests). Mais peu importe le fournisseur, le résultat est le même, tu récupères les data dans ton QA via leur API, et dans ta Fibaro, Paramètres, Général, Capteurs Principaux tu changes le fournisseur Météo.

Oui tout à fait Avec un petit QA maison qui te permet de récupérer les API de différents fournisseurs tels que WeatherBit ou OpenWeather ou encore ConceptMeteo (pour ne citer que les 3 que j'ai essayés) : https://www.domotique-fibaro.fr/topic/15135-quick-app-météo-weatherbit-v12/ https://www.domotique-fibaro.fr/topic/15134-quick-app-prévisions-météo-weatherbit-v12/

J'adore, merci Mais de mon côté je fais ce que je peux pour apprendre et pour aider. @Lazer maitrise et répond du tac au tac Parce que même quand je ne sais pas faire, chercher pour aider quelqu'un me permet aussi d'apprendre, la meilleure preuve avec tes demandes dans ce topic Et si tu as appris c'est mission remplie. Parce que donner la solution appliquée sans apprendre c'est dommage selon moi Un lien qui me sert beaucoup pour lire, relire, lire, et relire, afin d'apprendre à coder en LUA. Si j'ai bien compris, que tu précises "index", "i", "key", "toto", ça revient au même pour appeler l'indexage numérique d'une table. Sauf que mettre _ semble faire pareil sans avoir besoin d'utiliser un caractère créant une variable. Mais là je te dis ce que je pense, je peux me tromper même si j'ai l'impression d'avoir compris.

En tout cas @triossrf tu as ta solution de recherche de paramètres maintenant

Oui merci pour la précision concernant l'horreur des boucles du premier essai. Maintenant que tu le dis je ne peux qu'être d'accord avec toi et il faut que j'essaie de prendre l'habitude de faire attention à cela. Je l'ai mis pour partager mon évolution de la journée entre les 2 solutions réfléchies, je n'aurais peut-être pas du poster la première m'ayant servie de brouillon pour la deuxième Du coup ma solution finale n'était pas si nulle alors en comparaison (me servant de ton indice donné) for i, parameters in ipairs(api.get("/devices/"..Walli).properties.parameters) do if parameters.id == 13 then Brillance = (api.get("/devices/"..Walli).properties.parameters[i].lastSetValue) print("La valeur est "..Brillance) end end for _, parameter in ipairs(api.get("/devices/"..Walli).properties.parameters) do if parameter.id == 13 then local Brillance = parameter.lastSetValue print("La valeur est "..Brillance) break -- pour sortir immédiatement de la boucle, inutile de continuer end end Merci pour la précision du _ que j'avais bien testé mais ton explication aide à comprendre le pourquoi du comment. Bien vu pour la différence d'écriture de la valeur dans la variable Brillance. A lire c'est logique, mais je n'y avais absolument pas pensé Pareil pour le break, absolument pas pensé. Comme quoi j'ai encore à apprendre En tout cas cet exercice du jour m'a permis de mieux appréhender la gestion des tables, et m'ouvre des possibilités à réfléchir dans mes QA existants... mais il me faut un peu de temps de digestion Merci pour la mise sur la piste sans avoir donné la réponse

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 

Salut @Lazer en me réveillant ce matin je me suis dit : allé je sais faire une boucle donc cherche un peu tu as le cerveau frais Alors j'ai testé cela et ça a fonctionné, mais avec un principal problème qui est de définir le 5 de la boucle car si on met un chiffre trop élevé évidemment ça plante puisqu'on indexe un i qui pour la recherche d'une valeur qui n'existe pas dans la table, et pas assez élevé ça ne couvre pas toute la table. Et compter à la main combien de paramètres existent tu m'as compris. Voir ci-dessous : local Walli = 85 -- ici ID du module concerné de triossrf local Brillance -- la variable de triossrf local data = {} for i = 1,5 do data[i] = {} local m,rechercheId = data[i],nil m.rechercheId = api.get("/devices/"..Walli).properties.parameters[i].id if m.rechercheId == 10 then Brillance = api.get("/devices/"..Walli).properties.parameters[i].lastSetValue print(Brillance) end end J'ai vaqué à mes occupations le reste de la journée, puis je m'y suis remis ce soir en regardant ton idée de ipairs que je n'avais encore jamais testé, sachant que la solution devait être vers là, . Et voilà ce que ça donne après quelques tests : le code ci-dessous qui fonctionne très bien chez moi : local Walli = 85 -- ici ID du module concerné de triossrf local Brillance -- la variable de triossrf for i, parameters in ipairs(api.get("/devices/"..Walli).properties.parameters) do if parameters.id == 13 then Brillance = (api.get("/devices/"..Walli).properties.parameters[i].lastSetValue) print("La valeur est "..Brillance) end end J'ai remplacé ton _ par i mais uniquement pour ma compréhension. Car j'ai essayé et les 2 fonctionnent, mais il y a peut-être une subtilité avec le _ que je ne connais pas. Sois indulgent c'est mon premier ipairs, mais n'hésite pas à me dire si je n'ai pas trouvé la bonne solution ou si on peut mieux faire

Je pense que @971jmd voulait parler d'un api.put pour modifier un paramètre, à la place d'un api.get pour lire un paramètre Mais il faut qu'il confirme sa question dans le doute.

Et apparemment ce que je viens de dire est vrai pour " https://api.weatherbit.io/v2.0/current? " qui a ce problème de décalage horaire. Mais avec " https://api.weatherbit.io/v2.0/forecast/daily?" ça semble ok

De mon côté, en commençant d'abord en m'inspirant du travail de @couillerot ici et là, j'ai créé un QA WeatherBit, puis un QA OpenWeather histoire de comparer les résultats, bug et crash. J'ai également essayé avec ConceptMeteo, mais ça c'est un autre sujet Concernant WeatherBit, il y a un soucis dont personne ne parle, alors je me demande si vous le rencontrez également avec les VD sur HC2. Mode citation : En travaillant sur mes différents codes QA gestion météo aujourd'hui, je viens de me rendre compte d'un problème avec WeatherBit : le temps (au sens horaire) n'est pas bon. Il est à UTC+0, et pas UTC+1. Ca se confirme avec différents appels JSON : json.decode(response.data).data[1].ob_time json.decode(response.data).data[1].datetime json.decode(response.data).data[1].sunrise json.decode(response.data).data[1].sunset Et pourtant quand on vérifie le : json.decode(response.data).data[1].timezone Ca donne bien comme réponse : "Europe/Paris" Alors ce n'est pas que c'est très grave, mais si on veut utiliser des data timing comme lever/coucher soleil par exemple, ça peut être par principe problématique Vous constatez le même décalage horaire ? EDIT : Et apparemment ce que je viens de dire est vrai pour " https://api.weatherbit.io/v2.0/current? " qui a ce problème de décalage horaire. Mais avec " https://api.weatherbit.io/v2.0/forecast/daily?" ça semble ok

Ben disons que quitte à récupérer des infos météo d'un fournisseur reconnu, j'utilise également ces infos timing à la place de celles fournies par Fibaro. Du coup avec WeatherBit je trouve ce décalage, mais pas avec Openweather. Je ne sais pas comment corriger. J'ai bien pensé à truquer leur horaire, bien qu'il soit fourni en string, donc plus compliqué que si c'était un number, mais il y aura toujours une difficulté aux alentours de minuit. Mais bon, comme cet horaire on s'en fiche je pense qu'on peut contourner en faisant l'impasse. J'ai pensé à changer le fuseau en faisant croire que j'habite dans un autre pays, mais bon, ce n'est pas très classe... Je me dis qu'il doit y avoir une autre correction possible vu la taille internationale de ce fournisseur... Le plus surprenant c'est que la zone géographique est la bonne...

Hello, En travaillant sur mes différents codes QA gestion météo aujourd'hui, je viens de me rendre compte d'un problème avec WeatherBit : le temps (au sens horaire) n'est pas bon. Il est à UTC+0, et pas UTC+1. Ca se confirme avec différents appels JSON : json.decode(response.data).data[1].ob_time json.decode(response.data).data[1].datetime json.decode(response.data).data[1].sunrise json.decode(response.data).data[1].sunset Et pourtant quand on vérifie le : json.decode(response.data).data[1].timezone Ca donne bien comme réponse : "Europe/Paris" Alors ce n'est pas que c'est très grave, mais si on veut utiliser des data timing comme lever/coucher soleil par exemple, ça peut être par principe problématique @couillerot ou ceux qui utilisent WeatherBit, vous constatez le même décalage horaire ?

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 

Bon ben comme d'hab en domotique, on commence par un projet simple (un trou), et plus on avance plus le projet grossit (crocodile, nourriture, entretien, recyclage pour fertilisation, surveillance, etc.)

Thanks For this reason sometimes it takes time to understand the way to work of our Fibaro, and succeed doing something

Oui effectivement j'utilise bien le string également, mais je n'ai jamais compris pourquoi il fallait le faire. Car un truc m'interpelle concernant cette idée de passer la valeur en "string". 1. Quand on regarde API/JSON du slider (oui je sais je fais le malin alors que j'ai découvert cette outil hier ) sa valeur n'a pas de " " comme pour les string, et ressemble donc à un number. Où alors je me trompe et ne regarde pas au bon endroit. 2. Quand on fait un self:debug(type(event.values[1])) la console affiche : number. Donc cela voudrait confirmer que le slider renvoie bien un number et pas un string. Du coup ces 2 points réunis me font dire que lorsqu'on souhaite dans l'autre sens envoyer une valeur à ce slider pour en modifier sa position, ce devrait être un number logiquement non ? Ou un truc m'échappe dans l'analyse ?

Au moins tu auras essayé

tu lis dans mes pensées. Mais j’hésitais à y mettre le feu automatiquement !

Hello @jjacques68, Comment vieillissent tes FGMS à l’extérieur depuis bientôt 5 ans ?

Bon j’ai attendu 3 ans et 9 mois pour me décider à changer la porte de la boîte aux lettres par une neuve toute belle. Maintenant je dois installer un piège avec un trou d’au moins 3m de profondeur pour ceux qui voudraient s’en approcher. Seul problème : domotiser le piège pour que le facteur ne tombe pas dedans

Crotte de bique. Je commençais à réfléchir à mettre un module Fibaro pour couper la mienne en fonction d’une mesure d’humidité avec un autre module Aeotec…