Plugin: DelayLight

Plugins & Plugin Development General Plugin Discussion
#41

I have installed the stable branch, not sure if i have found a bug more testing needed, at the moment i have a door sensor that is set to (2) do not start off-delay timer until sensors reset. if the door is left open for a long period (unknown how long at this time) when the door is shut the timer does not start… only noticed it the other day when i upgraded the plugin to one of the older releases. (maybe two weeks ago).

I will do some more testing tomorrow and report back, unless you have an idea?

Paul

#42

Yup, I broke it. Stable branch updated with fix.

#43

I have manually installed the stable branch this morning and reboot the lupp, but i am still see the same problem. anything else i need to try?

Paul

#44

Open a tab in your browser and request this URL: [tt]http://your-vera-local-ip/port_3480/data_request?id=lr_DelayLight&action=status[/tt]

Send me the output via PM or email (on my profile here). I’ll take a look.

#45

Might have found the problem,

when i try and upload the file

1). L_DelayLight.lua
ERROR: Request Entity Too Large

#46

I tried to upload the Lua file on my Vera Plus (production) and Vera 3 (dev/testing) and no issues.

There’s no way that file could be too large (the limit is likely several megabytes). The file should be 1582 lines, and just short of 68,000 bytes (67949). Make sure your file size makes sense.

#47

I have managed to fix the upload, i used WINSCP deleted the file waited 5 min then upload the file via the browser and it looks like it uploaded ok,

will report back…

Paul

#48

OK. If you uploaded using WinSCP, there’s probably now a compressed version of the file, and an uncompressed. The former (compressed) is the one installed by the install process or made by the Vera uploader (it also compresses them). The uncompressed file is your WinSCP product. You need to remove the compressed file (L_DelayLight.lua.lzo) so that the uncompressed file is used; otherwise, Vera may/will prefer the compressed to the uncompressed, and again you will see no change. You should be able to see both files listed in Apps > Develop apps > Luup files, and you should be able to delete the LZO version from there as well.

#49

Just for future reference… The upload file size limit is 512K.

#50

Good to know. Hopefully I’ll never write a plugin that large! ;D

#51

After fixing the upload problem. the timer is now working.

Paul

#52

Good to hear. I’ll release that officially as 1.4 tomorrow (available in Vera Plugin Marketplace on Monday). That release will also have improvements in the status messages to make it more clear what is happening when a hold is in effect.

#53

OK. That’s released and available in the Vera Plugin Marketplace and AltAppStore.

#54

Hey, first off I’d like to say this is a great plugin.

One request (if I may) would be to treat an ON device dimming change the same as a status (on/off) change so it would also trigger the manual countdown.

Example and scenario:
My timer is as follows:
TRIGGER: Living room motion detector between 9:30pm - 7:30am
ON devices:
Kitchen lights - On - 75%
Living room lights On - 75%
OFF devices:
A scene that checks if the TV is on and either sets
Kitchen lights - Off
Living rooms lights - On - 30%
OR
Kitchen lights - Off
Living room lights - Off

Scenarios:
1.) If timer is active, I’m watching TV (so kitchen lights off, living room lights are at 30%), turning the kitchen lights on should trigger the manual countdown timer = Success - Kitchen lights turn on (at 75%), manual timer starts. There looks to be a bug here tho as this also causes my living room lights to increase from 30% to the set 75%. You said other ON devices shouldn’t be affected when one if manually triggered right? Or is this the desired behavior?

2.) If timer is active, I’m watching TV (so kitchen lights off, living room lights are at 30%), turning the living room lights up to 75% (or anything other then current setting) on should(?) trigger the manual countdown timer = Failed - Change of dimming setting on an ON device doesn’t trigger manual timer, nothing happens.

I’m somewhat pushing the limits of what this should do by using a scene to set specific off settings but the request of a dimming change to be treated as a manual trigger could be useful for more standard use cases also.

Thoughts?

#55

How is your “off” scene implemented. Lua?

#56

Yeah - just straight Lua in a manually triggered scene.

That shouldn’t matter to the triggering of the manual timer though as the ON devices are added as actual devices directly on the timer… right?

#57

Yeah - just straight Lua in a manually triggered scene.

That shouldn’t matter to the triggering of the manual timer though as the ON devices are added as actual devices directly on the timer… right?[/quote]

That’s absolutely right, but had to ask to be sure. DelayLight actually examines the scene actions to try to determine what devices may be affected, and try to do the right thing, but if control is in scene Lua, it cannot do that. But, as you correctly surmise, if the devices in the scene are also listed as “on” devices, it sees them that way, so should not be a problem for you.

[[living room lights previously on manual at 30%...]] turning the living room lights up to 75% (or anything other then current setting) on should(?) trigger the manual countdown timer = Failed

Agreed. This is a case not yet handled, but I’ve opened that as issue #9 in the Github repo. I’m going to try to address this before I go on vacation this weekend, but a full release is too risky, so I will just push it to the stable branch, and you can install the update from there. Stay tuned.

That said, though… once a timing mode starts, it is not overriden. So, if automatic timing (from motion sensing in your case) turns on the lights, turning other lights on or off (or changing their dimming level once I fix that) would not change the mode from AUTO to MANUAL as currently implemented. This is done for two reasons: first, if a user starts the timer in MANUAL mode by operating a light directly, a later trip of an automatic trigger device will not switch the timing mode from MANUAL to AUTO, which would reduce the time interval (typically) and leave the user in the dark earlier than they expected/in a switch war with the motion sensor; and second, if starting with an automatic trigger (so in AUTO mode), loads are already on and thus the only possible state change (currently/in 1.4) is to off, and that probably should not imply a switch to MANUAL. But, if we start paying attention to dimming changes, there’s a good case to be made for a dimming change to force a change from AUTO to MANUAL. I want to consider the impact of this more, but I’m inclined to implement it as an option.

