Proper and efficient use of timeouts

[dawiinci 5]

I saw that block scenes now use setTimeout functions. So obviously they are better and more efficient than just sleep. Can anyone explain how to change existing scenes which contain fibaro:sleep(10000) the right way?

[Dalle1985 16]

Are you sure that the setTimeout is actually a different way of doing timeouts than sleep? I doubt the function will actually release the memory from the scene, but I might be wrong, which would be great - but there is no such function in Lua itself, and I don't see anything in the fibaro API - but I might be wrong.

[petergebruers 1,268]

Are you sure that the setTimeout is actually a different way of doing timeouts than sleep? I doubt the function will actually release the memory from the scene, but I might be wrong, which would be great - but there is no such function in Lua itself, and I don't see anything in the fibaro API - but I might be wrong.

I've replaced 9 scenes that had an infinite loop and "sleep" statements, with equivalent "setTimeout" constructs. CPU dropped to +/- 5% from +/- 25%

With the limited knowledge I know have on this subject, I am tempted to say that there is no simple conversion from "sleep" to "setTimeout". Personally, I would not have called this function "setTimeout" but something like "scheduleFunction".

[j.nowacki 5]

Replacing sleep with timeouts requires deep changes to the scene. Sleep just freezes the scene in one place for a period of time, timeout is just "noticed" by scene and it goes on with executing next lines - the ones set in timeout will be executed after given time. Nice example was given here by a.socha

Please login or register to see this link.

As you can see the order of instructions in scene does not affect the order they are executed: only thing that matter is the time argument in setTimeout() function. This way the whole scene is executed at once and further actions are taken when they are set too. Meanwhile scenes with sleep and while true loops are always active.

[dawiinci 5]

So how would you change these two cases?

Please login or register to see this code.

Please login or register to see this code.

[j.nowacki 5]

Please login or register to see this code.

The first time the function will be called from the last line, and then it will repeat itself every 2s. 2nd example would be the same, but instead of printing the result, you would have an 'if' instruction.

[jgab 2,642]

Hi, I played around with setTimeout function and created a simple simulated lights function. The model becomes quite different from the traditional "sleep" version. (In more complex examples I guess one would like to have the opportunity to remove a scheduled call by using some kind of reference to it...)

Please login or register to see this code.

[dawiinci 5]

This doesn't work in virtual devices???

How do I change my loops in VD?

How do I replace fibaro:sleep() within a virtual device?

[jgab 2,642]

Nop, doesn't seem like setTimeout is available in VDs.

Btw, even though I think that the structure/logic actually is a bit simpler in this example than in the sleep version, stuff like saving the initial states and restoring them at the end is a bit trickier because it is difficult to know when the last scheduled turnoff is running in this case...

[ Added: 2015-01-12, 19:21 ]

I guess you don't replace them in a VD...?

[dawiinci 5]

Well I wanted to make the main loop a bit more efficient that just sleep.

Seems a bit half-baked that it only works in scenes.

[robmac 173]

Please login or register to see this code.

The first time the function will be called from the last line, and then it will repeat itself every 2s. 2nd example would be the same, but instead of printing the result, you would have an 'if' instruction.

With the greatest of respect we tested this and it is not good without the anonymous function as tested in hot fix thread. This syntax is bad.

[dawiinci 5]

What should I do?

[robmac 173]

What should I do?

Convert to plugin when full release comes

Please login or register to see this image.

/emoticons/default_icon_biggrin.gif" alt=":-D" />

If you are talking good syntax go and look in hot fix thread.

Testing with latest and greatest:

Please login or register to see this code.

This one actually takes 5 seconds before it iterates to next - that is success, however, just as robmac points out, I think it will fail....

The boxing in an anonymous call may work. Are you testing for overflow. Thanks bit busy myself.

He did and it is good!!!

Thanks to Bamsefar.

[jgab 2,642]

Please login or register to see this code.

The first time the function will be called from the last line, and then it will repeat itself every 2s. 2nd example would be the same, but instead of printing the result, you would have an 'if' instruction.

With the greatest of respect we tested this and it is not good without the anonymous function as tested in hot fix thread. This syntax is bad.

j.nowacki example works equally well. setTimeout wants a function (pointer) with 0 arguments as it's first argument. In Bamsefar's first attempt he passed a function call as the first argument instead of a function (pointer) which evaluated into an infinite recursion that ate all the calling stack before setTimeout manged to registered any call back at all...

See my earlier example of a light presence simulator that uses both models. The advantage with a anonymous function wrapper is that you can carry with you arguments in the resulting function closure.

