Fredmas

C'est bien ce que je pensais avoir compris jusque-là. Sauf que je n'avais pas encore compris que les variables des QA étaient en DB comme les VG. Même si une fois que cela est dit ça semble très logique C'est exactement aussi ce que je m'applique à coder. J'essaie autant que possible de vérifier une variable avant de la modifier pour rien. Je préfère lire et décider d'agir, que d'agir par défaut Je vais relire mon code, et probablement me forcer à le repenser autant que nécessaire, pour être sûr que ce que je garde en DB soit indispensable lors d'un redémarrage/plantage. Et passer le reste en variable dans le QA, que leur portée soit locale ou globale Je suis bien d'accord avec toi. Ce n'est pas tant l'optimisation de la vitesse que je recherche, mais plus l'optimisation du code, peu importe la puissance du hardware qui le supporte. En aparté, parlant de la philosophie d'optimisation du code pour un HW plus light, après avoir vécu des 25ans sous Windows à bidouiller des PC, c'est une des raisons (bonne ou mauvaise) qui m'a fait basculer sur MacBook il y a 2 ans. Un HW fait pour son SW. Et plus des HW surdimensionnés pour faire fonctionner un SW commun., même si évidemment tout n'est pas parfait chez Apple, surtout pour un ancien comme moi qui a grandi en assemblant ces ordinateurs et bidouillant Windows. Sans savoir pourquoi, je l'avais remarqué effectivement. Merci pour la précision. Thanks for your accurate technical addition. Due to that, as I said, even if I needed time to understand, I will try now to work in local way, out of DB as much as possible

