Plugin: DelayLight

Plugins & Plugin Development General Plugin Discussion
1

DelayLight is my version of a time-delay light/load control. It will turn off a configured set of lights after a delay period, optionally using one or more sensors to determine presence. Sensor triggers can also turn lights on. Sensor-based triggering turns lights on for an automatic timing interval, while manual activation of a light uses a separate manual timing interval.

I wrote this plugin in late-2017 when I had to rebuild my Vera configuration from scratch, and I decided not to use the same approach I had used for years prior. Until now, this plugin was just a tool I kept for my own use, and it didn’t even have a UI–it was configured by directly manipulating its state variables. But recently, some of the older plugins that implemented this kind of functionality seem to have lost their maintainers and their future has become less certain, so I decided to package up my expression of a solution for public use.

The GitHub repository for this project is here: [url=https://github.com/toggledbits/DelayLight]https://github.com/toggledbits/DelayLight[/url]

Documentation for the project is also found in its GitHub repository. Please post issues or questions in this thread.

DelayLight can be installed from the Vera plugin marketplace (search “DelayLight” with no space between words), or using the AltAppStore (ALTUI users).

DelayLight is free to use, and if you find it useful, please make a small donation to support its ongoing development.

REVISION HISTORY
Note: You can always see the current release info and latest changes by looking at the CHANGELOG.md file in the Github repo.

2019-08-25: Version 1.12. Fixes an issue with schedules and inhibit devices disabling manual mode. See the changelog (linked above) for details.

2019-06-08: Version 1.11. Works around issue where Luup creating variables from SwitchPower1 service on a lock makes luup.device_support_service() report that the device supports SwitchPower1, which is doesn’t.

2019-05-28: Version 1.10: Adds trigger quieting (see docs) and supports locks as triggers.

2019-01-07: Version 1.8. Fix for Monoprice switches that advertise themselves as dimmers but don’t dim; full wait for Z-Wave ready before initializing for better acquisition of device states after power failures; additional small bug fixes.

2018-08-19: Version 1.7. This version fixes a deployment error in posting 1.6 to the Vera Plugin Marketplace that was creating problems for fresh installs. Users of AltAppStore/openLuup are not affected, and there are no changes to the code of this release.

2018-08-05: Version 1.6 released. This version allows devices that implement SwitchPower1 to be used as inhibitors, and corrects a bug in the initialization of inhibitor tests.

2018-07-29: Version 1.5 released. This version allows the timer to not turn on lights if there’s an “on” delay and the trigger sensors all reset before it expires; handles change in load level to a dimmer that is already on as a manual trigger; adds ability for manual-on to not “set scene” by turning on all “on” list devices, just leave everything under manual control. See the Github repo’s CHANGELOG.md for more detail on these changes.

2018-07-02: Version 1.4 has been released to the Vera Plugin Marketplace and AltAppStore. This version fixes a bug in “Mode 2” timer restrictions (don’t start timing until all triggers have reset).

2018-06-24: Version 1.3 has been released to the AltAppStore and Vera Plugin Marketplace. See changelog.

2018-06-11: The “stable” branch of DelayLight has been enhanced to add Inhibit devices and active time periods. There is no UI for these functions yet, so you’ll need to edit state variables if you want to try them. Also, if running on openLuup, this version checks to make sure you’re not using a version of openLuup that a child startup bug.

2018-04-12: A beta version based on 1.2/1.3dev is available for openLuup and installable using the AltAppStore.

2018-03-19: Version 1.2 is now available in the Vera plugin marketplace. This version creates timer devices as children of the parent controller device, making it a single-instance plugin in which all timers share the same code. This should result in a much smaller in-memory footprint for systems with lots of timers (I have 16 in 9 rooms, for example). A single Luup timer/delay task is used as well, so it’s very resource-efficient.

2018-02-26: Version 1.1. This was a maintenance release that includes some code cleanups and an extension of the status interface for additional reporting when needed. Status reports are user-initiated by requesting [url=http://your-vera-ip/port_3480/data_request?id=lr_DelayLight&action=status]http://your-vera-ip/port_3480/data_request?id=lr_DelayLight&action=status[/url]

2018-02-19: Version 1.0 has been released in the Vera plugin marketplace.

2

I like the idea. I use PLEG for this today, but having an easier way to automate lights would certainly speed adoption. I agree this is such a common use case that Vera really should have this as a built-in module.

In your design, would you have a copy of the plug-in for every room with automatic lights? I have at least 13 “rooms” with automated lighting, around 17 switches, with full on-off functionality. Plus a few more switches that are automatic off only…

3

My own production install has these spread all throughout the house. Most bathrooms have at least two: lights and fan. My master ensuite has five (main lights (for 5 dimmers), shower light, WC light, WC fan, main fan).

I also used PLEG (four licenses worth), but I decided to not include it in my configuration when I did a full rebuild a few months ago.

4

@wilme2, I took your inquiry as a suggestion, since these timers have a way of multiplying like rabbits (keep on coming up with ideas/uses around the house).

I will be releasing v1.2 of the plugin this weekend, for Vera’s marketplace approval on Monday 3/19, that is a single-instance version: one copy of the plugin for as many timer child devices as you want to create. Existing devices from prior versions will be converted to children with settings copied.

5

A beta version for openLuup is now available for installation via the AltAppStore.

6

Great work Rigpapa

Is there a way to only activate the lights/load if it’s night time.

7

Working on it

8

G’day rigpapa

Your plugin sounds fantastic, especially that it is lean and mean given Vera’s limited resources, so I have just installed your plugin and done the following:

[ol][li]Clicked the Control Panel[/li]
[li]Clicked Add Timer[/li]
[li]Waited for the process to complete[/li]
[li]Gone back to my devices list and found the new DelayLight Timer[/li][/ol]

I have then:

[ol][li]Edited its Device name and assigned room, then clicked Saved Changes[/li]
[li]Gone back to the devices list and found no change[/li]
[li]Refreshed, still no change[/li]
[li]Repeated the editing and save[/li]
[li]Repeated the refresh[/li]
[li]Continued to repeat[/li][/ol]

I haven’t done anything else, nor have I installed anything else - clean vanilla Vera but with a crapload of Fibaro dual switches and Fibaro dimmers. Hoping you might spot something obvious I have overlooked…

9

Okay that’s weird… I tried setting just the room and saving, it moved. I then edited the name and saved, it worked.

So I added a second timer and edited both in one shot - also worked.

Looks like my nice clean Vera wasn’t playing nice after all.

Have configured the two test ones up. One of those rooms the light is already on, so the timer has started itself. VERY nice touch with the animated hourglass :slight_smile: :slight_smile: :slight_smile: :slight_smile:

10

Okay I have 16 set up and working great - though strangely many settings had to be set multiple times to stick, but probably because I was ploughing through them.

Only run into one drama. I have a dimmer light that is triggered by two different sensors - no worries. That dimmer is set to retain its dim level, as I have various scenes that will automatically set a relevant dim level at relevant times. Works fantastic because the sensors and events simply turn the dimmer on and it comes on at its existing dim level.

However, when I use DelayLight to control this dimmer it insists on a dim level. I don’t actually want the dim level touched, I just want it turned on or off. Can that be done - do I set the dim level to -1 or leave it at 100 to simply turn on, (as full brightness is actually 99), or will DelayLight specifically set a dim level?

Cheers!

11

I’ve noted some interesting intrinsic behavior in UI7 API response with respect to moving off the control panel pages, and that could be related. But more likely, the cause is simply that the plugin UI causes a reload when devices are changed in the configuration (watches, etc.) at the time you return to the dashboard. Timing parameter changes, on the other hand, are more easily handled on-the-fly and do not cause this reload. So, I’m guessing that you were probably running through the interface a little faster than UI7 and Vera could actually deal with while the reload was happening.

On the dimming level, DelayLight specifically sets the dim level as you’ve discovered, but I see your requirement. I think most users believe 100 is full brightness, so I think the option to leave the dimming level field blank and have that treated as “on without level change” (for “on” list devices) seems best. What do you think about that?

12

Mate I am really loving this plugin - it is fantastic in absolutely every regard, seriously well done! As I said I have 16 of them set up now and they are awesome!

Setting the dim level blank to instead have a binary on would be perfect, yes. This would enable me to configure my two multi-sensors into that DelayLight, presently it’s just reacting to the initial “on” which is sort of working but also causing some issues with the sensors being out of sync with one another. If I could add them both in as a trigger without causing the dim level to change that would be awesome!

I have also thought of two other great uses for this plugin, but would depend upon your release notes commenting consideration of monitoring other parameters:

  1. I would like to react to power consumption of smart switches. So if power usage drops below a certain threshold then the DelayLight kicks in, and only after it stays below that level for a certain amount of time would something be triggered. At the moment best I can think is a scene that detects wattage dropping below a certain level, and using that to trigger the DelayLight, but I’m not sure I want the potential of repetitive scene triggers. Still thinking about this, but the ability to react to the wattage parameter might be cool.

  2. Of more importance, I will be reacting to the door lock on my other home. I have pre-set a scene for this already, so if the door is unlocked then the DelayLight is triggered. So it’ll already work once I get out there with a smart switch - whenever the front door is unlocked the smart switch will activate for 36 hours, and presumably if the door is unlocked again during that 36 hours and the scene triggers again then the re-trigger of the DelayLight will restart the countdown? Thus the smart switch will automatically be on so long as anyone has come - so should work with existing capabilities, but another area where your thoughts of being able to use other parameters could be helpful… as the DelayLight could directly react to the door lock without the use of a scene?

13

It always was my plan to have DelayLight react to a much wider range of devices than just those that implement SecuritySensor1 as it does now. I actually had that written and was testing it for version 1, but I started to wonder why I should go to the trouble if scenes can be used to trigger DelayLight out of the box. Given that and the considerable additional complexity, I chose to stash that code and go with the simpler trigger path for version 1, put it out there, and see what happens. I think scene-based triggering works fine, although I can also see that it may add some complexity for the user by de-coupling the trigger decision away from DelayLight’s configuration, rather than having it all in one place. I’m still weighing benefits and costs there. DelayLight, in my mind, has a clear raison d’etre: to be very simple, light-weight and reliable step between the void that Vera has left for this use case (reliable on/off delay of a load), and the considerable weight and complexity introduced by PLEG (it’s awesome, but a big solution for this small problem). That keeps me tipping the scale toward the simple solution of using a scene (with or without Lua), which leverages a well-established, existing interface for creating a trigger response when DelayLight’s simple intrinsic capability doesn’t do enough. The things that leaves unaddressed that concern me, though, are (1) many devices have considerably more triggerable conditions than the current scene logic/eventList2 structures define, (2) AND vs OR of conditions in scenes, and (3) hysteresis (e.g. trigger when value goes below X, but don’t reset until value goes above Y, where Y > X, and maybe a time component as well, which may address your retrigger concerns).

On your door lock scene, yes, every time your scene “triggers” DelayLight, the timer will restart, so every unlock of your door will stretch the delay out to 36 hours beyond that event as you’ve configured it. Should work fine.

14

Completely agree - I would prefer configuration not be spread everywhere yet at the same time given Vera’s, shall we say, limitations I would prefer even more that DelayLight remain lean and mean.

The door lock situation I’m confident will work fine, the smart switch I’ll do some testing and see how it goes :slight_smile:

15

I’ve been evaluating DelayLight on my test VP running 1.7.3798 and it does exactly what it says it does. I’ll be installing it on my production system (VP running 1.7.3232—it’s stable and does what I need) and replacing the workarounds or Vera delays I’ve used to get this function.

While I can envision some other features/functions, I’m strongly drawn to the idea of lightweight and simple. Thanks for doing this!

16

Your comment is both flattering and helpful! :slight_smile: I’m a bit shy about upgrading my firmware these days, so knowing you’re successful on 3798 is a big help in several ways. Also, I’m always open to ideas, so I’d love to hear your thoughts about features and functions.

17

I’m grateful that you are developing some extremely useful plug-ins. Since I have a test VP, I’ll be glad to test for you (assuming it doesn’t require hardware I don’t have.) I typically upgrade the test system as soon as new software is announced to try and help the community with a thumbs-up or thumbs-down.

And, yes, as you noted, my production machine is on 1.7.3232 from last October due to the same nervousness. :wink:

18

Upgraded to 1.7.3831 just now and all is well. :smiley:

19

Good work on the plugin, rigpapa. This plugin will be of interest to anyone who has been using my old Countdown Timer plugin (which AFAIK still works on recent firmwares but which I’m not making any updates for). My plugin was designed to be the barest of barebones in adding timers to the Vera scene-and-device model, a sentiment that seems to coincide with your approach. Do feel free to cannibalize any features or code from the Countdown Timer that help you.

20

And thanks to you for Countdown Timer. It works on 1.7.3232—I use it to build digital filters for energy usage. Simple and works well.