setTimeout possibly causes LUA environments to die

[robmac 173]

Hi all developers and @fibaro,

 

I think there might be an issue with setTimeout. If you get random scene stopping and use this call I suggest you try removing it.

 

I have tried to use it in the past in scenes and always suspected an issue with long running scene dying at random times a while after it was called one or more times. Remove the calls to setTimeout and normal service resumes with scenes running for months without issue.

 

Not sure if the setTimeout in scenes shares the same code with plugins but now I am working on plugins I am seeing the same issue. I have the debugger running and I have seen a fault that I think occurs only after this function was called. Also close of the plugin after a time left working. I can not be sure but this does seem to be the puppy by the pile of ****.

 

As most of the fibaro plugins use this call to remake closed net connections this may also cause unreliability of fibaro plugins with them dying at random times.

 

As I do not have all of the source, I cannot dig  deeper and have not wasted too much time looking through logs as I think I can avoid use of the function.

 

If you are a scene developer and get random stops of scenes that should run for a long time or a plugin developer and get random stops of your plugin, I would suggest you look at any call to setTimeout.

 

Would love to have your test results and if @fibaro plugin developers could have a look it might explain the unreliability of some of the fibaro plugins.

 

Cheers,

 

Robert

 

 

[petergebruers 1,268]

Did you "see" the script die or was there no trace? No error message?

 

I have a long running script based on setTimeout that starts at boot and never fails... I have several scripts that loop while a light is on, also based on setTimeout. Never fails.

 

In another script, I protect the scheduler by pcall:

 

Please login or register to see this code.

If I do not need long running scripts, I avoid them.

 

Might the issue be related to this:

 

Please login or register to see this link.

 

We have different environments, different results?

[15green 0]

Could this be the cause of the many problems with my motion scenes that I have asked for help for on here? Since upgrade to 4.130 the scenes appear to work for a few hours then nothing happens.   I get no errors just lights fail to turn off.

I have tried various different tweaks but all centered around the basic code as shown below.  Unfortunately I am no LUA expert so rely on the block scene conversion which always seems to have SetTimeout in it somewhere since 4.130.  

Two weeks later I still have a house of lights that stay on all the time!

 

--[[
%% autostart
%% properties
43 value
%% globals
--]]
fibaro:debug ('here')
setTimeout(function()
local delayedCheck0 = false;
local tempDeviceState0, deviceLastModification0 = fibaro:get(43, "value");
if (( tonumber(fibaro:getValue(43, "value")) == 0 ) and (os.time() - deviceLastModification0) >= 1200) then
 delayedCheck0 = true;
end

local startSource = fibaro:getSourceTrigger();
if (
 ( delayedCheck0 == true)
or
startSource["type"] == "other"
)
    then
  fibaro:call(54, "turnOff");
    end
end, 1200000)

 

   

[petergebruers 1,268]

7 minutes ago, 15green said:

Could this be the cause of the many problems with my motion scenes that I have asked for help for on here? Since upgrade to 4.130 the scenes appear to work for a few hours then nothing happens.   I get no errors just lights fail to turn off. (...)

 

I doubt that your problem is caused by setTimeout alone, there has to be something else... 

 

 My motion scenes contain setTimeout and they do not fail. Here is a code snippet of one of my scenes:

 

Please login or register to see this code.

 

[15green 0]

Hi @petergebruers does the snippet above work that each activation of the sensor keeps resetting a "waiting" time of 5000 seconds, only after which time something is performed as per procesNoMotion elsewhere in the scene? 

[petergebruers 1,268]

Almost. It loops for as long as the motion sensor stays breached. It is not about activation. This loops starts if certain conditions are true and I do not post them here because they will make the code difficult to read. There are two motion sensors involved and some switches. But that is not relevant to the "setTimeout discussion".

 

I have a certain motion sensor set to not report "safe" until 6 minutes without motion have passed. If the sensor detects motion during that window, it resets that window. It does not report breached and it does not report safe either, because of this 6 minute timer. When I am in the kitchen (and I am not completely motionless) this sensor will detect some motion within that 6 minute interval. This means, if I am in the kitchen for 2 hours that code snippet keeps looping for two hours too. Only when I leave the room, after 6 minutes the sensor reports "safe" (zero) and that piece of code stops looping.

 

Does this help?

[robmac 173]

I think to be more specific with scenes it is those that destroy LUA  state while set timeout is active.  Peter's does not destroy itself while setTimeout is active. 

 

Used to be simple to cause bad behaviour but have not tested for a while. Try killing a scene when there is a active timer. Used to cause a bit of an issue.

 

In the plugin I do not fully understand the lifecycle of the issue and I did not say it was with setTimeout definitely  but I suspected it is.

 

Might be as simple as calling a function that is fundamentally changed before the timeout occurs.

 

For example calling connect on a connection that has changed in some fundemental way between the initiation of the timer and the callback. Possibly an invalidated reference in underlying c code.

[15green 0]

Yes @petergebruers I am slowly understanding how Lua works, but unfortunately the powerful flexibility that it provides is also its downfall for newbies like me - because it opens up literally dozens of different ways of doing the same thing, and everyone has their own methods.

 

All this wouldn't matter of course if the block scenes worked as you would expect, but in my experience they rarely do!