Checking number of running scenes - why?

[knuth 29]

Several posts on this forum recommend including a check in LUA scenes to ensure that only one instance of the scene is currently running. The recommended code is similar to this:

Please login or register to see this code.

The main panel for each scene, however, includes a parameter controlling max. running instances:

Please login or register to see this image.

/monthly_2019_09/image.png.350ee8a750533bbbca1be9ad3cadd73f.png" />

Why is it necessary to include the extra code, if this parameter already limits the scene to one active instance? Is it only to get the explicit warning from the fibaro:debug() command? 

 

 

[jgab 2,122]

52 minutes ago, knuth said:

Several posts on this forum recommend including a check in LUA scenes to ensure that only one instance of the scene is currently running. The recommended code is similar to this:

Please login or register to see this code.

The main panel for each scene, however, includes a parameter controlling max. running instances:

Please login or register to see this link.

Why is it necessary to include the extra code, if this parameter already limits the scene to one active instance? Is it only to get the explicit warning from the fibaro:debug() command? 

 

 

 

It's actually a very good question.

If you limit the number of running instances and your scene exceeds that you get warnings in the Fibaro GUI that is annoying and people experience as errors that need to get fixed. 

An approach to try to fix that is to add code as you exemplified. (You could set max running to 1 in the example above and skip the code but you will get a lot of warnings in the fibaro gui.)

However, the fibaro runtime has no idea what code you have inside your scenes (the countScenes check) and may still start up too many parallel instances of a scene before your scene code gets a chance to detect it and abort the scenes. That's why if you set max running to 1 and test countScenes < 2 you may still get warnings from fibaro that max number of scenes has been exceeded.

The way it's done now (which is not that helpful) makes meI always set max running to 10 and manage number of instances from the code (if needed).

[Sankotronic 2,236]

I do same as @jgab , set for scenes at least 6 to 10 instances running, but that is just to avoid that warning. In scene code I use this simple line that is on top of all other code:

Please login or register to see this code.

os.exit() is actually LUA function to stop running code and fibaro:abort() is Fibaro added function which actually call os.exit() so better to use original LUA function than function that calls function  It is also important to write that above way is keeping first instance running while killing all successor instances. NOTICE - killing already started instances not preventing them from starting.

 

There is another way to ensure only one running instance by adding option %% killOtherInstances but this one is tricky since it kills already started instance to let run next instance when started. This was like that at least when I tested it some time ago.

[knuth 29]

Clear and reasonable answers from @jgab and @Sankotronic as always! I have not been bothered by annoying warnings in the GUI, so I keep both options open. But I note that I can either set Max running instances to 1" or  use the one line code suggest by Sankotronic combined with a max of 5 or more instances. In my initial example (copied from others), the implementation was a bit more elaborate

Please login or register to see this code.

which makes sure that an "annoying warning" appears anyway, through the fibaro:debug message . That seems to defeat the purpose of having an internal code! Sankotronics one-liner is better. 

 

I note the recommendation to use os.exit() rather than fibaro:abort() - shorter and more direct. To be implemented in all my scenes from now on! Thanks!

[jgab 2,122]

I'm not sure I agree about bypassing fibaro:abort because we know that it's just a call to os.exit.

First the overhead in time is counted in microseconds (not milli) for that extra Lua function call.

Secondly, os.exit is a Lua builtin to terminate the app. And it also works to kill an instance  the way Fibaro have implemented it. However, one could imagine a future where Fibaro wants to do something else before killing the instance (or not actually "killing" it). They can't put that in fibaro:abort because everyone has taken a custom to bypass it. So a general principle when coding in framework is to not bypass the API that is offered as it limits how the framework can evolve. Having said that I'm not expecting the fibaro Lua api to evolve anytime soon