turning the kitchen lights on should trigger the manual countdown timer = Success - Kitchen lights turn on (at 75%), manual timer starts. There looks to be a bug here tho as this also causes my living room lights to increase from 30% to the set 75%. You said other ON devices shouldn't be affected when one if manually triggered right? Or is this the desired behavior?

No, this is the expected behavior–when any “on” device is turned on, all the “on” list devices are set to their prescribed state. But, I can add an option for this; it seems like a desirable alternative to the current default behavior.

Stay tuned. I’ll get something up on stable for you later today if all goes according to plan.

#58

@jarrodirwin The stable branch on Github now contains the following changes for your case:

[ol][li]Changing the dimming level of a light that is already on is detected as a manual change (issue #9);[/li]
[li]The [tt]ManualOnScene[/tt] state variable (flag/boolean, default 1) has been added to control whether a manual trigger by a single device sets all “on” list devices to their configured states (the current behavior and default), or if the “on” devices should be left alone (set [tt]ManualOnScene[/tt]=0). There is no UI for this option yet, so you have to change it by hand in Advanced > Variables (issue #11).[/li][/ol]

To update, just download the [tt]L_DelayLight.lua[/tt] file from the Github stable branch, and upload it using Apps > Develop apps > Luup files. If you are using ALTUI and the AltAppStore, you can update via reinstall by choosing the “Github.stable” version and clicking the “Alt” install button.

#59

@jarrodirwin The stable branch on Github now contains the following changes for your case:

[ol][li]Changing the dimming level of a light that is already on is detected as a manual change (issue #9);[/li]
[li]The [tt]ManualOnScene[/tt] state variable (flag/boolean, default 1) has been added to control whether a manual trigger by a single device sets all “on” list devices to their configured states (the current behavior and default), or if the “on” devices should be left alone (set [tt]ManualOnScene[/tt]=0). There is no UI for this option yet, so you have to change it by hand in Advanced > Variables (issue #11).[/li][/ol]

To update, just download the [tt]L_DelayLight.lua[/tt] file from the Github stable branch, and upload it using Apps > Develop apps > Luup files. If you are using ALTUI and the AltAppStore, you can update via reinstall by choosing the “Github.stable” version and clicking the “Alt” install button.[/quote]

Woah thanks rigpapa! That was a really quick turnaround.

100% agree with your opinions in your last 2 posts.

I’ll install these changes and give it a whirl tonight and let you know how I get on in a real world test. Everything on paper makes perfect sense though.

#60

@jarrodirwin The stable branch on Github now contains the following changes for your case:

[ol][li]Changing the dimming level of a light that is already on is detected as a manual change (issue #9);[/li]
[li]The [tt]ManualOnScene[/tt] state variable (flag/boolean, default 1) has been added to control whether a manual trigger by a single device sets all “on” list devices to their configured states (the current behavior and default), or if the “on” devices should be left alone (set [tt]ManualOnScene[/tt]=0). There is no UI for this option yet, so you have to change it by hand in Advanced > Variables (issue #11).[/li][/ol]

To update, just download the [tt]L_DelayLight.lua[/tt] file from the Github stable branch, and upload it using Apps > Develop apps > Luup files. If you are using ALTUI and the AltAppStore, you can update via reinstall by choosing the “Github.stable” version and clicking the “Alt” install button.[/quote]

Hey rigpapa,

Had a play with this and it does work - Not sure if you’d rather me comment on the Github issue or here but will just do here for now.

In my somewhat complex timer, it looks like if the “off” action dims one of the “on” devices (like in my TV watching scenario where if the TV is on, turn one light off and dim the other), then this sets a manual timer so defaults to the “on” status’s. This essentially means the lights never get back to the ‘off’ state. This could be due to my dimming of the the lights being triggered through lua in a scene and not directly in the timer settings…?

I have another timer for the hallway which is much simpler. On but dimmed to 50% when motion is detected, off after X seconds. When this is manually turned on and the manual timer is counting down, a change in dimming level resets the manual timer like expected with the new feature. When auto timer is triggered, changing the dimming level does nothing still - assume you haven’t implement that option yet? Although I’m running v1.4 and only copied the new .lua file so haven’t got any of the newer UI enhancements to enable/disable this if created.

EDIT: Confirmed the dimming being set via Lua in my ‘off’ scene is what’s causing the timer to hear a dimmer state change. When I changed the hallway timer to simply dim instead of turn off, it worked as expected. To get this working with my ‘off’ scene, I tried changing the watchMap() code for dimmers to listen for LoadLevelTarget events instead of LoadLevelStatus and although this did let the lights turn off and dim correctly, it also created a new manual countdown timer… even though everything is in the desired ‘off’ state - so that doesn’t seem like a solution.

As I’m new to Vera, Scenes and Lua, do scenes wait for all actions and code to run before returning true/success? When using scenes does the timer wait for any type response from the scene before continuing? Wondering if I can add some halt/wait in my scene Lua that gives my lights enough time to dim before they get heard from the timer (or something).