@bravenel I am still seeing "A bug in Motion Lighting with 'Don't tun off is already on' " issue in 2.1.5.124
app:312019-10-06 01:24:33.841 am infoNot turning off: lights not on
app:312019-10-06 01:24:33.810 am infoMotion inactive Motion - Iris Test
app:312019-10-06 01:23:40.376 am infoMarks Nightstand turned on
Need to see more information, including the setup page for Motion Lighting, and please show a screenshot of the logs instead of copy/paste. What you've shown does not provide enough context for how the lights were turned on.
ok - I'll reply tonight with the logs...The rule is disabled during the day....For context - I turned the light on via shaprtools.io dashboard. I will take a screenshot of the motion lighting rule and the logs for you though. Never saw this issue in 2.1.4 - so searched last night when they didn't turn off and saw the fix in previous release.
It's not a big deal for me, as the light is Alexa enabled and I can just shut it off by voice or dashboard - but wanted you to know that I saw the bug in latest release.
here is the rule:
I'll share the logs tonight.
Mark
Just to add -- Only the Nightstand was on - the hallway was off. If that helps.
What does this have to do with “Don’t turn off if already on”? That option is not selected.
ok...The lights did not turn off when the motion stopped (even when I turned them on manually) - That always worked. The log said Not Turning Off, Lights Not on...even though the lights were on (I also checked device state and they were on) ...I thought that was what was fixed in the release. I misunderstood what was fixed I guess. Sorry that I bothered you.
How were they turned on? No bother...
It was turned on via Sharptools.io dashboard
So as far as Motion Lighting was concerned, since it had not turned on the light, it had no reason to turn it off. If you put that light in the option for switches to turn on the lights, then it would have turned it off. As a general rule Motion Lighting doesn’t turn off lights that it didn’t turn on.
ok...thanks for the quick replies. I would have sworn it worked that way every night...Maybe I'll move it over to Rule Machine, where the Motion inactive will act as a trigger event - I thought Motion Lighting worked the same way. From the logs, it seemed too, but it thought the lights were not on....
My ignorance as a newbie - sorry.
Mark
I think I'm seeing this problem and I do have the option checked and motion lighting is turning on the light.
Here's my rule:
and here's the log from last night where ML turned it on but failed to turn it off because it thought it was already on.
It looks like what happened is the trigger in this case wasn't the motion but the switch (hallway lights in this case) that I set to activate on as well and after that motion was detected which also triggered it and that secondary trigger reset the state such that ML thought it was already on even though it had originally turned it on.
I would think it could keep its own state? @bravenel, is this working as intended or is it possible there's a bug?
That is working as designed. The feature "Don't turn off if already on" was active due to the lights being turned on from other than motion. Which way do you want it to work?
Oh, I had assumed if Motion Lighting app turned on the light (via motion or one of the other settings), it would then treat it as though ‘it’ turned the light on and would thus turn it back off, regardless of the trigger. I was imagining the “already on” would apply to cases where the ML configured triggers (another switch, motion, etc) fired and the light was on already.
There's a conflict between those two options. And, on top of that there is a race condition. I think the logic of your expectation is OK, but the implementation doesn't work out that way due to the race condition. I will look into the possibility of forcing the race condition to resolve the other way, that is, so that the "Switch to turn on" takes precedence over the "Don't turn off if already on".
This will be resolved in the next release.
I don't have any "switches to activate on" and I have this same problem. If I use "don't turn off if already on" the lights never turn off.
This works, but the lights turn off after the timeout no matter what. The override also doesn't seem to ever run.
This does not work, the lights never turn off once triggered by ML even if I did not overrride by changing level etc.
Show the logs from the app. They will reveal what's going on.
yeah, after responding I started thinking about how I would attempt to do this in RM and realized it's not quite as straightforward as I'd like (or initially thought)...
Great, thanks Bruce!
You end up with two different concepts both 'triggered' by the same event. Hence, you get a race condition. So, who gets to win the race? My solution is to delay the "Don't turn off if already on" logic by 100 msecs, thus allowing the race to be won by the switch activation logic.
Download the Hubitat app