OK, merci de m'avoir corrigé Effectivement je pense avoir fait un raccourci facile/tentant entre variable à portée globale et son stockage dans le contrôleur Fibaro. Du coup, d'un point de vue contrôleur Fibaro, l'utilisation de variables stockées de manière persistante dans le QA, bien en dur dans l'onglet variable, possède les mêmes désavantages que les VG (d'un point de vue mémoire et contrôleur) ? Je suis en train de supprimer mes VG, mais au final il faut que je fasse attention à ne pas les remplacer "cotes pour cotes" par des variables persistantes dans le QA, mais autant que possible en local dans le code, en tout cas à chaque fois que je n'ai pas besoin qu'elles soient persistantes ?

thank you for the demonstration @jang Unfortunately until now as I didn't investigate enough, Child in QA is close to be unknown for me. I will see later, even if I start to understand how it can be usefull for some application. But I will try to keep in mind you advise linn to:

Thanks @jang I thing I understood your main explanation. The main thing not cristal clear for me is this sentence below and risks. Probably because I am not using children yet... I am too young in QA

Le fait que je reformule n'est pas si mauvais, dans le sens où tu as certainement mis le doigt sur une belle incompréhension de ma part, puisqu'en écrivant ces mots, j'avais bien en tête globale et locale au sens variables LUA dans les scènes... Du coup je vais te relire et me relire pour vérifier ma compréhension... Merci beaucoup, car je n'avais effectivement pas entièrement compris à 100% Merci, car c'est effectivement une question qui me trotte dans la tête. Grâce à mes petits débuts en QA je suis en train de supprimer mes variables globales qui étaient utilisées dans les scènes. Mais du coup, que penser des variables non spécifiées "local" dans le code du QA, mais dans l'onglet "variable" du QA ? Si j'ai bien compris elles ne sont pas globales dans le sens LUA/Fibaro, mais d'un point de vue calcul et lenteur dans le QA comparé aux variables locales dans le code du QA ?

Pour le onInit et sa position dans le code, merci pour les réponses. J'ai pris pour habitude de faire comme la deuxième méthode décrite par @Lazer, mais je comprends complètement l'intérêt de : Mais du coup, tout en écoutant attentivement, je vous laisse débattre au coin du comptoir de l'historique du FORWARD Pas à propos de Pascal (@mprinfo) mais bien des origines du Pascal. Bon ok je sors...

Merci @Lazer ton explication est claire, et je comprends mieux les 2 écritures et leur utilité. Je vais relire mes codes en cours Du coup, pour vérifier si j'ai bien compris, j'ai pour habitude (et déformation professionnelle) de reformuler avec mes mots, et ça donne : - la première écriture est locale au QA concerné (tu as écrit globale dans ta phrase alors j'ai le doute), donc accessible uniquement dans le QA concerné et tous ses fichiers, mais pas en dehors de ce même QA. - la deuxième écriture est globale, donc utilise de la mémoire, mais la fonction est accessible en dehors du QA concerné si on l'appelle. Ai-je bon ? D'ailleurs, j'étais en train de réfléchir à justement écrire dans main tout ce qui concerne onInit, boutons, labels, boucles, etc., et créer un fichier pour ce que j'appelle le code fonctionnel, celui qui fait le boulot attendu Et ceci uniquement à fin de fluidifier la lecture du QA. Bonne ou mauvaise idée ?

#3 Question 3 : définir correctement une fonction comme membre du QA J'ai compris que pour qu'une fonction prenne des commandes self par exemple, et donc utilise les méthodes du QA, cette fonction doit être membre du QuickApp (ajoutée au QuickApp class). Cependant à la lecture des sujets et des manuels Fibaro, on constate plusieurs types d'écriture et manières de déclarer une fonction pour qu'elle soit membre du QA, en tout cas j'en ai retenu au moins 2. Après avoir réalisé quelques essais simples, les 2 manières décrites ci-dessous fonctionnent, donc j'imagine que la subtilité se situe peut-être davantage au niveau de certaines utilisations des paramètres et des arguments. Afin d'éclaircir les codeurs découvrant le monde des QA, quelqu'un saurait-il expliquer qu'elles sont les différences entre les 2 écritures suivantes Ecriture #1 function onInit() self:debug("onInit") test(self) end function test(self) self:debug("hello") end Ecriture #2 function onInit() self:debug("onInit") self:test() end function QuickApp:test() self:debug("hello") end p.s. : petit hors sujet, pourquoi dans la plupart des QA que nous trouvons, le onInit est très souvent rédigé à la fin du code ? J'ai plutôt tendance à l'écrire au début, est-ce une erreur ?

Yes I like it It was something like that about what I was thinking drinking my afternoon coffee But I am not sure that I would think so fast: 1. to move the call of intervalRunner() from onInit() to a QuickApp object like this button3(), called itself by onInit() 2. to define ref as a table and not a value in onInit() But reading your proposal I understand the good idea and how it works Much more simple and easier to maintain than my previous way to do with button, variable and return ":EXIT"

You are too strong and fast for me. Thanks I didn't think to put ref in onInit() Updating your proposal to my QA, like below it seems to work simply for me --to initialize the QA function QuickApp:onInit() self:debug("onInit") ref = intervalRunner(2, function() return mainCode(self) end) end --to stop the QA function QuickApp:button3() stopIntervalRunner(ref) end function stopIntervalRunner(ref) if ref[1] then clearTimeout(ref[1]) ref[1]=nil end end --to loop the main code of this QA function intervalRunner(seconds,fun) ... end --the main code to run from this QA function mainCode(self) print("Hereafter the main code to run") end

Thanks a lot @jang and @Lazer I understood and learnt a lot about starting with QA and about the way to loop Everything is now running properly in the loop, and I continue to code my main function in this QA instead of scenes. The only thing I didn't succeed to put in place is the function stopIntervalRunner. I didn't succeed to understand where and how to call it. I tryed to write this function like that: function stopIntervalRunner(ref) if ref[1] then clearTimeout(ref[1]) ref[1]=nil end end Then I tryed to call it from my main code (or somewhere else) for a test, but I didn't find how and what to put for calling stopIntevalRunner(ref). I understood that you said: "with the ref that intervalRunner returns". But I probably failed to catch the ref returned by intervalRunner() But anyway, at the end I put in place another solution with a simple button like below, in case I need to stop intervalRunner, and it works good: function QuickApp:button2() if self:getVariable("QAOnOff") == "on" then self:setVariable("QAOnOff", "off") self:updateView("button2", "text", "QA is OFF. Pusch to switch on") else self:setVariable("QAOnOff", "on") self:updateView("button2", "text", "QA is ON. Push to switch off") intervalRunner(60, function() return mainCode(self) end) end end It is not perfect because I wrote here again the same line intervalRunner(60, function() return mainCode(self) end), duplicated from onInit(). Not good when we want to change the value and for the maintenance, but I will probably never change it, or not so often And in the main code I put at the beginning: function mainCode(self) if self:getVariable("QAOnOff") == "off" then print("QA is off") return ":EXIT" end blablabla end Have a good day, Bonne journée, Fred

Et il a fallu que j’écrive cela pour que ça re-fonctionne aussitôt Fibar group sort de ce forum

Après quelques semaines d’essais sur des « petits » QA, je n’avais jamais rencontré ce problème Là je suis en train de finaliser mon premier vrai QA plus important, et bim même problème que vous, je ne vois plus le contenu du QA dans l’app de l’iPhone Redémarrage de la HC ne change rien. Je verrai si demain matin ça va mieux Et sans parler de l’impossibilité d’afficher des QA en favori sur la page d’accueil Meme si je suis bien d’accord avec @Lazer, le but n’est pas de l’ouvrir tous les jours mais que ça fonctionne tout seul tout le temps. Mais parfois on peut avoir besoin d’y accéder pour vérifier un truc.

sounds good but new for me, even if I already read weeks ago something about "unpack" here. But I will go step by step, as now I understood the way to code the previous version And I keep it in my notes for a next step

Perfect. I didn't think just to put "return" in the line in onInit Not so easy to learn from zero I understood and it works.

Maybe I was not enough clear Yes I put your proposal intervalRunner (10, function () checkVariables (self) end) in onInit() instead of intervalRunner (10, checkVariables(self)). And it works very well to be able to call in my code QA variable. But putting your proposal intervalRunner (10, function () checkVariables (self) end) in onInit() instead of intervalRunner (10, checkVariables(self)), make the ":EXIT" not running anymore. When I put return ":EXIT" at the end of my code, intervalRunner ignore and continue to run and never stop. It seems like if fun()==":EXIT" or ref[1]==nil then return end doens't find anymore the return ":EXIT" coming from my code when I put intervalRunner (10, function () checkVariables (self) end) in onInit() instead of intervalRunner (10, checkVariables(self))

yes it works! Thank you @jang for the explanation and the link. But in this case now, writting return":EXIT" at the end of checkVariables doesn't work anymore, so I tried to replace in function intervalRunner (seconds,fun): if fun()==":EXIT" by if function()fun(self)end==":EXIT" but it doesn't work if fun()==":EXIT" by if fun(self)==":EXIT" but it doesn't work if fun()==":EXIT" by if function()checkVariables(self)end==":EXIT" but it doesn't work if fun()==":EXIT" by if checkVariables(self)==":EXIT" but it doesn't work if fun()==":EXIT" by if checkVariables()==":EXIT" but it doesn't work

Hello, Tout fonctionne en boucle, sauf pour un point : l’utilisation de variables provenant du QA au lieu des VG Et oui l'étape suivante logique est que le QA soit autonome sans utiliser les Variables Globales J'ai réalisé beaucoup d'essai pour trouver la solution mais je n'y suis pas arrivé. Description : Si dans la fonction checkVariables() j'appelle une variable avec fibaro.getGlobalVariable("var") ça fonctionne. Si dans la fonction checkVariables() j'appelle une variable avec self:getVariable("var") ça ne boucle pas. Le print fonctionne une fois (normal la fonction est désormais appelée par le onInit), mais le print ne fonctionne plus ensuite. Une logique que j'aurais mal comprise ? Ci-dessous ça fonctionne. Je vois le print toutes les 10s. function QuickApp:onInit() self:debug("onInit") intervalRunner(10,checkVariables) end function checkVariables() print(fibaro.getGlobalVariable("variableVG")) -- hereafter the function I want to launch regularly thanks to the loop in the function IntervalRunner end function intervalRunner(seconds,fun) local nxt,ref=nil,{} local function loop() if fun()==':EXIT' or ref[1]==nil then return end nxt=nxt+seconds ref[1] = setTimeout(loop,1000*(nxt-os.time())) end local t = ((os.time()-3600) // seconds) * seconds nxt=t+seconds+3600 ref[1] = setTimeout(loop,1000*(nxt-os.time()-(seconds > 3600 and 3600 or 0))) return ref end Ci-dessous ça fonctionne. Je vois le print toutes les 10s. function QuickApp:onInit() self:debug("onInit") intervalRunner(10,checkVariables) checkVariables(self) end function checkVariables(self) print(fibaro.getGlobalVariable("variableVG")) -- hereafter the function I want to launch regularly thanks to the loop in the function IntervalRunner end function intervalRunner(seconds,fun) local nxt,ref=nil,{} local function loop() if fun()==':EXIT' or ref[1]==nil then return end nxt=nxt+seconds ref[1] = setTimeout(loop,1000*(nxt-os.time())) end local t = ((os.time()-3600) // seconds) * seconds nxt=t+seconds+3600 ref[1] = setTimeout(loop,1000*(nxt-os.time()-(seconds > 3600 and 3600 or 0))) return ref end Ci-dessous ça ne fonctionne pas. Je vois le print une fois, normal puisque onInit(). Et ensuite la boucle commence et s'arrête s'arrête dès qu'elle rencontre un self: comme par exemple print(self:getVariable("variableQA")) function QuickApp:onInit() self:debug("onInit") intervalRunner(10,checkVariables) checkVariables(self) end function checkVariables(self) print(self:getVariable("variableQA")) -- hereafter the function I want to launch regularly thanks to the loop in the function IntervalRunner end function intervalRunner(seconds,fun) local nxt,ref=nil,{} local function loop() if fun()==':EXIT' or ref[1]==nil then return end nxt=nxt+seconds ref[1] = setTimeout(loop,1000*(nxt-os.time())) end local t = ((os.time()-3600) // seconds) * seconds nxt=t+seconds+3600 ref[1] = setTimeout(loop,1000*(nxt-os.time()-(seconds > 3600 and 3600 or 0))) return ref end

No, no, no, absolutely not Just I like to understand what I do and most of all how it works, doing some test and not simply reuse a code given As I said I am a QA beginner, and I need to learn and understand to be autonomous later, sharing in same time with other beginners. It sounds good. I don't see a real issue not to start from 0:00 for big loop of hours but from 1:00, even if I understand the wish to start from midnight for some people. But it would be a pity. Your alignment proposal is a good waf idea Yes, perfect Thanks a lot for being patient and your explanation @jang

Thank you @jang #1: cristal clear #2: cristal clear #3: clear but: I understand your explanantion about the difference between expression and possibility to return a value But to be sure I understood the calculation inside, this means: - if seconds = 60 in onIntit() ==> ref [1] = setTimeout (loop, 1000 * (nxt-os.time () - 0) - if seconds = 3601 in onIntit() ==> ref [1] = setTimeout (loop, 1000 * (nxt-os.time () - 3600), and in this case sometimes the result of (nxt-os.time () - 3600) can be a negative number Am I correct? If yes, I don't understand the purpose to substract 3600 when seconds is more than 3600.

Thank you @jang I am still learning And there are some points I don't understand perfectly: #1 ref[1] = setTimeout(loop,1000*(nxt-os.time())) I understood that ref is a table, and now after some tests I am understanding that each time the operation after '=' is successfull, the table ref is incremented about 1 more. Am I correct about the way to work of this incrementation? It's what I see putting a print(ref[1]) and checking each loop the result in the console: 1, then 2, then 3, then 4, etc. #2 local t = ( os.time() // seconds) * seconds I understand the floor division. But what is the purpose to put it here and not simply using os.time() for next operation: nxt=nxt+os.time()? To be sure not to drift about some tenths of a second several times? #3 ref[1] = setTimeout(loop,1000*(nxt-os.time()-(seconds > 3600 and 3600 or 0))) I don't understand the syntax of the last part of this sentence: "(seconds > 3600 and 3600 or 0)". Is it a LUA optimization for the way to write something like "(if seconds > 3600 then 3600 else 0)"?

Bon ben version beta, je passe mon tour

#3 Javais bien prévenu que je préférais m'abstenir de trop m'avancer au risque de dire une bêtise

Bonjour @Penelope, Je ne connais pas cette gamme bticino, mais uand tu dis que tu possèdes des " interrupteurs bticino living now", ce sont juste les mécanismes ou également le reste de l'intallation bticino connectée ? Et ce sont des interrupteurs au sens propre du terme c'est à dire bistable, ou des poussoirs monostable ? J'ai vu que les 2 existent dans cette gamme. En attendant tes réponses, de manière plus générique voici ce que je peux te répondre avec mon petit niveau #1 "Puis-je installer un double switch pour contrôler 2 points lumineux différents ? Et puis-je installer 2 double switch dans le même boîtier pour contrôler 4 points lumineux différents ?" Selon moi tu peux installer (cas classique) un switch sur un circuit de lumière, qu'il possède un ou plusieurs point lumineux (par un exemple un couloir, un escalier, un pièce avec plusieurs plafonniers, etc.), ou alors directement sur un seul point lumineux spécifique de ce circuit, mais je ne vois pas trop l'intérêt. Oui un double switch possède 2 entrées et 2 sorties, donc tu peux piloter 2 circuits de lumière (peu importe le nombre de points lumineux dans le circuit), tant que tu respectes le courant admissible. Et installer 2 switch dans un boitier, disons que ça dépend la taille de ton boitier. Si c'est une boite d'encastrement classique pour 1 mécanisme, je n'y crois pas trop vu la difficulté a déjà rentrer un seul switch derrière un poussoir. Sinon il existe des boites qui "s'agrandissent" derrière la cloison par exemple. #2 "Dois-je installer un switch pour chaque point lumineux ou pour chaque interrupteur ?" Je ne maitrise pas la réalisation de ton installation électrique, et à voir si tu as vraiment des interrupteurs bistables et pas des poussoirs monostables. En attendant tes réponses, je vais prendre un exemple avec un circuit lumineux dans un séjour, avec 2 lustres (donc 2 points lumineux), et 2 boutons poussoirs monostables à chacune des portes de la pièce : tu as besoin d'un seul switch dans cet exemple. #3 "Si je souhaite installer des spots leds couleurs, dois-Je obligatoirement prendre un RGBW controller ?" Je n'ai encore jamais utilisé ce type de module FGRGBW-442, donc je préfère m'abstenir de trop supposer et dire des bêtises à la place de ceux qui savent. Mais je pense que si tu veux piloter la couleur, oui il te faut un module de ce type. #4 "Dois-je installer un module dimmer plutôt qu’un switch dans un interrupteur dimmable ?" Si ton besoin in fine est de dimmer ta lumière, oui. Un switch possède un relai, alors c'est binaire 1 ou 0. #5 "Pour les prises, est-ce préférable d’utiliser le wall plug ou un switch ?" J'ai déjà lu que certains étaient intéressés par ce type de montage de switch derrière une prise. Pas moi, car un switch supporte moins de courant qu'un wall plug, tu déplaces plus rapidement si besoin un wall plug qu'un switch encastré, et je trouve les wall plug très discrets une fois l'appareil électrique branché.

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