Letter to R&D about coroutines, mentioned before many times...

[Łukasz997 117]

Dear Fibaro R&D Team (via @m.roszak),

I would like to ask whether there are any plans to make Lua coroutines available in the HC3 QuickApp environment, or at least to provide an equivalent cooperative execution mechanism.

At the moment, QuickApp developers are forced to build all non-trivial logic in a purely event-driven style. This becomes increasingly complex when dealing with asynchronous, multi-step processes such as:

- device discovery and registration,

- client-server handshakes,

- retry-based initialization,

- dependency ordering between virtual devices, child devices and physical devices.

 

Without coroutines, there is no clean way to express a “wait until ready or fail” flow. As a result, developers must split logical sequences across multiple callbacks and state flags, which:

- VERY significantly reduces code readability,

- makes error handling MUCH harder,

- increases the risk of subtle race conditions,.

 

With coroutines, this could be expressed in a safe and non-blocking way using cooperative yielding and resuming (without blocking the event loop)

If coroutines are intentionally unavailable in HC3, optional mechanism also will be appreciated (something like: fibaro.await)

If they are planned, is there a rough roadmap or time target?

 

Having clarity on this topic would greatly help advanced QuickApp developers design long-term, maintainable architectures that align with the platform’s intended direction.

This question has already been asked multiple times without any result. I believe that, as customers who have spent money on your products and actively use your hardware, we deserve a clear answer.

 

Kind regards,

Łukasz Stachura

PS. Everyone who is interested, please sign this. Maybe then it will get better attention.

[jgab 2,647]

Long time ago, coroutines in Lua had some security issues, but from 5.2, coroutines are deemed as safe as the math lib.

...and coroutines takes up very little resources, less then the code we are forced to write to overcome the lack of them  

Depending on the way they have embedded Lua (I assume it's a C app embedding a Lua VM - one per QA and Scene) 
it may require some work besides just including the coroutines functions.

Lua coroutines can't yield across C boundaries - which means that we can't yield from a lua callback function from builtins like ex. from setTimeout/setInterval as they seem to be implemented in C. There are ways around it but it requires come coding. (with old setTimeout and coroutines we could easily code new setTimeout in lua space working with yield)

In my Plua interpreter I embed Lua in Python, and I have a similar problem as Lua can't yield across python boundaries - and my base timer is from Python. However, I can use the python timer to drive a Lua setTimeout where all calls are Lua to Lua, and we don't have the yield issue...

Yes, the advantage of coroutines would be huge.

We would not have all the posts from people struggling with handling the return value from net.HTTPClient():request() as we could make a HC2 style synchronous version. etc etc.

We could kick off QuickApp:onInit() as a coroutine and allow people to do fibaro.sleep(..) without stopping all other callbacks/timers, allowing people to do simple

Please login or register to see this code.

I could remove 3000+ lines of code from EventRunner6, where I today compile to my own VM that have "coroutines" so I can run several rules in parallell....
 

...and then if we had access to load(...) also, so we could create dynamically tailored code....

Edited December 12, 2025 by jgab

[jgab 2,647]

So, I change my mind. Fibaro should just enable coroutines and don't worry if it clashes with setTimeout and other native callbacks. 
We, developers, that will use coroutines will get a clean "Can't yield across C-boundary" error from Lua if we use those callbacks.
However, we can then implement our own Lua library to get around these limitations....

[Łukasz997 117]

Are we too small a group to deserve an answer?

@m.roszak, we will appreciate the answer...

[m.roszak 773]

For now no plans for changes here, if something will be planned here - I will let you know.