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

setTimeout in HC3


jwi

Question

I have many HC2 scenes in which the command setTimout (functionname, 60 * 1000) is used.

The main function checks conditions such as temperature or brightness every minute. Since the

command no longer works in the HC3, I have built a while loop into the function and ended up

with a fibaro.sleep (60 * 1000).
It works, but I assume there is a better solution.
But which?

Calling up the scene every minute via a cron trigger is definitely not a good solution.
Thanks for your help.

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 1

ctrr+f with fibaro.setTimeout on this page

Please login or register to see this link.

Link to comment
Share on other sites

  • 0
5 minutes ago, jwi said:

I have many HC2 scenes in which the command setTimout (functionname, 60 * 1000) is used.

Fibaro has moved this function to the "fibaro" class and, for unknown reasons, swapped the order of the arguments.

 

Please login or register to see this code.

BTW you are indeed encouraged to use setTimeout instead of sleep, because sleep is blocking. But scene using "sleep" are easier to read...

 

10 minutes ago, jwi said:

Calling up the scene every minute via a cron trigger is definitely not a good solution.

I don't know. Depends on what you want to do I guess. I recently added 2 such senses to test a certain hypothesis and did not notice the impact (compared with similar scene running every minute using sleep or setTimout I mean). 

Link to comment
Share on other sites

  • 0

Do you know if SetTimeout start a new thread ?

The delay (30000) is in micro seconds ?

Edited by AlexPeret
Link to comment
Share on other sites

  • 0
1 minute ago, AlexPeret said:

Do you know if SetTimeout start a new thread ?

I think by "thread" you mean "I can have more than one setTimeout" at the same time? In that case the answer is yes. I don't know if it is technically speaking a different (linux) thread. But keep in mind, your main code has to finish before the timers kick in... httpClient can also do more than one call...

 

Link to comment
Share on other sites

  • 0
On 7/4/2020 at 10:45 AM, petergebruers said:

I think by "thread" you mean "I can have more than one setTimeout" at the same time? In that case the answer is yes. I don't know if it is technically speaking a different (linux) thread. But keep in mind, your main code has to finish before the timers kick in... httpClient can also do more than one call...

 

 

To be more specific, it's not a new Linux thread (Lua itself is not reentrant and its a mess to share a Lua context between processes). So what we have is a cooperative model where your "setTimeOuted" function needs to exit before any other setTimeout function can run (lets call them timers). The "system" keeps a sorted table of scheduled timers and run them in order when times up. That's why no timer is called before your main code is loaded and finished it's "run". This also means that a timer can be delayed because other stuff are running, but it will be scheduled as soon as the system can. This may feel like a limitation, but in reality it's not.  However, fibaro.sleep will block any opportunity for the system to schedule timers.

In fact, we should be glad that we have this model. Imagine if our functions were running in parallel and we could have race conditions? We would need models for locking and critical sections and just imagine the kind of "unexplainable" errors people would encounter. 

 

For people interested here is a small "QuickApp" emulator written in Lua. It can't run on the HC3 due to limitations of available Lua functions (needs coroutines) but it works in any standard Lua environment on a PC/Mac/Linux. It implements setTimeout and friends from scratch and run a QuickApp "class". Conceptually close to what's going on on the HC3.

 

Edited by jgab
Link to comment
Share on other sites

  • 0

@petergebruers Yes that was my question ("can we launch as many as we want ?").

 

@jgab : Ok, I understand. So (for me) if the context is not transmit, that's not exactly what I call a thread in programming language. But if in the Fibaro HC3 context the setTimeout process is launch in parralelle than other process (and doesn't stop them), this is the main goal and it does the job :-)

 

By the way, the delay (30000) is in micro seconds ?

Edited by AlexPeret
Link to comment
Share on other sites

  • 0
12 minutes ago, AlexPeret said:

the delay (30000) is in micro seconds ?

Milliseconds. The example I gave turns off a device 30 seconds after booting my HC3

Link to comment
Share on other sites

  • 0

BTW if you come from a different program language it may not be obvious what is going on (eg "why do we write function() ... end" as a parameter?). I wrote this topic when the function was introduced on HC2, so unfortunately it is not been updated with HC3 syntax (I mean setTimeout becomes fibaro.setTimeout and you have to swap the arguments)

 

 

  • Thanks 1
Link to comment
Share on other sites

  • 0

I can find one small upside to the argument switch in fibaro.setTimeout but then they should have let us add argument parameters

Ex.

Please login or register to see this code.

This is how we need to do today to pass arguments to the function used in setTimeout. 'sum' in this case.

They could have allowed us to do

Please login or register to see this code.

which of course looks nicer when the delay is the first argument. This would also make the style similar to pcall.

 

Of course it's easy to patch the function to behave that way but it should be built-in

Please login or register to see this code.

 

Edited by jgab
Link to comment
Share on other sites

  • 0

is it per design that asynchronous setTimeout in HC3 works only after scene is finished?

when scene is still running inside function is not executed, but ony when scene is finished 

Link to comment
Share on other sites

  • 0

Yes, it's per design. Timers are run in a cooperative fashion where a timer needs to finish before another can start.

Think of the main scene running as the "first" timer. Other timers started can run first when the main scene timer is finished.

If we didn't have this model and instead had true parallelism - we would need mechanism to synchronise the code so there were no

race conditions. ex. code trying to set the same variable at the same time etc... much easier to have buggy code.

In general, each timer (or block of code) should be small enough so that timers will run on time and not block out each other.

However, don't use fibaro.sleep with timers as it it will block them and on the HC3 in scenes actually push timers into the future... which is a bug.

Edited by jgab
  • Like 2
Link to comment
Share on other sites

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...