Since it was a simple rule I decided to just re-create it rather than using the imported rule. I was able to get the default to say 0 but then even with a per mode stay of 1 it still shut off right after motion stopped.
This is not how motion inactive works. There must be a motion inactive event for them to turn off from the Means To Turn Off of "Motion Sensors that stay inactive". The UI would be clearer if that said "Motion Sensors that become and stay inactive".
Basically, when you are turning the lights on from a dashboard or the device page, you aren't even running this app, as it runs from motion becoming active. You might want a different instance with Means to Activate of the light being turned on, and then use Elapsed Time to turn it off. At the moment, there is not a Condition to Limit turning off for motion, but I think we should add that.
Check the next release...
1 Like
Please show the Room Lights setup page.
What mode was you hub in? Show the Mode Setup page.
That appears to be a bug... I will look into it. Thanks.
2 Likes
This is such a cool app. Thank you for this.
Would it be possible to implement a 'grace' period as part of the "Turn off lights options"?
There is a grace period option. You can delay off for x seconds. This is on the Turn Off Options page:
Sorry, i can see that grace means something different here (English is not my primary language 
).
With grace period I mean, that the lights dim to x% while "waiting" for the sensor to potentially become active again. Otherwise it will turn off the lights after x time.
1 Like
What would cause this to happen?
We call this fade or grace. You have two timers. After detectors go inactive it goes to a level then holds there for X time then after X it turns off.
You can also do transition time so inactive lights "fade" to 10% over 1 min then hold there for 5 mins before turning off.
I would love to see this, it is the only significant feature that is missing in all the built-in lighting apps.
I do think a simple timer like you describe would be great. For non-dimmable lights, maybe blink once or something before turning off.
Dim before off gives the user a chance to re-trigger the automation before you are suddenly sitting in the dark. Besides that functionality improvement, I think it just looks cool to have the lights go dim for a few seconds, then go out.
2 Likes
I wonder if this could be done with a variant of the Preset Off feature, where it adds a time element. The RL instance would already go back to the initial table settings if a new Activation event comes along. The Preset Off is where it goes when Turning Off. But, by adding a time element, that becomes temporary settings before full off.
4 Likes
Yeah this would do the job👍🏻
1 Like
This will be in the 125 release. Already you could to a Transition to off over some time, where it gradually lowers the lights before finally turning them off.
With this new feature, you will have the step to lower settings for x seconds, then off. You can also combine the two: run a Transition to lower level settings, then turn off after a grace period.
8 Likes
I have converted several MML rules to RL. I noticed these errors on them when enabling/disabling Enable Logging. You can see the first two are one rule, turning it off then on. Next two are a second rule enabling/disabling Logging, and the final two are a third rule, enabling/disabling. I assume this is not normal?
Yes, known problem. When the next hot fix comes out, probably tomorrow, open each of those and hit Done. This particular error has minimal impact, and the app should work for you.
3 Likes
I've created 2 RL instances so far.
When I'm trying to push the button that is supposed to turn the lights off, they don't and an error is being logged:
This is my RL setup:
Thanks!
Could you please show me the Application State from the App Status page (gear icon).
Also, could you tell me what device is 2762. You can find this by going to
[hub-ip-address]/device/edit/2762
I assume that is Kitchen Hue Dimmer, right? If so, just need to see Application State.
