Scenes vs manual execute lights on

Community Playground Scenes & Automations
#1

Can someone like maybe @rafale77 explain when running a scene to turn on 10 light it can take like 0,5 to 5 minutes .(popcorn effect) But when i turn the on them manually in the app they all turn on as fast as i can press on every device in the app?

Is it some kind of que in scenes and not in manually?

Very annoying!
/ Mattias

#2

Hi Mattburk,

What you are observing is what I have been complaining about and what I call the last 20% of problem left over after reducing the chattiness of the zwave network. It is a command queueing issue. From my analysis of my logs, I am seeing 2 root causes:

  1. Got CANs which I think are the result of sensors in the network sending a frame back to the vera and the vera decides to dump that frame and block any serial communication to the zwave dongle for 0.1s. If this happens while you are sending commands you are going to see delays… and they will show up as tardy callbacks in the logs. These delays accumulate and can get long… very very long and normally crash the luup engine in 5min. I disabled the ability for the system to reload itself in these situations and saw it go as long as 2hours. This is what people are observing as “commands getting executed randomly”.
  2. NONCE_GET flood. I have not gotten to the bottom of this one but appears to be from the vera not handling the command queue properly and waiting for a frame from the device which the device probably already sent but was buried in the chattiness of the system. Strangely the vera handles it with a 20s timeout and therefore the vera will not send zwave commands for 20s.

The reason why you are not seeing it as much when you run one command at a time is because of the time gap you put between each command allowing each command to execute or timeout. It is rather a matter of probability and is why I had asked @akbooer if he could handle a command queue through the verabridge on openluup because… the vera is failing to do so properly. One by spacing commands in time and two, by putting which are timing out to the end of the queue. This is elementary command queuing but I think the vera has gotten a little “too cute” trying to do things in very strange ways, I suspect to maintain command order which could be important for device inclusion…

1 Like
#3

Hi…Thank you very much for the explanation @rafale77 !! ok my amateurguess was something like that.

I wonder, if you turn on 10 lights thru Reactor , will the Vera handle it as I scene or will it more handle like manually?

Will a delay between help and virtually make my human delays so it goes faster?

In reactor it would be nice with an easier way to fast choose devices to for example turn on. More like in native vera scenes… you just click what devices you want to do something with and then they pop up together and you then can choose dim/turn on/off etc… What do you think about that @rigpapa?

/Mattias

#4

Scenes run as jobs in the Vera core, so they are subject to Vera’s scheduling of the job in relation to other jobs, and thus might be affected in ways we cannot easily externally determine.

Reactor runs actions on devices individually, in the executing thread of the Reactor core. Thus when Reactor decides to turn on a light, the action is invoked to do that right now. This is one of the things that can make Reactor Activities more responsive than native Vera scenes.

That said, both will have this limitation: if the implementation of the device action specifies that the action is to be performed in a job, then that job will be queued and run when Vera is good and ready. This is a decision made by the implementation, so for plugins especially, the author should have good reason to use a job rather than an immediate run. YMMV.

I’ve contemplated “device sets” for Reactor, but the technical problems in doing it in the current Vera device model don’t point to a fair exchange of value for effort. Determining what to do on a non-homogenous set of devices when you invoke an action on the set that not all of the member devices support directly, for example, is not a trivial task. That is, if you have a set with a light and a thermostat, what does “turn off” really need to do? There isn’t a universal “turn off” action in the Vera/UPnP device model. If you start building metadata to map such generic actions into the actual UPnP actions, what happens when the set contains a device that’s not in the metadata? On day one, does the metadata need to contain information to support every device and service created by every plugin currently in the Vera App Marketplace? I just don’t see a great exchange of value for the effort this would take. And I have considered it, because Reactor already has a pretty big catalog of metadata even for what it currently can do. But this a whole new level. And then there’s matter of the upcoming new firmware working completely differently anyway…

#5

OK Thanx for the explanation. I understand the complicity of the device sets function.
Well since I started using vera 4 years ago it always took long time to turn off all lights for example for the night. These days its going much more faster but has a bit annoying lag. But you learn to accept it even if you always want improvement.

This is good info for the vera users!!

Keep upp the good work @rigpapa and rafale77. :smile:
/Mattias

#6

I stopped using vera core scene controller for scenes and starred using reactor and manually coding the scenes in lua

#7

I have had similar experiences with PLEG, especially when 2 conditions go true and execute 2 actions on the same device at the same time. Adding a delay of 1 sec to one of the actions resolves that issue. A better solution is to consolidate those conditions but I had other reasons to have them separate.