Speed up reactor / delay-light response time?

[connormacleod]

Hi Patrick,

Not sure if this is something I can control in Recator or Delaylight, or if this is a problem with Vera itself that’s typical and something I have to live with!

I have a Zooz ZSE18 motion sensor that I’ve tied to delay-light as a trigger device. Of course, it’s supposed to turn on the lights when it sees motion. I’ve noticed when no one has been in the room for some time, there seems to be an inexplicable delay in activating the lights when motion is detected. (~10 sec). But if someone has been in the room recently and the lights have gone through an on/off cycle, they turn on with relatively little delay. (< 2 sec)

The Zooz sensor has a little blue light that flashes when motion is detected, and the light seems to come on almost instantly in both cases (i.e. whether someone’s been in the room recently or not). But as described above, if the lights have been inactive for some time, there’s a delay (like ~10 seconds) before the lights come on. So the Zooz sensor is detecting motion, it just seems the downstream sensors aren’t responding to the signal always in short order.

I tried setting up a reactor sensor to monitor the state of the Zooz sensor, and use that as a trigger for delaylight, but it makes no difference, the behavior is the same as if I use the Zooz sensor as a trigger for delay-light directly.

Any ideas on what would cause the excess delay in turning on the lights when they’ve been inactive for some time? Is there a work-around for this kind of behavior so that it responds more expeditiously. lol

appreciate any advice.

regards

[rigpapa]

The first thing that jumps to mind is polling. The system will suspend polling activity when other things are going on, then resume polling when the mesh has been quiet for a while. If it’s busy polling a device when your motion sensor triggers, the polling job has to finish before other jobs can run.

This is complicated by @rafale77 's discovery that an ARR/NNU is done on battery operated devices (like many motion sensors) at inopportune times. This is a process that can take several seconds, during which time the system is busy just doing that, so other jobs are apparently delayed.

Much has been said in other threads about best practices for configuring polling and handling the ARR/NNU issue, so I won’t rehash those here. A good read of this thread may provide some answers: Zwave Network On Vera Explained

[rafale77]

There can be a number of reasons for delays within the zwave command queue in both the receiving and the sending directions. @rigpapa’s suspicion is right on. If you have not upgraded the firmware yet and ran these codes to eliminate some of the frivolous garbage the vera generates on your network, start there. It should take down the frequency of these occurrence by 50-80% depending on your network.
For the remaining other root causes, unfortunately we have nothing in sight at the moment and are relying on prayers… or replacement plans.

[connormacleod]

Thanks @rafale77 and @rigpapa, that’s a most interesting read. I changed the poll settings to 0 for the zooz sensor, and changed the wakeup interval to 86,400. (my zooz zse 18 is connected to USB power and functions as a repeater)

From what I understand reading the article however, I should really be turning off polling for ALL my non battery powered devices, by using the LUUP code, is that right? Would I have to include this in my startup LUA, or is running this code once sufficient?

[rafale77]

Running the code once is sufficient. The data is stored in your vera’s configuration file.
And yes you are right, only very rare AC powered devices benefit from polling. Turning it on for all devices is absurd. After you turn them all off, you can decide which ones may need it when you see them not update status proactively. I do not recommend turning off polling in the zwave menu though as it would turn off all polling except ones for the battery operated devices which… also rarely need polling but we can’t turn that off at this point. Likewise the entire scheme of asking the battery powered devices to update neighbors at every wakeup event or ever at all is blatantly stupid. So are the short default wakeup interval set during the inclusion process and nightly heal.