No worries, I’ll use reactor logic to cover my use case.
Hi @rigpapa one issue i’ve noticed recently with DelayLight that is a minor pest is disabling an active DelayLight device doesnt cancel the timer and the configured action.
Using my above example, if I turn on my study room light and then turn on my WFH VS, Reactor will disable the relevant DelayLight device for 4 hours but the timer will still be active and turn off the light after 1 hour has elapsed.
Oh and one other question, how does DelayLight handle multiple monitored lights on the one device? Does it set the timer based on the first light turing on and then turn off any additional lights at the same time as the first. Or does it run an additional timer for each light?
Also by design. I think the safest course of action here is to add a new action, “Cancel”, which will quietly cancel any active timing without changing the state of the controlled devices. I’ll work on that.
My finite state machine is trending toward infinite…
2 Likes
Thanks Patrick, that’d be quite useful. 
EDIT: or even just a toggle option in each DelayLight device to cancel (or not) active timers when disabled could work well.
OK. If you want to try the stable branch version on GitHub, that should get you where you are going. The new action is Cancel, and Reactor will find it as a new exception for the moment. Just issue that action after the SetEnabled action and you should be good to go.
1 Like
Cheers, downloading now.
1 Like
and that works great, thanks Patrick. 
1 Like
Hi Patrick,
Wonder if you could help, i’m Looking to have 3 different delaylight devices, 1 for setting the times during the evening, 1 for overnight, and 1 for the morning.
I’ve got different active periods and in the night device, using the night mode, whereas the others both use home.
I’m finding that the active period and the mode doesn’t seem to be being applied, and when the sensor triggers the light, it’s starting the timer for all the instances. This means that the timer with the shortest timescale is winning, and turns the light off accordingly.
A quick query, I’m using a aeotec 6 in 1 sensor, which I disarm during the daylight hours, does the delaylight only use the sensor when its armed and tripped?
Thanks
Tony
Tony, if you have multiple DLTs controlling a single light, whichever DLT controls the light first will look to the other DLTs like someone has manually turned on the light, which starts manual timing on those DLTs. They don’t talk to each other. Multiple DLTs controlling an overlapping set of devices is not supported.
I’ve been working on making the “active periods” into full-blown schedules, with different auto and manual timing in each period. Haven’t gotten to alpha there yet though.
1 Like
Hi @rigpapa I just realised I didn’t get an answer to this question, any chance you could please confirm how this scenario is implemented?
Sorry, not sure why/how I missed that…
When any monitored load is turned on manually, it causes manual timing to start for the lot of them, all together as a group. They will be turned off at the same time. A monitored load is any load that appears in the “on” list or the “off” list, or both.
In addition, if any loads are listed in the “on” list, all of those devices will be turned on (to their configured levels as may be necessary) when any monitored load is turned on manually. This behavior can be disabled by setting ManualOnScene to 0 in the DLT.
All good, I’d forgotten about it too.
Awesome, I’ll switch to per room DelayLight devices as that seems to make more sense.
Thanks for the update, if you need some code testing, when you’ve had chance, let me know.
Thanks again!
Hi Patrick,
As a workaround for now, I’m using scenes to enable and disable the delay light devices. So far, so good…
Would love to see this future!!
Hi Patrick,
I’ve installed your Plugin which looks great and have set up a light to switch on when the motion sensor is tripped.
Works as designed however there is a 4 - 6 second lag between the sensor tripping and the light switching on. The “on delay” option is set to zero so wouldn’t expect a delay?
Are you able to assist.
Thanks
That’s probably a combination of the responsiveness of your motion sensor and your ZWave mesh. Motion sensors, particularly the pet immune models, have built-in delays for hysteresis (to avoid nuisance trips caused by shadows or heat sources). Some of these are tunable, although rarely, and sometimes it’s a bit obtuse–I have one, for example, where the “sensitivity” setting very clearly affects timing.
But beyond that, we’re working with the responsiveness of your Vera and the ZWave mesh. I would check the load on your system first, to make sure something hasn’t gone rogue and is making your system very busy. Also, you may want to look into using the new DisableWakeupARR_NNU variable on your battery-operated sensors, as @rafale77 recommends, and reduce polling traffic on your mesh to the minimum necessary. More about those points here: Zwave Network On Vera Explained - #2 by rafale77 - Getting Started & Initial Setup - Ezlo Community
2 Likes
To pile on, I use DelayLight on over a dozen switches in my house. The response in most cases is as fast as a dedicated in-wall PIR switch. As @rigpapa points out, however, the motion sensor itself has a several attributes that affect the speed.
- Sensitivity - as mentioned.
- Basic design - some PIRs will respond faster than others. You may need to find a different sensor if yours is intrinsically slow.
- Field of view - all PIR sensors have a “lens” that sets the field of view. Check the device instruction manual—there will usually be diagrams of the sensor field of view. Try to aim the sensor for maximum effectiveness. The Z-Wave PIRs are usually designed for false trigger immunity, not absolute response speed.
- Your network and Vera’s load - a good way to see if this is the issue is to trigger the PIR and watch for its LED flash (assuming it has one) which will tell you when the PIR saw the event. If there is a substantial delay after the flash, network/Vera delay may be the problem. Something else to consider – the PIR may flash the LED when the detector fires, but that may not be when the device sends the Z-Wave out, perhaps due to sensitivity/debounce delays.
1 Like
Thanks for the reply. I can rule out that it’s not a congestion problem as I was replacing an existing scene which works instantly the moment the PIR LED lights up.
The current set up:
- Virtual Switch, HALL LED, sends a HTTP request to a wifi switch to switch on an LED light
- PIR triggers a scene to switch on the HALL LED, wait 5 minutes and switch off.
The performance based on the above is lightning fast.
Worth mentioning is that scene is running on my Vera Edge controller which I have bridged to a VeraPlus controller.
I have various scenes of which your plugin would replace and significantly simply.
Any further recommendations would be greatly appreciated.
Thanks
Look at your LuaUPnP.log file on the system running DelayLight. You should easily find the string “Timer (name and device number of DLT) AUTO triggering…”. After that, you should find the string “Timer (name and device number of DLT) turning loads on”. The difference in the timestamps of those two is the bulk of DelayLight’s response time from seeing the PIR signal to turning on the controlled load(s).
If you want to watch that process in more detail, first turn set DebugMode in the DelayLight master device to 1, the reload Luup. Then run the test and check the logs. You’ll be able to see when the DLT actually sends the signal to the virtual switch. The DLT first sees the PIR change with the message beginning with “timerWatch(device number of your PIR, otherstuff…)”. That will typically lead the “AUTO triggering” message by just a few milliseconds.
Have you tried just flicking the virtual switch yourself and seeing how long it takes the light to come on? Seems you’ve got quite a bit of plumbing on that side, and bridged.