The sensor does not need to be armed.
I finally got around to trying out DelayLight ⊠and itâs great! Thanks for another fantastic plugin Patrick! 8)
Just made one that turns on the light at low level if someone is walking around the house in night mode. For some reason it wonât limit its efforts to the night mode, it triggers in home mode as well⊠any ideas?
Please go to the Settings tab for your DelayLight timer, and click on the link at the bottom of the page to Toggle Debug. It should report that debug is ON.
Then, make sure you are in Home mode, and attempt to trigger your timer. Then please fetch and send me your log via PM (not posted in the thread, please). Thanks!
[tt]http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP[/tt]
You have mail. 
OK. It looks like the timer âNattlysâ (device 596) is correctly responding to the action of various motion sensors (e.g. âBevegelse - Badâ and âBevegelse - Stueâ) and not turning on its light, because it recognizes the current house mode as 1 (Home), but it is configured to only execute in house mode 3 (Night). So thatâs correct, itâs doing the right thing.
But, another timer âLystimerâ (device 595) is also responding to âBevegelse - Badâ is being triggered, and it is configured to respond only in âHomeâ (house mode 1), so itâs matching and therefore turning on lights on its list.
The âonâ for Nattlys is â588=30,285=30,19,90=30â (so devices 588, 285, 19, and 90 at their respective dimming levels). The âonâ list for Lystimer is â588,589â. So both timers include device 588 (Lys - Bad).
So, Iâm now confused about what the problem is, but I can see this: Nattlys is correctly suppressing any activity when in Home mode, because it is restricted to Night modeâit is working as configured. And Lystimer is also performing as expected. Both timers seem to be doing what they are configured to do. Did you intend for two timers to control the same light? Thereâs nothing wrong with that, but it would explain why lights are coming on in a mode other than âNightâ.
âLysTimerâ is ment to turn the bathroom light on in Home mode, but when I went in there, the action of the delaylight was that of the âNattlysâ instance, not the âlystimerâ reaction, which only has one light to turn on. All devices set up in âNattlysâ reacted as stated in âNattlysâ.
I think it seems like thereâs a common variable somewhere that shouldnt be common, but i donât knowâŠ
[quote=âForzaalfa, post:87, topic:198651â]âLysTimerâ is ment to turn the bathroom light on in Home mode, but when I went in there, the action of the delaylight was that of the âNattlysâ instance, not the âlystimerâ reaction, which only has one light to turn on. All devices set up in âNattlysâ reacted as stated in âNattlysâ.
I think it seems like thereâs a common variable somewhere that shouldnt be common, but i donât know⊠:)[/quote]
OK, I understand now, and I think I know whatâs going on. Closer to the opposite of that, really. The two DelayLights donât communicate. Lystimer is turning on the bathroom light in AUTO mode. Nattlys is seeing that light go on, but knows it didnât do it, and more importantly, doesnât know that Lystimer did it, so itâs assuming someone has turned it on manually, and is starting a manual timing cycle. You can probably see this in the timing countdownâthe timing interval remaining is longer than your configured âautoâ delay time. Manual timing is never effected by house mode (by design), only Auto.
There are two things you can do: disable manual timing on Nattlys and Lystimer (set the manual delay to 0). If thatâs undesirable, set the state variable âManualOnSceneâ to â0â in both timers, which will prevent them from turning everything on when one activates the other.
Ok, Iâll try that and see⊠Iâd like the manual timer to work for the bathroom, the night light doesnt need it. Iâll let you know how it works out.
Yeah, ManualOnScene=0 is likely the better solution. Thereâs an argument that it should be the default, but itâs a behavior change from earlier versions, so when I added it, I stuck to prior behavior as the default.
Active Period
Would it be possible to add an option to active period to select another service e.g in active period I would have a drop down selection and I would select day night plugging and value =1 ( or night). So then I let the plugin adjust timings for winter/ summer sunset variables rather than having to manually modify each cycle
[quote=âPrincessCleavage, post:91, topic:198651â]Active Period
Would it be possible to add an option to active period to select another service e.g in active period I would have a drop down selection and I would select day night plugging and value =1 ( or night). So then I let the plugin adjust timings for winter/ summer sunset variables rather than having to manually modify each cycle[/quote]
Reactor was born, in part, because of the increasing demand for tests for triggers and inhibitors in DelayLight.
That said, you donât need Reactor for this scenario; whatâs in DelayLight already will probably suffice. As an example, letâs say you want your DelayLight timer to be active from sunset to 11pm (23:00). To do that, you would first create an âactive periodâ with a start time well before sunset ever occurs at any time of year, and an end time of 23:00 (e.g. active period is 18:00 to 23:00). Then, you make the Day/Night plugin an inhibitor (you may need to check the âinvertâ box to get the right testâI donât remember if Day/Night is tripped during the day, or tripped at night). The effect of the active period and inhibitor is cumulativeâDelayLight will only attempt auto timing during the active period (18:00 to 23:00), but the inhibitor will keep it from timing even during the active period if itâs not yet nighttime (after sunset).
Rgr,
Thanks Rippa
[quote=ârigpapaâ][quote=âPrincessCleavage, post:91, topic:198651â]Active Period
Would it be possible to add an option to active period to select another service e.g in active period I would have a drop down selection and I would select day night plugging and value =1 ( or night). So then I let the plugin adjust timings for winter/ summer sunset variables rather than having to manually modify each cycle[/quote]
Reactor was born, in part, because of the increasing demand for tests for triggers and inhibitors in DelayLight.
That said, you donât need Reactor for this scenario; whatâs in DelayLight already will probably suffice. As an example, letâs say you want your DelayLight timer to be active from sunset to 11pm (23:00). To do that, you would first create an âactive periodâ with a start time well before sunset ever occurs at any time of year, and an end time of 23:00 (e.g. active period is 18:00 to 23:00). Then, you make the Day/Night plugin an inhibitor (you may need to check the âinvertâ box to get the right testâI donât remember if Day/Night is tripped during the day, or tripped at night). The effect of the active period and inhibitor is cumulativeâDelayLight will only attempt auto timing during the active period (18:00 to 23:00), but the inhibitor will keep it from timing even during the active period if itâs not yet nighttime (after sunset).[/quote]
Day/night does not list in the drop down as an option to select as an inhibitor
[quote=ârigpapa, post:92, topic:198651â][quote=âPrincessCleavage, post:91, topic:198651â]Active Period
Would it be possible to add an option to active period to select another service e.g in active period I would have a drop down selection and I would select day night plugging and value =1 ( or night). So then I let the plugin adjust timings for winter/ summer sunset variables rather than having to manually modify each cycle[/quote]
Reactor was born, in part, because of the increasing demand for tests for triggers and inhibitors in DelayLight.
That said, you donât need Reactor for this scenario; whatâs in DelayLight already will probably suffice. As an example, letâs say you want your DelayLight timer to be active from sunset to 11pm (23:00). To do that, you would first create an âactive periodâ with a start time well before sunset ever occurs at any time of year, and an end time of 23:00 (e.g. active period is 18:00 to 23:00). Then, you make the Day/Night plugin an inhibitor (you may need to check the âinvertâ box to get the right testâI donât remember if Day/Night is tripped during the day, or tripped at night). The effect of the active period and inhibitor is cumulativeâDelayLight will only attempt auto timing during the active period (18:00 to 23:00), but the inhibitor will keep it from timing even during the active period if itâs not yet nighttime (after sunset).[/quote]
Rigpapa,
I think that on the DelayLight Plugin, since a lot of these actions rely on sunset and sunrise (because that is when most lighting events will need to happen), it would be most helpful to add those triggers to the active period, much like youâve done in the Reactor plugin with the Sunrise/Sunset condition. This would avoid the need to load yet another plugin to our already overloaded Vera systems. Just an opinion. Keep up the great work!
Rigpappa,
is there a way to synchronize 3 lights on 3 circuits with this plugin? Iâve been racking my brain trying to figure this one out, but havenât been able to. Here is my scenario:
I have lights at the top deck, middle deck, and floor level and they are all on independent circuits. what i want is for all 3 circuits to come on when any one of them turns on (pretty easy with DelayLight), but what i am having an issue with is turning them off when any one of them is turned off. When one light comes on, the others turn on as planed, but since now they all have power, turning one off does not turn the others off.
No biggie if this is not the tool for that, i can code it in Lua if necessary, but just wanted to check
[quote=âsebby, post:96, topic:198651â]Rigpappa,
is there a way to synchronize 3 lights on 3 circuits with this plugin? Iâve been racking my brain trying to figure this one out, but havenât been able to. Here is my scenario:
I have lights at the top deck, middle deck, and floor level and they are all on independent circuits. what i want is for all 3 circuits to come on when any one of them turns on (pretty easy with DelayLight), but what i am having an issue with is turning them off when any one of them is turned off. When one light comes on, the others turn on as planed, but since now they all have power, turning one off does not turn the others off.
No biggie if this is not the tool for that, i can code it in Lua if necessary, but just wanted to check[/quote]
No, DelayLight is pretty hands off with manual off of controlled loads. It only reacts when all of the controlled loads are off, just resetting the timer to idle. Custom Lua or Reactor would be the way to go for your requirement.
[quote=ârigpapa, post:97, topic:198651â][quote=âsebby, post:96, topic:198651â]Rigpappa,
is there a way to synchronize 3 lights on 3 circuits with this plugin? Iâve been racking my brain trying to figure this one out, but havenât been able to. Here is my scenario:
I have lights at the top deck, middle deck, and floor level and they are all on independent circuits. what i want is for all 3 circuits to come on when any one of them turns on (pretty easy with DelayLight), but what i am having an issue with is turning them off when any one of them is turned off. When one light comes on, the others turn on as planed, but since now they all have power, turning one off does not turn the others off.
No biggie if this is not the tool for that, i can code it in Lua if necessary, but just wanted to check[/quote]
No, DelayLight is pretty hands off with manual off of controlled loads. It only reacts when all of the controlled loads are off, just resetting the timer to idle. Custom Lua or Reactor would be the way to go for your requirement.[/quote]
As always, thank you for the reply. Really appreciate the work!
Hi Patrick
Firstly I love you plugin. You did a great job designing it, and the interface is really the part I find most elegant. I currently use a modified version of the Smartswitch plugin as my daily driver for managing automated lights. Lost of the code in there was modified by myself. I do quite a bit of setup these days for other people and find your plugin just to be much better to configure and maintain. It does almost everything I need to change over to DelayLight being my own daily driver⊠almost.
The one feature I use quite extensively through the use of scenes, is the ability to set the smartswitchesâ dim levels. The use case for this is quite simple. during late nights, certain lights still react to triggers form sensors, but to be kind to late night eyes, they are dimmed quite lowâŠ
I can think of a two of ways to achieve this with DelayLight, but none of them seem elegant:
[ul][li]Use duplicate duplicate timers. and only enable the right ones. Messy clutter.[/li]
[li]Set dim levels outside of Timers. Most of my lights go full power when binary on is received, instead of last level. they are not actually z-wave⊠limitation of interface.[/li][/ul]
The fix on face value would be quite simple (expose an action on the timer that facilitates this), until you think about the one feature that really distinguishes DelayLight from SmartSwitch. The ability to include multiple devices for ON/OFF control. The only idea I could think of is to have a âglobalâ ON dim level, and OFF dim level as part of the plugin, and leave the individual nodes dim levels empty. Then have an action that can set these variables. Not sure if this is elegant or practical.
So in conclusion. If you have any ideas how to do this either with an elegant workaround, or code, let me know. I am happy to tackle the code and design, and contribute to your Git Repo, but would not want to write anything that you donâtâ consider useful of appropriate. I also donât like making my own branches, as that generally leaves me without future enhancements 
Regards
Tiaan
[quote=âtiaanv, post:99, topic:198651â]Hi Patrick
Firstly I love you plugin. You did a great job designing it, and the interface is really the part I find most elegant. I currently use a modified version of the Smartswitch plugin as my daily driver for managing automated lights. Lost of the code in there was modified by myself. I do quite a bit of setup these days for other people and find your plugin just to be much better to configure and maintain. It does almost everything I need to change over to DelayLight being my own daily driver⊠almost.
The one feature I use quite extensively through the use of scenes, is the ability to set the smartswitchesâ dim levels. The use case for this is quite simple. during late nights, certain lights still react to triggers form sensors, but to be kind to late night eyes, they are dimmed quite lowâŠ
I can think of a two of ways to achieve this with DelayLight, but none of them seem elegant:
[ul][li]Use duplicate duplicate timers. and only enable the right ones. Messy clutter.[/li]
[li]Set dim levels outside of Timers. Most of my lights go full power when binary on is received, instead of last level. they are not actually z-wave⊠limitation of interface.[/li][/ul]
The fix on face value would be quite simple (expose an action on the timer that facilitates this), until you think about the one feature that really distinguishes DelayLight from SmartSwitch. The ability to include multiple devices for ON/OFF control. The only idea I could think of is to have a âglobalâ ON dim level, and OFF dim level as part of the plugin, and leave the individual nodes dim levels empty. Then have an action that can set these variables. Not sure if this is elegant or practical.
So in conclusion. If you have any ideas how to do this either with an elegant workaround, or code, let me know. I am happy to tackle the code and design, and contribute to your Git Repo, but would not want to write anything that you donâtâ consider useful of appropriate. I also donât like making my own branches, as that generally leaves me without future enhancements
Regards
Tiaan[/quote]
If I understand correctly, your goal is to have different light levels for controlled loads at different times of day; a typical use case is full brightness during the day, reduced brightness at night. I do this myself in several bathrooms in my houseâe.g. motion sensors turn on âmainâ lighting when motion is first detected, full bright during the day on two lights, and 30% on a single light at night. When no motion is detected for a period, all lights are extinguished.
I use an âonâ scene with scene actions to set up the âdaytimeâ scene: vanity lights and recessed fixtures set to 100% on. Then I add scene Lua code like this for the night exception:
if luup.is_night() then
luup.call_action( "urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", { newLoadlevelTarget=30 }, 66 ) -- undercabinet LED strips
return false
end
return true
So, if the night test in the Lua code fails, the scene Lua returns true, so Luup runs the scene actions normally. If the night test succeeds, the scene Lua directly sets just the toe-kick LEDs to 30%, and then returns [tt]false[/tt]. The scene actions are not run by Luup when scene Lua returns [tt]false[/tt] (so the vanity and ceiling lights are not turned on).
The second part of this is setting up the DelayLightTimer instance so that the âoff listâ contains all of the lights in the bathroom (shower, vanity, recessed, and WCâyou donât need an âoffâ scene, just list the devices explicitly in DelayLightâs config). This ensures that when the DelayLight timer expires, all lights in the room are turned off (including any additional lights turned on manually). In addition, the automatic and manual timing intervals should be set to the same value (I use 3600 = 1 hour).