Plugin: DelayLight

[quote=“rigpapa, post:100, topic:198651”]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).[/quote]

Thx Patrick

That could work, but it’s going to require me to set up approximately 14 additional scenes… and then maintain the “exceptions” in each of those… Not something I think will be an improvement on the current mechanics. I appreciate the advice though! I might tinker with your plugin code for my own use if you don’t mind.

T

I use a small bit of code in my triggers for night only triggering.
return luup.is_night() == true

It seems to work right as the sun is going down any time of the year with a vast time change on sunset.
Maybe the addition of this or similar codes for triggers would be a viable and efficient way to trigger when you want?

BTW, thanks for this add on as I do love it. I made a small donation today. Have a beer on me!

I’d love to be able to reset the load level for lights that are turned on/off by DelayLight. for example, i have a bunch of lights that get turned on by motion sensors (depending on house mode and other conditions using your Reactor Plugin). one of the conditions is that if it is after midnight, i typically dim them down a bunch so as not to blind the wife. the problem is that when they get turned off by DelayLight, they dimmers remember their last setting.

Could you add a LoadLevelStatus field for when lights are turned off? maybe even just a checkbox that allows people to enter the load level in the existing box and if it is unchecked (by default), you do a SetLoadLevelTarget turning them on OR if unchecked, then you do a LoadLevelStatus that way they are reset for the next time?

[quote=“sebby, post:103, topic:198651”]I’d love to be able to reset the load level for lights that are turned on/off by DelayLight. for example, i have a bunch of lights that get turned on by motion sensors (depending on house mode and other conditions using your Reactor Plugin). one of the conditions is that if it is after midnight, i typically dim them down a bunch so as not to blind the wife. the problem is that when they get turned off by DelayLight, they dimmers remember their last setting.

Could you add a LoadLevelStatus field for when lights are turned off? maybe even just a checkbox that allows people to enter the load level in the existing box and if it is unchecked (by default), you do a SetLoadLevelTarget turning them on OR if unchecked, then you do a LoadLevelStatus that way they are reset for the next time?[/quote]

DelayLight has a dim level field for the “off” list. Can you check the version number on the Settings tab (in the footer). You should be running 1.8. If so, am I missing some detail of the way you want it to work?

Yes, running 1.8. The issue i have is that the dim level on the “off” list does a SetLoadLevelTarget call which turns ON the lights to that load level. what i am trying to accomplish is to turn OFF the lights and return them to a brighter default load level (LoadLevelStatus) so the next time someone hits the switch they are not at the dim level that was used by delay light.

[quote=“sebby, post:103, topic:198651”]I’d love to be able to reset the load level for lights that are turned on/off by DelayLight. for example, i have a bunch of lights that get turned on by motion sensors (depending on house mode and other conditions using your Reactor Plugin). one of the conditions is that if it is after midnight, i typically dim them down a bunch so as not to blind the wife. the problem is that when they get turned off by DelayLight, they dimmers remember their last setting.

Could you add a LoadLevelStatus field for when lights are turned off? maybe even just a checkbox that allows people to enter the load level in the existing box and if it is unchecked (by default), you do a SetLoadLevelTarget turning them on OR if unchecked, then you do a LoadLevelStatus that way they are reset for the next time?[/quote]

OK. I’ve poking at this a bit.

If Vera was following UPnP, I would be able to set [tt]LoadLevelTarget[/tt] in the Dimming1 service and have the light restore to that value if switched on with SwitchPower1. But that doesn’t work. As we know, doing the [tt]SetLoadLevelTarget[/tt] action on Vera turns the light on, so that’s a no-go already. I tried [tt]LoadLevelStatus[/tt] also, knowing it wouldn’t work but just trying, and sure enough, doesn’t work.

Vera has mysteriously added a [tt]LoadLevelLast[/tt] variable to the Dimming1 service, which they just kludged in apparently without (a) actually adding it to the Dimming1 service definition, or better yet, not mucking with a standard UPnP service definition and putting it in a service of their own, or (b) actually just using [tt]LoadLevelTarget[/tt] for the exact same purpose, which would make more sense and be more consistent with UPnP. But I can set [tt]LoadLevelLast[/tt] to a value, and if I follow that with a [tt]SetTarget[/tt] action (SwitchPower1 service; not the [tt]SetLoadLevelTarget[/tt] action in the Dimming1 service) to turn the light on, it goes to dimming level last set [tt]LoadLevelLast[/tt].

I’ve also only tested this with two dimmer brands, since I currently only have two brands in my house, and while it works for both, behavior differences between brands have been noted in the past.

