I have a motion lighting rule for our mudroom which used to work and now doesn't turn off the light if it was manually turned on. My desired (and prior behavior) is:
When motion is detected, turn on light for 2 minutes
When the door is opened, turn on the light for 2 minutes
When the light is manually turned on, turn it off again (if no motion) in 2 minutes
What I'm seeing is that if the light is manually turned on, it is never turned off by this rule. I'm 99% sure this worked originally though. I'm not sure if this popped up in .135 or an earlier 2.3 release - most people don't hit the switch so my opportunity to notice the problem is small.
Here are the event subscriptions which seem to show it's subscribed to the switch being turned on/off:
Motion lighting turning off lights is caused by motion inactive, Without motion, they aren't going to turn off. Why don't you just use a separate rule if you want them to turn off x minutes after being turned on?
Interesting - I thought this used to work.... I wasn't using a separate rule as it seemed redundant to have a ML rule that says "when motion or contact, turn on lights and off again after 2m" and then a RM rule that says "when light is on, wait 2 minutes and then turn off" since I'd now have to keep that timing in sync if I ever want to change from 2 minutes to 5 or whatever. It also increases the chance for odd behavior if ML is keeping it on because there's still motion and my RM rule is just waiting 2m - I'd basically have to duplicate some of the ML logic in RM which I was trying to avoid.
I understand. But the functionality you are describing has never been part of Motion Lighting. It has never treated a switch being turned on the same way that it treats motion-active followed by motion-inactive. There haven't been any changes to the app related to this.
Yes indeed, just turning off a light after some time could have a bad interaction with a motion lighting instance that IS monitoring for motion inactive as the key to turn off the lights. There are ways you could get around this, that entail some rule complexity. For instance, ML could turn on a virtual switch that indicates it is in the motion-active-inactive sequence, and that could suppress the rule from turning the lights off.
Motion Lighting is intended for a circumstance where it is THE means of turning lights on and off in a room. Many users seek ways to intervene, like when not to turn them on or when not to turn them off. But if you think about it, you're wanting something that is unrelated to the motion in the room -- hence, it's not within the natural domain of Motion Lighting.
That's certainly a fair perspective and in my case I do intend motion to be the main trigger. The wrinkle is that we have a switch and so those who may not realize there's motion can manage to quickly hit the switch before ML turns things on and to my surprise that did cause the light to remain on (I came back an hour later; sadly logging was not enabled at that point).
I do think I'm still seeking something related to motion - that is, if the light is on and there's no motion for 2 minutes, turn it off. But I understand if you're view is this is out of scope of ML and I'll try to set up a rule to deal with it in RM.
As an aside, I'm not sure why I ever thought this worked... maybe my early testing was incomplete and I assumed more than I should've
You would need the "Allow contact sensors to trigger" for timing to be involved in turning off when the contact closes. But, that gets complicated as well, because then the lights won't turn off if the contact doesn't close.
But there'd have to be no subsequent motion for the lights not to turn off later. So you have a room where you turn on the light, but motion isn't detected? Perhaps you need more motion sensors for that room.
In a normal ML setup, you can turn on the lights from outside the room, then enter the room (ML will know they are already on), and they will turn off after you leave the room.
I suppose it's possible nobody pushed the switch and the root cause is the door issue you pointed out. I had assumed that'd work by having the door in the contact sensor trigger:
And I think that works (but will test a bit more) - if the door opens, the lights come on even if there's not motion (yet). I did look at using the new "Allow contact sensors" option but noticed the caveat that the door closing turned off the light again - in our case it's a garage door so it's spring loaded and will (nearly) always close and we don't want the light going off until the person leaves the room; there's no door on the house side of it and it's not a large enough space to dump more motion sensors in.
I speculated someone opened the door and pushed the switch before motion was triggered (which shouldn't be possible but motion is a bit slower than a person reaching through the door and pushing the button) but that's pure speculation on my part since I don' t have enough logs from that window of time. I'll try to play with it a bit more to see if I can figure out precisely why it stayed on but from what you describe, I don't have an option to have ML turn off a light that's been on without motion if it was somehow turned out without motion to start.
I dug up the logs and I was wrong - I think in the context of your answers here there is a reason it stayed on. The door was opened and then closed without triggering motion (I suspect our 2y old managed to open it just a bit before our nanny encouraged her back outside to the garage).
So I suppose using contact sensor for on (which does work as I have it now) and off (which I don't have) would resolve this if it behaves nicely with the motion as well. I'll have to play a bit and see. If not, then I can likely come up with a rule in RM to solve this. Thanks for sharing more about how ML is expected to behave.
Edit: I set up a test rule and using contact sensors (for on and off) behaves as we want. Since our door has a spring (and is an exterior door) we can safely assume it'll always (at some point) close.
