Not sure if I'm missing something but the motion lighting app sometimes won't turn on the light because it thinks it is already on even though the hub knows it is off. "Sewing Room Light" (the override light) was off at the time and showed off in the device properties as well and the mode was "Night" at the time.
I'm guessing it keeps a state variable in the rule and doesn't bother to check the actual state of the light and since the light was last turned off via the good night rule at 10:31 that state variable was still set to on. If that is the case, it would be great if it would also check the actual state of the light and if it doesn't match with the state variable then turn it on.
I'm still figuring out a few aspects of the motion lighting app myself, but I think you're on the right track here. I recall reading that it something outside of the motion lighting rule would be turning the lights on or off, that thing needed to be added in the motion lighting rule under the appropriate section. In this case, since it's another rule turning off the light, I don't think you can add it directly in the motion lighting rule.
As a workaround, you could probably add a virtual switch which the light, add that switch in your motion lighting rule as a switch that toggles the lights on/off, and modify your good night rule to turn off the switch, rather than turning off the lights directly.
It feels like a bit of a kludge, and I agree that it would be better if the Motion Lighting rule simply checked the actual status of devices before deciding whether an action is required, but this could at least get your lighting working as expected until a better solution becomes available.
That workaround sounds like it would work well, I'll set it up tonight and try it over the next few days to see if the motion lighting is finally reliable. I'll try to report back this weekend. Thanks for the suggestion!
In the logs you showed it never gets around to turning the light off, as you have two motion sensors and one must have still been reporting motion active. Is that right? That might be a problem. Also, Motion Lighting does subscribe to the on/off events for the light, as opposed to only keeping track of the state. So when the light reports turning off, ML does know that has happened.
It would be useful if you could show more logs, than include what happens when both motion sensors go inactive.
Motion Lighting does listen to every event from the light to know if it's on or off. But, some devices are not good at actually reporting their on/off state. This would obviously create a problem, as in that case querying the status of the light would yield the wrong result.
If you turn on logging in ML, and really watch closely the sequence of events, it's usually possible to see where things aren't right.
ML has been beat upon a great deal with respect to these issues -- it's not as if these problems have been overlooked. That's not to say there couldn't be some odd corner in the app that doesn't work as expected. But, for the most part, these issues have boiled down to device issues not ML issues for quite some time. Always open to being shown a problem, and comprehensive logging from ML and the devices in question is the way to show a failure.
For example, in the OP above (@Terk) , the logs for ML are from one time period, and the events shown from the device are from a completely different time period. So it's not possible to draw any conclusion from those logs whatsoever. These have to be lined up in time, so the actual complete sequence can be seen.
Thanks Bruce, Ill try to get more logs next time, it happened at 4am so i wasn't ready to gather comprehensive logs. The device events are from earlier in the night since that was when something last occured.