I’m pondering the wisdom of using an undocumented feature of Luup as a feature of DelayLight, and not warming up to the idea yet. I’ve pushed the envelope a bit with things in Reactor, but everything I’ve done there can be referenced to the wiki (using things that are mentioned by name but otherwise not described, for example). [tt]LoadLevelLast[/tt] isn’t even mentioned in the wiki anywhere that I could find–even if just mentioned, at least it would give me some comfort that it’s an implementation decision by Vera that’s likely to stick. This is also a variable that Luup manipulates internally, and the conditions under which, and timing of when that happens, is also uncertain and subject to change. And especially now that they are “rewriting” (or have rewritten) the Luup/Lua part, it seems likely that anything not documented may not be reproduced in upcoming firmware–it’s very difficult to reproduce years worth of accumulated behavior into a rewritten subsystem in just a couple of months, so that fact alone gives me concern that a lot of documented things will change (and take months to resolve), let alone anything undocumented, which we may likely never see reproduced again.

So for the moment, I’m going to decline to add this as a feature of DelayLight, but I’ll keep it open for future consideration. What I can recommend to you for now is that you go ahead and use this “feature”, knowing it may stop working in future firmware, but at least it addresses the problem for you now. You can just set up a scene trigger on that light so that any time it’s turned off, it runs scene Lua to set [tt]LoadLevelLast[/tt] (service [tt]urn:upnp-org:serviceId:Dimming1[/tt]) to the default you want.

luup.variable_set( "urn:upnp-org:serviceId:Dimming1", "LoadLevelLast", 100, dimmer_device_num )

thanks, like everything with Vera nothing is just easy. i had been mucking with a scene and LoadLevelStatus, but could not get it to work. I will try with LoadLevelLast and see what happens. Anyhoo, thanks for the consideration.

K, i added a variable_watch for LoadLevelStatus and set the LoadLeveLast to 100 when Status goes to 0, works like a charm for now, but we’ll see when they pull the plug on that variable. Thanks for looking into it.

Just started using this great plugin, and I’m finding the same, Day/Night plugin is not visible in the drop-down selection for the inhibitors.
Is there a workaround for this yet?
I’m on version 1.8.

[quote=“PrincessCleavage, post:94, topic:198651”][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]

[quote=“bruring, post:109, topic:198651”]Just started using this great plugin, and I’m finding the same, Day/Night plugin is not visible in the drop-down selection for the inhibitors.
Is there a workaround for this yet?
I’m on version 1.8.

[quote=“PrincessCleavage, post:94, topic:198651”][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][/quote]

The Day/Night plugin implements its own device type, which is neither a binary switch nor a sensor (and therefore will not be listed as an inhibitor). So, you’ll need to have a virtual sensor or virtual switch track the state of that plugin. You can then use the virtual device as an inhibitor.

[quote=“rigpapa, post:110, topic:198651”][quote=“bruring, post:109, topic:198651”]Just started using this great plugin, and I’m finding the same, Day/Night plugin is not visible in the drop-down selection for the inhibitors.
Is there a workaround for this yet?
I’m on version 1.8.

[quote=“PrincessCleavage, post:94, topic:198651”][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][/quote]

The Day/Night plugin implements its own device type, which is neither a binary switch nor a sensor (and therefore will not be listed as an inhibitor). So, you’ll need to have a virtual sensor or virtual switch track the state of that plugin. You can then use the virtual device as an inhibitor.[/quote]

I installed the binary switch plugin and that did it! Thank you.

Just come across this, agree this will be great instead of using pleg as its a high use case. Looking forward to getting stuck into using this.

It looks like you can only set an active period between times, it would be great to be able to set the time based on X mins after sunset (or sunrise). I’m looking to use this to only trigger lights when its dark and that changes each day (it might be I’ve missed something in the settings that would enable that).

Great work.

[quote=“mzpost, post:112, topic:198651”]Just come across this, agree this will be great instead of using pleg as its a high use case. Looking forward to getting stuck into using this.

It looks like you can only set an active period between times, it would be great to be able to set the time based on X mins after sunset (or sunrise). I’m looking to use this to only trigger lights when its dark and that changes each day (it might be I’ve missed something in the settings that would enable that).

Great work.[/quote]

Requests like this are exactly how Reactor came to be.

Haha Ok thanks, so now I’m downloading reactor.

The delaylight plug in is excellent by the way, really good work. I’ll be supporting your devevelopment.

I noticed that during the operation of the plug-in there are moments when not a single light bulb is on for a long time.
It would not be bad to be able to choose one constantly burning lamp.
Or did I overlook something? 8)

[quote=“opel-oleg, post:115, topic:198651”]I noticed that during the operation of the plug-in there are moments when not a single light bulb is on for a long time.
It would not be bad to be able to choose one constantly burning lamp.
Or did I overlook something? 8)[/quote]

Are you referring to DelayLight or DeusExMachinaII here? Sounds a bit like maybe the latter…? Or am I just short on clue today…?

