Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 0

Door Open Lights On - Delayed


Question

Guest puma
Posted (edited)

Hi I have a scene that i have created that when one of my garage doors opens it turns the lights on. The issue that I have with it is there is a big delay about 30 secs before it will turn the lights on.

 

The door controller is an Aeotec Garage Door Controller. Is there something that I can change to make it quicker?

 

Thanks

Please login or register to see this code.

 

Edited by puma

19 answers to this question

Recommended Posts

  • 0
Posted
4 hours ago, puma said:

Hi I have a scene that i have created that when one of my garage doors opens it turns the lights on. The issue that I have with it is there is a big delay about 30 secs before it will turn the lights on.

 

The door controller is an Aeotec Garage Door Controller. Is there something that I can change to make it quicker?

 

Thanks

Please login or register to see this code.

 

 

(c) @petergebruers

 

Quote

HC2 version 4 has a new primitive for timing: setTimeout() with arguments "function" and "time in ms". 
I's available in scenes, but it's not in Virtual Devices. Here's an example, starting from a script based on sleep:
ID=207

fibaro:sleep(1000)

fibaro:call(ID, "turnOn")

fibaro:sleep(2000)

fibaro:call(ID, "turnOff")

The semantics of "setTimeout" are different. It means "Schedule this function to run after this time interval has elapsed".
So the first argument is a function. Defining a function is easy: wrap the actual command you want to run in "function() .. end".
In the next script I've put the on/off code in functions, and scheduled them... but there are two pitfalls. 
One: don't use () after the first argument (that would make it a "function call" instead of a function). 
Two: because the timers in this script start at the same time, the second timer has to be 1000 + 2000 = 3000 to be equivalent to the first example.
ID=207

function lightOn()
  fibaro:call(ID, "turnOn")
end

function lightOff()
  fibaro:call(ID, "turnOff")
end

setTimeout(lightOn, 1000)

setTimeout(lightOff, 3000)

There's something important here and it's easy to miss. You see in setTimeout we refer to "lightOn". You 
think that is a function call? Sure? It isn't: it's a variable bound to a function, not a function *call*. 
A function *call* would be like this: "lightOn()". If you put the "()" like you are used to do... the script won't work. 
When the script arrives at the setTimeout call, it immediately executes the function call. So add "()" to lightOn and the light will switch on immediately, instead of after a 1 second delay. 
And after one second, you get a mysterious "LUA error: attempt to call a nil value". That's setTimeout barking at you: "Hey, where's the function you want me to call after time out?". 
Please note that if you can't use "()" then you also can't have parameters. So "lightOn(ID)" isn't going to work either. I'll write about that later.
Maybe you don't like the idea of the two functions being scheduled at the same time, maybe you want to see the second timer at "2000" in your script. 
Then you can refactor it like this. The first timer is OK. But the second timer should start in the function of the first timer, so they are "chained". 
When I do this, I change the name of the first function from lightOn to lightOnOff because that is what it will do. 
Then at the end of it, I put the second setTimeout, that was at the bottom, and change the time to 2000. Like this:
ID=207

function lightOnOff()
  fibaro:call(ID, "turnOn")
  setTimeout(lightOff, 2000)
end

function lightOff()
  fibaro:call(ID, "turnOff")
end

setTimeout(lightOnOff, 1000)
Lua supports anonymous functions, and that can make a good solution for simple things... 
But I think this often gets hard to read. I put this example in anonymous form. And I payed attention to the indentation. 
But you still have to go through the text a few times to decode the pieces. On the other hand, it's valid and concise.

setTimeout(
  function() 
    fibaro:call(ID, "turnOn")
    setTimeout(
      function()
        fibaro:call(ID, "turnOff")
      end
      , 2000)
  end
  , 1000)

But don't give up on this anonymous-function-thing. You'll need it if you want to use parameters with setTimeout. 
Remember I said you cant put parenthesis after the function name in setTimeout? 
I'll offer two solutions to work around this. First, you can wrap the function in "function()" 
<CODE HERE> "end". That defines an anonymous function, which contains the statements and the parameters you want:
my_ID=207

function lightOnOff(id)
  fibaro:call(id, "turnOn")
  setTimeout(function() lightOff(my_ID) end, 2000)
end

function lightOff(id)
  fibaro:call(id, "turnOff")
end

