OK. Not seeing your config but drawing on your description of the problem… version 1.10 is now released, and includes a new feature called “trigger quieting”. The quieting period is a “dead time” during which the triggers are ignored if all lights are turned off manually. This ensures that any motion event that occurs as you leave the room does not cause automatic triggering and bring the lights back on (only a problem for certain sensor configurations and room configurations, but also not rare–surprised it took this long for it to come up).
Hi Rigpapa, I came home today after a short break, bypassed my PLEG & re-instated your plug-in to send you that config, but for the life of me I couldn’t reproduce the fault. After I read your post, I know why! Thanks, the dead time variable has done the trick! Quick work and much appreciated.
One last question, I have set the holdover mode to option (2) “do not start the timer until triggered sensors reset”. I don’t want the light to go off if I come back into the room, so will the timer be abandoned if motion re-occurs?
No problem. The default for quieting is 0 (seconds), which is consistent with how previous versions would operate, so if you’re not able to reproduce your specific condition and quieting is 0, you’re probably just getting lucky (the timing of the motion sensor’s messages to the Vera factor in and can make for some non-obvious state transitions). So you may still need to experiment there a little and probably move quieting up to a few seconds.
The default mode will work, you don’t really need mode 2. Any motion sensor trip restarts/extends the timing period. It won’t hurt, but I’m guessing your motion sensors have pretty quick resets (which is why you were having the original problem), so the effect of mode 2 is minimal.
Garage Door Left Open Notification
Hi rigpapa,
I followed your Github instructions to add a door left open notification;-
1. Create a new timer device (see Adding Timers above);
2. Set the automatic timing period to 5 seconds, and the manual timing period to 0;
3. Set the trigger device to your garage door open/close sensor;
4. Set the “on” delay to the limit (in seconds) that the door is allowed to be open (e.g. 1800 = 30 minutes);
5. Go back to the Control tab, and hit the Notifications tab (you may need to scroll to see it);
6. Add Notification for: Timing State Changes
7. State: device starts off-delay timing
8. Select the users to receive notifications, then hit Add.
9. Use the “Back” button in the tab strip (not your browser’s “back” button) to exit configuration for the timer–this will cause a Luup reload.
10. Once Luup has reloaded, make sure your new timer is enabled, and give it a try.
But when I open VeraAlerts and tab into “Configure Notifications” (as per Richard Scheafer’s instructions Vera Alerts - Vera Plugin for Notifications), I get this error;-
VERA IP address says
Trigger Description error: SyntaxError: Unexpected identifier
When I remove your notification, I don’t get any error in VeraAlerts?
I would say that’s something to be worked out in VeraAlerts.
Ok rigpapa, I’ll do that 
Installed 1.10 today and added my door lock as an automatic trigger but… it doesn’t seem to work. How is this supposed to work? When I unlock the door, I was expecting the light to turn on and visa versa but maybe I’ve missed something?
Interesting. So it looks like the new firmware sets Target and Status in the urn:upnp-org:serviceId:SwitchPower1 service on the lock device initially, and then does not update them. The lock service (urn:micasaverde-com:serviceId:DoorLock1) has its own Target and Status that do operate correctly, and this is what locks have always used. But the addition of the two SwitchPower1 variables makes luup.device_supports_service() think the device now supports SwitchPower1, so when DelayLight is evaluating the device for how to trigger from it, it first sees the SwitchPower1 service implemented on the device, and so sets up to watch it as a switch (using Status in SwitchPower1) rather than a lock (Status in DoorLock1). Then, because the firmware does not update those SwitchPower1 variables after creating them, DelayLight never sees the lock changing state.
I can work around this easily in DelayLight, but it’s a firmware bug (two bugs, actually). Stay tuned…
EDIT: Interesting… it does update those variables, but not immediately when the lock changes state… seems to be when it polls the device… that’s even stranger…
Edit 2: bug report
OK. Workaround is up in stable branch on Github. You only need to install the L_DelayLight1.lua file (right-click and choose “Save Link As…” to download, then upload it to your Vera and reload Luup).
Edit: also, just FYI, I have for some time been chasing an issue in 7.0.29 with my Schlage BE469 where the status is not reflected immediately when the lock is operated manually (e.g. by the handle, not using Vera UI or the lock’s keypad). I haven’t fully developed that bug report yet because I’m trying to resolve an inconsistency: sometimes it works (immediately) and sometimes it doesn’t. It seems like it’s related to non-use of the lock for an extended period, like perhaps the lock is going into a low-power/sleep mode. Anyway, be aware, your mileage may vary when relying on lock status; there be monsters there.
Version 1.11 is now released for all platforms/stores. This version works around an issue with lock implementation that causes locks to be seen as switches, even though they can’t be controlled like switches. Only users with the need to trigger DelayLightTimers from locks need to update to this version. It is otherwise the same as 1.10.
rigpapa, first of all Thank You for creating yet another great piece of software for the benefit of our community! Is it possible to trigger a DelayLight instance using a scene?
My Linear garage door opener has a built-in sensor and doesn’t appear in the list of “trigger” devices to choose from in DelayLight. I created a scene that will return true whenever the door is opened; I want to use this as the trigger for a DelayLight, with my ultimate goal being to use your tutorial on the github README for an alert if the garage door is left open for X minutes.
If you can’t use the garage door sensor as a trigger directly, the Github cookbook won’t work–it relies on direct status from the sensor. I recommend using Reactor, which can provide the full solution to your problem (it has the ability to time-delay a response–see the tutorial videos) with a more comprehensive triggering capability.
Also, is your garage door sensor listed as a separate child device of a parent garage door control? If so, please go in to the Advanced tab on the device control panel, and reply here with the values from device_type, categogory_num, and subcategory_num.
The linear garage door opener essentially acts as a light switch . I do not see it as a child device.
device_type: urn:schemas-upnp-org:device:BinaryLight:1
category_num: 32
subcagegory_number: 0
If it doesn’t expose the sensor as a child device, you can’t use it as a trigger directly. Do you know where it writes the sensor state?
The sensor state is basically a switch status. It writes to ‘Status’ and ‘Target’ like most other switches I think.
OK. You can’t use a switch status as a trigger in DelayLight, and I think it would be too dangerous for me to enable that behavior without making people think about it–the possibility for creating logic loops due to a misunderstanding about what device needs to go in what field is high, and the results would be tragic.
You have some options, though. Two that immediately come to mind:
- Install Reactor, and create a ReactorSensor that merely tracks the state of the Status variable. ReactorSensors are implemented as binary sensors, and binary sensors are exactly what DelayLight wants in the trigger list. Now, that’s a big bat to hit the problem with, but on the plus side, it has myriad other uses, I think you’ll find.
- Install VirtualSensor. The current version of VirtualSensor allows you to create a virtual binary sensor whose value is copied from or matched to any state variable on any other device, so you can do what Reactor would have done above “on the cheap” by just having your virtual binary sensor copy its state directly from the garage door’s Status variable (which is also a binary value). You can then use this virtual sensor as a trigger in DelayLight. While VirtualSensor is more limited in its utility, this is exactly the kind of problem it’s intended for, and it’s a trivial plugin–very light weight.
1 Like
Thanks rigpapa. I had already gone down the path with both of your plugins for several other automations and indeed it is an easy solution using Reactor and VirtualSensor .
I just came across this thread and saw that it was left open and wanted to share how the Linear garage door openers are configured.
1 Like
Version 1.12 is now released for all platforms. This addresses an issue discovered by @HSD99 where inhibitors and schedules would disable manual mode. The documentation clearly states that manual mode is always operative. If your configuration relies on the bug (disabling manual mode during schedule or device inhibits), set the ApplyScheduleManual or ApplyInhibitorsManual state variable, respectively, to 1; but note that because this is technically a bug, the behavior in future will be as documented and the state variable workaround to get the old behavior is temporary and will be removed at a later date. Full disable of both auto and manual should be done by disabling the timer instance (via the SetEnabled action or the Enable/Disable switch on the instance’s dashboard card).
1 Like