The interesting thing with setTimeout is that we have a alarm/timer mechanism that now can contain state and can share state between handlers (something we couldn't do with scenes besides global variables). It is quite suitable for scheduling type of problems (see my earlier example again), and we need to figure out if we can find coding patterns for typical tasks (sensor turning on a light with a timer with overriding switch etc).

It would be cool if we could register event call-backs in the same way sharing (closures) states (would get rid of a lot of globals.)

[robmac 173]

Good spot I think I have to hold my hand up to the original. I wrote the example on the forum without thinking what it was trying to do.

Have you looked at plugins?

[Bamsefar 13]

setTimeout wants a function (pointer) with 0 arguments as it's first argument. In Bamsefar's first attempt he passed a function call as the first argument instead of a function (pointer) which evaluated into an infinite recursion that ate all the calling stack before setTimeout manged to registered any call back at all...

See my earlier example of a light presence simulator that uses both models. The advantage with a anonymous function wrapper is that you can carry with you arguments in the resulting function closure.

The interesting thing with setTimeout is that we have a alarm/timer mechanism that now can contain state and can share state between handlers (something we couldn't do with scenes besides global variables). It is quite suitable for scheduling type of problems (see my earlier example again), and we need to figure out if we can find coding patterns for typical tasks (sensor turning on a light with a timer with overriding switch etc).

It would be cool if we could register event call-backs in the same way sharing (closures) states (would get rid of a lot of globals.)

Where is this documented?

[robmac 173]

setTimeout wants a function (pointer) with 0 arguments as it's first argument. In Bamsefar's first attempt he passed a function call as the first argument instead of a function (pointer) which evaluated into an infinite recursion that ate all the calling stack before setTimeout manged to registered any call back at all...

See my earlier example of a light presence simulator that uses both models. The advantage with a anonymous function wrapper is that you can carry with you arguments in the resulting function closure.

The interesting thing with setTimeout is that we have a alarm/timer mechanism that now can contain state and can share state between handlers (something we couldn't do with scenes besides global variables). It is quite suitable for scheduling type of problems (see my earlier example again), and we need to figure out if we can find coding patterns for typical tasks (sensor turning on a light with a timer with overriding switch etc).

It would be cool if we could register event call-backs in the same way sharing (closures) states (would get rid of a lot of globals.)

Where is this documented?

Yes i missed that when the parameter was added it changed it

Interesting though

By using an anonymous function you managed to pass parameters which is a nice pattern.

[VladoV 0]

Use of setTimeout - on Fibaro HC3L 5.090, code edited with VS Code.

Because it is quite new for me, I have tested, how does the setTimeout work, here you have some examples.

Btw., answer to "overflow": Probably no overflow, because every next call of the same function kills the previous instance - so my experience.

 

--

-- setTimeout -> Wait in Queue and Call Asynchron - Anonymous(!) Function

--

local secs = 3

fibaro.setTimeout(secs*1000, function() print("Anonymous Function - Action 1 Time") end)

 

[09.12.2021] [13:24:00] [DEBUG] [TEST]: Scene Call
[09.12.2021] [13:24:03] [DEBUG] [TEST]: Anonymous Function - Action 1 Time

 

--

-- setTimeout -> Wait in Queue and Call the Function Asynchron

--

local secs = 3

local function call()

  print("Action 1 Time")

end

fibaro.setTimeout(secs*1000,call)

 

[09.12.2021] [13:27:00] [DEBUG] [TEST]: Scene Call

[09.12.2021] [13:27:03] [DEBUG] [TEST]: Action 1 Time

 

--

-- setTimeout -> Wait in Queue and Call Asynchron  +  R e c u r s i o n

--

local secs = 3 cycle = 2

local function loop()

  if cycle > 0 then

    print("Action and Repeat")

    cycle = cycle - 1

    fibaro.setTimeout(secs*1000,loop)

  else

    print("Action Last Time")

  end

end

fibaro.setTimeout(secs*1000,loop)

 

[09.12.2021] [13:28:00] [DEBUG] [TEST]: Scene Call

[09.12.2021][13:28:03] [DEBUG] [TEST]: Action and Repeat

[09.12.2021][13:28:06] [DEBUG] [TEST]: Action and Repeat

[09.12.2021][13:28:09] [DEBUG] [TEST]: Action Last Time

 

--

-- setTimeout -> Function with  P a r a m e t e r s  !!!

--

local sec1 = 5 sec2 = 3

local function sum1()    print("Function Uithout Parameters")                                   end

local function sum2(a,b) print("Function With Parameters "..a.." + "..b.." = "..tostring(a+b))  end

fibaro.setTimeout(sec1*1000,           sum1          ) --> example simple function call without parameters

fibaro.setTimeout(sec2*1000,function() sum2(40,2) end) --> example with function in anonymous function

                                                       --  => here you can pass parameters

 

[09.12.2021] [13:29:00] [DEBUG] [TEST]: Scene Call

[09.12.2021] [13:29:03] [DEBUG] [TEST]: Function With Parameters 40 + 2 = 42

[09.12.2021] [13:29:05] [DEBUG] [TEST]: Function Uithout Parameters

 

--

-- setTimeout -> Starts after(!) the Scene End

--

local secs = 3 wait = 5

local function call()

  print("Timeout Action")

end

fibaro.sleep(secs*1000,call)

fibaro.setTimeout(secs*1000,call)

print("Scene End")

 

[13.12.2021] [11:11:00] [DEBUG] [TEST]: Scene Call

[13.12.2021] [11:11:05] [DEBUG] [TEST]: Scene End

[13.12.2021] [11:11:08] [DEBUG] [TEST]: Timeout Action

 

Edited December 13, 2021 by VladoV

[jgab 2,642]

Unfortunately, setTimeout in QuickApps and Scenes behave differently

Scene:

Please login or register to see this code.

[09.12.2021] [14:00:04] [DEBUG] [SCENE74]: time 4

 

QuickApp:

Please login or register to see this code.

[09.12.2021] [14:00:04] [DEBUG] [SCENE74]: time 2

 

Hint: Scene's implementation is broken, busy code blocks the countdown of the timer.... same if one does a fibaro.sleep()...