setTimeout(function() lightOnOff(my_ID) end, 1000)
The second solution is the real "functional programming" stuff. 
Can you design a function, that *makes* a function for you that does the right thing and can be called from setTimeout? 
That's what's happening here. Functions are "first class citizens" and can be passed around and can be used as variables. 
This is the same example, but this time the argument for setTimeout is created inside a function, makeLightOnOff(id). 
This works because, well, if you're not used to functional programming, this might blow your head off, functions in lua are "closures". 
That means, they capture the local variables from the context *outside* the function (I'm talking about "id").
my_ID = 207


function makeLightOnOff(id)
  return function()
    fibaro:call(id, "turnOn")
    setTimeout(
      function()
        fibaro:call(id, "turnOff")
      end,
      2000)
  end
end

my_on_off=makeLightOnOff(my_ID)
setTimeout(my_on_off, 1000)

================================================


The "Lua idiom" to setup a non-drift setTimeout loop is

Ex. a 60s loop

local time = os.time()
local  function loop()
     doWork() --- call function or do whatever needs to be done each loop
     time = time + 60 -- calculate next time we should be called
     setTimeout(loop,1000*(time-os.time())) -- subtract current time from wanted time
end
loop()
In this case, if 'doWork()' takes a millisecond or 30s it doesn't matter. The loop will run every 60s.

However, when in the minute doWork is called depends on when the loop is started. If it is started 10:05:26 it will loop 

10:05:26, 10:06:26, 10:07:26, 10:08:26 ...

 

This is easy to extend to make it run starting on the minute (works for hour too)

E.g. looping 10:06:00, 10:07:00, 10:08:00, 10:09:00 ...

  local interval = 60
  local time = os.time()
  local function loop()
    doWork()
    time = time + interval
    setTimeout(loop,1000*(time-os.time()))
  end
  time = math.floor(time/interval)*interval+interval
  setTimeout(loop,1000*(time-os.time()))
and then the pattern can be captured in a function

function loop(fun,interval,startOnInterval)
  local time = os.time()
  local function doLoop()
    fun()
    time = time + interval
    setTimeout(doLoop,1000*(time-os.time()))
  end
  if startOnInterval then 
    time = math.floor(time/interval)*interval+interval 
    setTimeout(doLoop,1000*(time-os.time()))
  else
    doLoop()
  end
end

loop(doWork,60,true) -- run doWork() every 60s starting on the next minute.
 

 

  • 0
Guest puma
  • Inquirer
  • Posted

    Thanks for the reply however I'm not sure if thats the answer. Well I don't entirely understand all of that as its a little advanced for me however I think it has something to do with the reporting from my aeotec garage door opener to say  that the door is open.

     

    When the light triggers it does as it should it's just really delayed compared to say my other zwave door sensors if I open on of them they turn the lights on instantly.

    • 0
    Posted

    Maybe first look in your history screen to see how fast your switch and your light responses. 

    • 0
    Guest puma
  • Inquirer
  • Posted
    On 8/8/2020 at 9:27 PM, SmartHomeEddy said:

    Maybe first look in your history screen to see how fast your switch and your light responses. 

     

    Sorry how to I find that info I can't seem to find what you are talking about.

    • 0
    Posted

    Sorry, on the HC2 it is called “event panel”

     

     

    Please login or register to see this attachment.

    • 0
    Posted

    I would say, check the webinterfact of the fibaro app.

    If you open the door, does the device status change  immediately?

     

    • 0
    Guest puma
  • Inquirer
  • Posted
    4 hours ago, SmartHomeEddy said:

    Sorry, on the HC2 it is called “event panel”

     

     

     

    Oh yes I did find that however it only shows sensors not devices. So just temp, voltage and the like.

     

     

    1 hour ago, akatar said:

    I would say, check the webinterfact of the fibaro app.

    If you open the door, does the device status change  immediately?

     

     

    Yes it does act pretty quickly but because it is like a progression thing as soon as I click the button to open it changes state from closed to opening then to open. Once it is opened I'd say I have to wait 20-30 seconds for it to trigger the lights.

    • 0
    Posted

    @puma

    Try this thing, make a block scene: if sensor breach then turn on lights

     

    if this works instantly then we know that communication from the sensor and to the lights are good.

    And then you know that it's something in the code that makes it slow.

    • 0
    Guest puma
  • Inquirer
  • Posted
    20 hours ago, akatar said:

    @puma

    Try this thing, make a block scene: if sensor breach then turn on lights

     

    if this works instantly then we know that communication from the sensor and to the lights are good.

    And then you know that it's something in the code that makes it slow.

     

    I tried to do that however the garage door controllers don't show up as a device. 

     

    For some reason I can only use them in a magic scene or a lua scene

    • 0
    Posted

    @puma

    Last thing you can try, make the lua scene as simple as possible

    so just

    if breach, turn light on

     

    if it's still not working as it should contact fibaro support, they can login and see what is going wrong.

     

    • 0
    Guest puma
  • Inquirer
  • Posted
    On 8/11/2020 at 6:20 PM, akatar said:

    @puma

    Last thing you can try, make the lua scene as simple as possible

    so just

    if breach, turn light on

     

    if it's still not working as it should contact fibaro support, they can login and see what is going wrong.

     

     

    No worries thanks I might have to do that I think that maybe my issue is with how quickly it reports to fibaro when it is open.

    • 0
    Posted

    @puma

    If it reports (changes) directly in the webinterface then something else is the problem.

     

    • 0
    Posted (edited)

    I would experiment with a simple script like:

     

    Please login or register to see this code.


    (I don’t use a HC2, so I don’t know if this should work)

     

     

    Edited by SmartHomeEddy
    • 0
    Guest puma
  • Inquirer
  • Posted

    @SmartHomeEddy your code doesn't work I don't have an option for value.

     

    The way I look at it when I go into writing the lua code I can't only choose what I find in the right hand list for the devices. Is this correct?

     

    Please login or register to see this image.

    /monthly_2020_08/936661109_ScreenShot2020-08-15at7_34_29pm.png.b1d0186ed325b12073d53781e0fd63f4.png" />

     

    Please login or register to see this code.

     

     

    This works and it is simple however I still have the delay.

    • 0
    Posted

    Is it the only door sensor you have?

    • 0
    Guest puma
  • Inquirer
  • Posted
    22 minutes ago, SmartHomeEddy said:

    Is it the only door sensor you have?

     

    No I have plenty of others.

    • 0
    Posted

    So this is the only door sensor who acts this way?

    • 0
    Guest puma
  • Inquirer
  • Posted
    27 minutes ago, SmartHomeEddy said:

    So this is the only door sensor who acts this way?

     

    Yes it is.

     

    I can have a simple scene for another sensor and it works a treat.

     

    It's just this particular controller I feel it's not the fibaro it has to be the controller on how quickly it reports the change however I can't seem to change that.

    • 0
    Posted

    Please login or register to see this image.

    /monthly_2020_08/782E7EF5-534F-4DC5-979F-8C951F63107D.png.a0a4802e35fba2b58b4d4f810ed95578.png" />

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Answer this question...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...