I am looking to implement what I think should be a simple solution.
1 motion detector
1 dimmer switch
when motion active turn on lights to level x (by mode)
turn off after no activity for 5 minutes
Here is where i am struggling a bit. Once activated, if the user adjusts the level w/ dimmer or Alexa, I want the new level to be maintained. When re-activated (but only after turned off) resume the originally levels determined by modes.
I have been using motion lighting app and have lost track of the options I have played with...so many choices:slight_smile:
I find i am putting the app in override which is preventing the motion from turning things on the next time. I have also experienced that when the sensor detects motion and reschedules the turnoff task it also resets the levels to the original levels.
I am rather certain it can be done, but I know have myself in a circle of settings i have tried, forgotten, failed, etc.
Does the switch remember the previous dim level when you manually turn it on? That would simplify things. Or you could just program dimmer levels based on mode. (75% for evening, 25% for night, that sort of thing)
My use case is different, but maybe you could apply it to what youâre trying to achieve. My Sengled Element Plus bulbs donât support fade to OFF or fade from OFF to a specific brightness level, but I really like the look of them slowly fading on and off, so I have forced it to happen with rules. I can dim the lights up or down from a Pico, but when I hit the off button, it calls up a rule that fades the lights to 1% then 3 seconds later, it turns them OFF. When I press the ON button, it fades the lights to 70% brightness. So using separate rules, this gives me the fade I want for ON and OFF, but still allows for brightness adjustment.
Maybe you could call upon specific rules that respect the mode and set the light to turn on to that level when the motion detector activate them?
That shouldn't be happening. But, I think there is a bug in the way override is working (or not, as the case may be).
The way it's supposed to work is that if the lights have come on by motion to some level, and you adjust the level with they physical dimmer or Alexa, then it is supposed to stop changing the level or turning off until it is turned off by some means. I just discovered that it's missing the Alexa element of that. This will be fixed in an upcoming release.
Thanks for the update. i await a fix. It is reassuring to know I am not losing my mind.
One thought on the implementation though. In my case I would not want to override the turn off delay of the action, merely prevent the level from bouncing back to the mode defined level. This really is behavioral, if the light comes on (ie. closet lights) i override it to be able to see color better (those days when the wife doesnât lay out my clothes), i will continue with my morning and eventually walk out not turning off the light due to being in the habit that it is motion controlled. In other use cases I can see wanting to override both the turn off and the setting of levels.
It would be a UI and usability mess to implement two different things to be caused by the same action. It should be one or the other. My thought was that since you've gone to the bother of messing with the dimmer in order to take control from the automation, you have to also bother with it to give control back to the automation.
Bruce, I donât completely agree. As for the UI aspect, it could be an option overide level vs overide automation.
In an area of the home used by multiple users the behavior being trained is this room is automatically going to turn off. If one user changes brightness, other occupants may not realize.
If we are attempting to fully automate a home, it is necessary to be able to augment the automation without completely disabling it.
I have used and loved RM in SmartThings, but saw that Motion Lighting had both a Switch to Disable On and Switch to Disable Off feature.
Previously, in RM, I would create a virtual switch and then have that rule not fire when the switch was turned on.
Iâm attempting to get that same result in Motion Lighting by specifying the same virtual switch in the settings for âSwitch to Disable Onâ and âSwitch to Disable Offâ.
I note that it doesnât ask what the state of the switch is in the config options, so maybe Iâm misinterpreting what this is for.
Basically, I want the lights Iâm controlling to remain in whatever state they are (on or off) ignoring motion sensor activation when this virtual switch is on.
It seems to work for not turning lights on when the virtual switch is on, but, when I turn the virtual switch off, and the âTime to Delay before turning offâ time elapses (10 minutes in my case), the lights are remaining on.
If I have to do a Rule for this, it wonât be the end of the world, but I was just wondering if Motion Lighting could handle this case?
Am I missing something obvious? Thanks for the help/guidance.
What I seem to be missing is I still want to have a means via button or switch disable the automation all together. I have a pico that I use to turn on a virtual switch for "sleeping" to disable a number of automations. Is this possible? Maybe I am missing something.
I havenât tried this myself but why not use the same switch in âswitch to disable onâ also be used in the last group of options âswitch to disable offâ. That switch would essentially disable the whole automationâŚI think
I can confirm that using the same virtual switch for both override on and override off works⌠the only wrinkle is that it appears that the internal âruleâ doesnât get re-evaluated when the virtual switch is turned off.
In other words, if I have the lights go on, then put on the override virtual switch, and wait past the âdelay to turn offâ, it works great - lights stay on. But, if you then turn off the virtual switch, the rule isnât re-evaluated - the lights will stay on until another cycle of motion/no motion.
This is a minor wrinkle, and usually easily avoided if the sensor is going to pickup movement relatively quickly. Once it does, the rule is re-evaluated and all works normally.
@bravenel are there any plans to change things so that the current rule / scheduled action is re-evaluated? I want to use a virtual switch set by multiple possible channels (ie. a button, action on a switch, alexa, etc.) all to turn on / off a virtual switch. The virtual switch would be the switch for the enable on and disable off. But if the same virtual switch is used, then the light could already be on, turned off by the existing schedule then not turned on because enable on is false.
Motion Lighting does not have rules that are evaluated. It is entirely event driven. So the simple answer to your question is, no, there are no such plans.
I don't fully understand what you're trying to do. Using the same switch to enable on and disable off doesn't sound logical... ??
Thanks Bruce - this does help answer a question and strange behavior I was seeing in Motion Lighting.
Back in the early days of RM, when I submitted a patch for you to consider for rule override, the general pattern was that a switch (virtual or otherwise) was evaluated to see if it was turned on. If it was on, then execution of the rule was effectively suspended.
So, if you didnât want the rule to fire turning on lights in a kids room after bedtime (but with the house in Home mode), you turned on the virtual switch. Disabling off is a similar use case - the lights came on with the automation, but, turning on the virtual switch would prevent execution of the âturn off after x minutes of inactivity.â
Based on your earlier example in Motion Lighting, I was under the assumption that using the same virtual switch for âdisable onâ and âdisable offâ was operating in the way I just described.
If thatâs not the case, I can easily convert my Motion Lighting to RM rules. If you could clarify, that would be great.
You should not need to know how the implementation handles this internally. RM did things in one way because it had a more general problem to solve, namely the evaluation at a point in time of a bunch of conditions. Motion Lighting doesn't have that problem to solve, so it goes about it differently. Whereas RM was implemented such that it found out the current state of a device at the time of evaluation, Motion Lighting is implemented such that it maintains in its internal state the implication of the state of the device. Motion Lighting has subscribed to these override devices, and uses their events to manage its internal state. RM did not maintain internal state about devices. The net effect of either approach is the same (or should be).
If you turn on the disable-off switch at any time before the timer runs out on motion-inactive, the lights will not turn off. Motion Lighting should function exactly the same way the corresponding rules would function. If it doesn't work as expected, there could conceivably be a bug somewhere, although I am not aware of any at the moment.