jang

Add to this that the QuickApp: setVariable (name, value) looks something like this: (Similar search for QuickApp: getVariable) So, the quickAppVariables are stored in a linear list and the time to retrieve / store a variable depends on where in the list it is I don't understand why they didn't use a hash table (!) I hope that fibaro global variables are stored / retrieved more efficiently.

Yes, but your example is only globally declared functions. We were talking about "forward declaring" local functions. This don't work function QuickApp:onInit() f1("toto"); end function f1(a) return f2(a); end -- f1 local function f2(a) print(a); end This do function QuickApp:onInit() f1("toto"); end local f2 function f1(a) return f2(a); end -- f1 function f2(a) print(a); end

Yes, for QuickAppChildren you first need a male QA and a female QA...

local n = 10000000 -- loop 10 million times... local a = 1 -- our local variable b = 1 -- our global variable local t0 = os.clock() for i=1,n do a=a+1 end local t1 = os.clock()-t0 local t2 = os.clock() for i=1,n do b=b+1 end local t3 = os.clock()-t2 print("Local assignment ",n," times = ",t1,"s") print("Global assignment ",n," times = ",t3,"s") print("You saved ",t3-t1," seconds of your life") [25.07.2021] [14:23:34] [DEBUG] [QUICKAPP400]: Local assignment 10000000 times = 0.579324 s [25.07.2021] [14:23:34] [DEBUG] [QUICKAPP400]: Global assignment 10000000 times = 2.69236 s [25.07.2021] [14:23:34] [DEBUG] [QUICKAPP400]: You saved 2.113036 seconds of your life The HC3 is (or rather Lua is) quite fast.

QuickApp:onInit() is run after the whole file is loaded so it can be anywhere. Fibaro does something like... loadFile("QA file") -- Everything in the file is run - all functions and globals are defined (also locals on "top level"). local self = QuickApp() -- Now all methods are defined, create an instance if self.onInit() then self:onInit() end -- If the user declared an :onInit call it quickApp = qa -- Set the globaö 'quickApp' to the current QuickApp self. So :onInit() is called when everything is defined. Also note that Fibaro sets the global 'quickApp' to self after :onInit() is done. This means that we can use quickApp instead of passing around self to local functions if we are careful. It may not work if we deal with QuickAppChild instances as we then have many instances of "QuickApp" that we pass around... And yes, we need to "forward" declare local variables sometimes. This doesn't work local function bar(x) if x > 0 then foo(x-1) else print('done') end local function foo(x) bar(x-1) end foo(5) This work local foo local function bar(x) if x > 0 then foo(x-1) else print('done') end function foo(x) bar(x-1) end foo(5) The reason is that when bar is defined/compiled, 'foo' is assumed to be a global variable as it has not been mentioned/seen earlier. In the second example 'foo' is recognized as a local variable (even if it at the moment doesn't have a value)

You could make the button toggle intervalRunner --to initialize the QA function QuickApp:onInit() self:debug("onInit") ref={} -- Start running self:button3() end --to toggle running the QA function QuickApp:button3() if ref[1] then -- Running stopIntervalRunner(ref) self:updateView("<button3 id>","text","Halted") else ref = intervalRunner(2, function() return mainCode(self) end) self:updateView("<button3 id>","text","Running") end end "<button3 id>" should be the id of the button.

function intervalRunner(seconds,fun,...) local args,nxt,ref={...},nil,{} local function loop() if fun(table.unpack(args))==':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 function stopIntervalRunner(ref) if ref[1] then clearTimeout(ref[1]) ref[1]=nil end end function QuickApp:onInit() local ref,i=nil,0 ref = intervalRunner(2,function() i=i+1 print(i) if i == 5 then stopIntervalRunner(ref) end end) end

We could do intervalRunner a little better function intervalRunner(seconds,fun,...) local args,nxt,ref={...},nil,{} local function loop() if fun(table.unpack(args))==':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 Then we can do intervalRunner (10, checkVariables, self)

Sorry, my bad. Solution is intervalRunner (10, function () return checkVariables (self) end)

No no no, the solution is to do this in your code intervalRunner (10, function () checkVariables (self) end) intervalRunner shouldn't care what function it is given or if it needs self or not. No need to change intervalRunner.

Yes, because the checkVariables needs 'self' that's not available when called from intervalRunner - so it crashes (silently) Solution: intervalRunner ( 10 , function() checkVariables(self) end) That setTimeout crashes silently when the function crash is really a problem and makes many errors go undetected. You can add my fibaroExtra.lua files to your QA and you will see that you get an error when the checkVariables try to call self:getVariable (it also protects success/error handlers net.HTTPClient() )

Now you are starting to put pressure on me Well it turns out that print(os.date("%c",0)) >Thu Jan 1 01:00:00 1970 So it starts to count at 1 o'clock Jan 1 1970, not at 0 o'clock (midnight). This means that my alignment calculation becomes 1 hour off when we align for time >= 1 hour. My "hack" to subtract of 1 hour makes it work for time of 0-3600 seconds but not for 2 hours. After some thinking this is more correct and allow it to align up to better for hours. 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 -- remove 1 hour from epoch 0 for align calc nxt=t+seconds+3600 -- add back to start time ref[1] = setTimeout(loop,1000*(nxt-os.time())) return ref end However, alignment is a tricky concept for time - when we have intervals of hours we maybe would like to align it from midnight. If we do intervalRunner(2*3600,fun) it won't align on even hours which may be what we had expected. It can become 3,5,7,... (reason being, I guess, leap years that don't make hours always align from midnight) We can also skip the whole alignment and simplify the code function intervalRunner(seconds,fun) local nxt,ref=os.time(),{} local function loop() if fun()==':EXIT' or ref[1]==nil then return end nxt=nxt+seconds ref[1] = setTimeout(loop,1000*(nxt-os.time())) return ref end return loop() end ..it will still be drift free.

setTimeout() returns a reference that can be used to cancel the timer with clearTimeout(ref) The reference happens to look like an incrementing number but it's internal to setTimeout. intervalRunner needs to return a reference so that we can stop it with stopIntervalRunner(ref). We can't return setInterval's reference directly as we generate a new reference each loop when we call setTimeout. Instead we return a table with one position where we store the last reference from setTimeout. Each loop in intervalRunner updates the table with the new reference from setTimeout. If (and when) we call stopIntervalRunner(ref), ref will be the table and it will contain the last setTimeout reference. That reference we can then use to cancel the ongoing setTimeout call with clearTimeout(ref[1]) It's so that the time interval should start on even intervals - 60 it starts on even minutes, 15 it starts on even 15s (00:15,00:30 etc), 3600 it starts on even hours. The drift is taken care of with the statement setTimeout ( loop , 1000 * ( nxt - os . time ())) Yes, but it's an expression so it returns a value. if-then-else is a statement and doesn't return a value. We can't do local b = 100 * (if a == 1 then return 9 else return 10 end) but it would have been nice

"There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

Ok, you seems to have it covered. Fingers crossed Btw, you could add some counters for cache hits and misses - nice stats to see.