So I never thought I would one day come to ask this but here we are. With the latest update and some additional packages the vera has been humming with elimination of nearly all delays. I am now noticing that the only remaining delays I am observing are due to openluup running multiple scenes in parallel: When scenes are triggered before other scenes are completed, scenes can get a delay waiting for the scene to complete. It isn’t a huge problem and is fairly minimal but… whenever there is room for improvements… I will ask.
So my question is this what: limitations are there in openluup for parallel scenes execution and is there a way to improve the performance? I know openluup runs on only one cpu thread.
I am also wondering in openluup whether there is a difference between luup.call_delay and luup.call_timer in terms of job/cpu cycles.
1 Like
I’m surprised. This shouldn’t be the case. Scenes are quite separate from one another. Delayed actions also run asynchronously.
Need more information on what the scenes are trying to do.
Shouldn’t be any, apart from the fact that the CPU can only actually do one thing at a time. You would need a different build of Lua to get multi-core support.
A job has slightly more overhead, but much more flexibility. Scene timers are run as jobs. Interval timers are run as delays. There should be negligible practical difference. I would advise against trying to optimise against specific peculiarities of any system.
Very open to investigate this further, but need a little help. What type of scenes? What order of magnitude delay? Do you have a test case to try?
Strangely enough, I am looking closely at scenes just now anyway. Just squashed a bug where paused scenes still ran jobs. I’m discovering a few things as I add monitoring features to the console (like globals, and the completed task list,…). My main goal at the moment is to nail the “active scene” status, although that is a topic for another thread.
I have a test case:
My TTS annoucement scenes run with a local TTS server (mac OS) and through a local API. In order to prevent running two TTS calls to my speakers, I am using a flag which turns on an off and blocks the TTS call if one is already running. In any case, as you already know I have set a variable watch on the vera to instantly update openLuup.
So I have this scene which from a sensor status sends a TTS from openLuup.
Immediatly after this scene, I can trigger another sensor which turns on a light. So the first scene is not running an action on the vera and the second does. What I observe is that while the first scene is always instantaneous. And the second also is if the first one is not running, when one runs within a second of the other, I am getting a delay. The first scene takes 3-4s to complete because I implemented a luup call delay to call a function to turn off the TTS flag after some time and well, the TTS announcement itself takes time. I have never seen the second scene (turn the light on) complete before the TTS is completed.
So the first is a local openLuup scene, and the second through a bridged Vera?
First is triggered by vera but execution is local. Second is triggered by the vera and executed through the vera by openluup.
I guess I still don’t fully understand.
Your triggering is done with your variable watch Vera code sending a request to set a variable (or run a scene) on openLuup?
The second scene is triggered likewise, but results in running a scene on Vera? How? (for that matter, why?)
It’s rather hard to diagnose without the details.
Is your VeraBridge using asynchronous polling? When this is enabled, an asynchronous request is also used to initiate remote requests. However, bridged scenes are, by default, done synchronously. You could explicitly change this in the local (openLuup) scene Lua.
No scenes are on the vera. They are all on openluup. What I meant is that the actions are vera (asynchronous verabridge) actions. Sorry for not being clear. Basically while the first openluup scene is being run. And includes a luup call delay. The second openluup scene does not execute.
OK, clearer now.
Can I see the scene JSON for both scenes?
The easiest way to do this is from the Lua Test window…
print (luup.scenes[scene_no])
Thanks.
I will PM you later today. Thanks!
Try the latest openLuup development version (19.5.12)
It has a rather subtle change, and I wonder if this will address your issue…?
Whilst scenes triggered by timers, etc., run quite independently of one another, the action call to HomeAutomationGateway waited for the first action group of the scene to complete (delayed actions still ran asynchronously.)
There are other things in your scene Lua which could be investigated, but give this a go for a start.
1 Like
Will do! Thanks for the quick turnaround. I will let you know how it works out.
Looks like it didn’t help. I tested it a little:
The first scene runs a few conditionals then triggers a luup.inet.wget along with a luup.call.delay or luup.call.timer at the end of which it calls a function to reset a global variable. It runs flawlessly and immediately whenever triggered by the sensor (verabridge)
The second scene is a very simple turn on a light whenever triggered with a delay to turn that light off after some time.
What I am observing is, both scenes run instantly when run one at a time. When I trigger both scene from ALTUI, one after the other (scene 1 and the scene 2) within one second, The second scene does not run until 3-4s later. I tried shortening the delay for the luup call timer but that did not make any difference. Could it be the luup.inet.wget? It is an loopback call withing the same VM 127.0.0.1.
OK. I will look harder (at your code, and mine!)
One more test result: I tried running the first scene and immediately from openluup turn the light on… The delay is less than 1s. There is a delay, the TTS needs to complete, but the light immediately turns on after the TTS announcement is complete unlike the scene case which takes a few extra seconds.
I further refined the test with lua code test:
running the two scenes this way:
luup.call_action(“urn:micasaverde-com:serviceId:HomeAutomationGateway1”,“RunScene”,{ SceneNum=“123” }, 0)
luup.call_action(“urn:micasaverde-com:serviceId:HomeAutomationGateway1”,“RunScene”,{ SceneNum=“117” }, 0)
I get 3s delay
Running one scene then turn on the light manually
luup.call_action(“urn:micasaverde-com:serviceId:HomeAutomationGateway1”,“RunScene”,{ SceneNum=“123” }, 0)
luup.call_action (“urn:upnp-org:serviceId:SwitchPower1”, “SetTarget”, {[“newTargetValue”] = “1”}, lightDeviceNo)
I get 1s delay
One more test: I flipped the order of the scenes and the delay is gone. So the first scene which contains a call to luup.call_delay and a luup.inet_wget is the one causing the delay and I am wondering if it is because of the node server I am running within the same VM responsible for the TTS hogging the CPU while processing the TTS. This may not be a problem with openLuup after all but it is still odd that a verabridge action shows a shorter delay than a scene action calling that same verabridge action.
This was going to be my next line of investigation. Perhaps easier for you than for me: can you mock up a scene which does everything but the TTS, but still does a fixed-length (long-ish) call_delay() ?
Ok, will do it but in a couple of weeks… I am on business travel.
OK, fair enough. I’ll try and take a look at it myself sometime, then.
That would be great. Thank you.
Sorry for not being more helpful for the time being.
I am back for too days and I think I got to the bottom of it: It is not the luup call delay which is causing the lag… It seems to be the luup.inet.wget waiting for a response and my TTS server does not want to respond until after the announcement is complete. Is it possible that the http call causes openluup to hang while waiting for a return?