Oops))) I saw the word familiar.
The light flashed in the window.))) Of course DeusExMachinaII
Sorry for not sending you there.

Oops))) I saw the word familiar.
The light flashed in the window.))) Of course DeusExMachinaII
Sorry for not sending you there.[/quote]

No problem. I’ll reply briefly here, and if there’s anything more, let’s take it over here.

I’ve also noticed this, but haven’t acted on it yet. I’ve added Github issue #32 for this. I was working on Deus earlier this week. I don’t think I’m ready to release yet, but I’ll make sure this is addressed before I do.

Hi rigpapa

A few years ago, I was battling how to tell if a light has been turned on automatically by movement or manually at the switch. I solved it using a PLEG and it has served all my lighting requirements for a long time.

When I came across your thread, I thought WoW this is exactly what I need to get rid of a lot of complicated PLEG expressions and make my VERA run a little bit more smoothly (hopefully). So I bypassed my Internal Light PLEG (and External Light PLEG) and replaced them with your DelayLight Plugin. I have been running like this for a few weeks, but have reluctantly now gone back to my PLEG solution.

I have been “fighting” my lights. i.e. I turn my kitchen light off and your plugin immediately turns it back on or vice-versa. I never had this problem with my PLEG solution.

I am the first to admit my logic is basic, but the following was built on practical evaluation. Somewhere there is a key difference between what you are doing and what I am doing in PLEG. It makes me sad to go back to PLEG and would much rather use your solution. If you would comment so I can use your Plugin without any problems, I would be very happy.

I have four conditions in a PLEG;-

  1. cLightOn = VERA turns the light on automatically by movement at night
  2. cManualOn = The light has been turned ON manually by a person
  3. cLightOff = VERA turns the light off automatically
  4. cManualOff = The light has been turned OFF manually by a person

After much experimenting, I used the following expressions for each of the above;-

  1. cLightOn = (cManualOff ; tMotion > 10:00) AND !tLightOn AND tNight AND tMotion AND (!tLightOn ; tMotion)
  2. cManualOn = tLightOn AND !(cLightOn ; tLightOn < 10 )
  3. cLightOff = tLightOn AND !tMotion AND (!tMotion ; NOW > 3.00) AND (!cManualOn OR (tLightOn ; NOW > 29:00))
  4. cManualOff = !tLightOn AND !(cLightOff ; !tLightOn < 10 )

To look more closely at each;-

  1. cLightOn = (cManualOff ; tMotion > 10:00) AND !tLightOn AND tNight AND tMotion AND (!tLightOn ; tMotion)

This means automatically turn the light ON, when ALL the following are TRUE;-

• (cManualOff ; tMotion > 10:00) = It is at least 10 minutes since the Light has been turned off at the switch
• !tLightOn = NOT LightOn i.e The Light is currently OFF
• tNight = it is dark (defined elsewhere)
• tMotion = The room is occupied
• (!tLightOn ; tMotion) = Motion AFTER the time that the light went OFF (!=NOT)

This last condition was necessary to prevent the Light being immediately turned back on after I turn it off manually. My light switch is within range of the motion sensor, so tMotion will be True, but its time stamp will be BEFORE the time the light was turned off. This prevents the light being turned back on until new motion AFTER the light has been turned off)

  1. cManualOn = tLightOn AND !(cLightOn ; tLightOn < 10 )
    The expression in brackets is true if the light turns on less than 10 seconds after a command to turn the light on automatically. It is then likely to be an automatic On. The “!” negates that, so the Light is ON but it was turned on manually.

  2. cLightOff = tLightOn AND !tMotion AND (!tMotion ; NOW > 3.00) AND (!cManualOn OR (tLightOn ; NOW > 29:00))

This will turn OFF the light, when ALL the following are TRUE;-

• tLightOn = The Light is ON
• !tMotion AND (!tMotion ; NOW > 3.00) = there is NO motion NOW and the last motion was more than 3 minutes ago
• (!cManualOn OR (tLightOn ; NOW > 29:00)) = Turn light OFF when AUOMATICALLY turned on, 3 minutes after last motion
OR after 29 mins if turned on MANUALLY (plus more time if motion continues).

  1. cManualOff = !tLightOn AND !(cLightOff ; !tLightOn < 10 )
    This works out if the Light has been turned OFF manually in a similar to the Manual On above

To summarise:-
A Light turned OFF manually will not come back on for at least 10 minutes
A Light turned ON manually will stay on for at least 29 minutes, and will stay on while motion continues; only turning off 3 minutes after motion ceases, and I get no “fighting” problems.

What I really need to see is your DelayLight configuration. On the bottom of the Settings tag is a “Plugin Status” link. Please PM me that output (do not post it in this thread–PM directly to me) and I’ll take a look.