Hi Rigpappa and Users,
Silly me after using a z-wave lock for some years, the scene was slow and unreliable to complete. I finally figured out that extra cameras triggering record when unlocking/locking were delaying the scene. Once I set it to 1 camera and the lights near the door the scene sped up and is far more reliable than it has been.
I’m trying to determine if Reactor is right for me. I have read your posts, use cases, and watched the threads since your wrote the plugin. I know Vera’s use of cameras on the platform isn’t great so with that said, does Reactor’s scheduler work better than Vera’s and more complex scenes that don’t involve z-wave only devices would run more efficiently?
Take a second example with the door lock. One of the lights in the scene is a Philips Hue A19 bulb. Sometimes it is noticeable that the Hue bulb is delayed turning on/off when the door is unlocked.
So to summarize, my question really involves around cloud plugins (Philips/MyQ/Nest/etc.) in scenes (cameras are less important now). Is Reactor more efficiently calling those plugins in the scenes that are cloud based versus Vera’s mechanisms for executing the scenes?
Yes, clearly I can install and see for myself but I get limited play time and would prefer yours and the community’s perspective on it first.
Thank you very much for your time and effort!
Your example is sort of a classic timing thing everyone has run into with Vera. You want things to be instantaneous, but they’re not. Even Z-Wave is subject to delays. We’ve all had the issue where a Z-wave device is having problems, and it causes delays in scenes whenever it’s used (part of this is because Vera seems to stall while retrying, rather than, for example, deferring retries by suspending the job and moving it to the back of the queue, etc.). The conditions that lead to issues like this are innumerable, and unpredictable.
Reactor can’t work around these limitations in the current environment. Neither can PLEG or scene Lua. I can fill the feature holes in scene/action triggering, and make it really fast to sense the changes and submit the actions to Luup, and be a good custodian of your system’s resources and not bog it down, but I can’t make Vera’s Luup job scheduling and execution any better than it is. All we can do is ask Luup to perform the task, and Luup does it when it’s good and ready. Perhaps some day, Vera will be a true multitasking system, and in that environment we may be able to minimize some of the effects of slow, failing, or failed devices, but that’s not where we are today, and that won’t get your bulb turned on quickly if it doesn’t want to be for any external reasons.
That said, I would not choose a cloud-based device for an application where low-latency response to commands is a requirement. And FWIW, most of the pro-grade security camera systems I’ve worked with record several seconds of video to a buffer that becomes part of the video when recording is triggered by an event. As good as they may be, they still would otherwise not be able to trigger quickly enough to capture the event adequately. I use BlueIris in my own home, which is hardly high end, but it has this feature. Pressing Vera, bulbs, and IP cameras into a race to get a decent recording also doesn’t seem like it would lead to consistent success.
Thank you for taking the time to respond to me. I guess after reading your threads and all of extroot from rafael77 I sort of guessed this already. Thanks!
Sent from my VS995 using Tapatalk