OK. I've been banging my head against this rule for weeks, and I just can't see what the problem is. Maybe fresh eyes will spot it.
What this rule does, in theory, is to control the kitchen lights based on mode and motion. When there is motion during the day, the light level is set based on lux. At night the light level is set to dim. Lights go out with no motion after 10 minutes during the day, or two minutes at night. During the day the lights are faded out over time. At night they just go out. If the lights have started to fade out and there is new motion, the lights should come back on again.
All that works, almost all the time. Every now and then, when the lights are in the middle of the fade, new motion does not trigger the lights to turn on again, and they continue the fade until they turn off. At that point, motion will again turn the lights on. You can actually see this in the logs. The lights are fading off, then at 6:34:11.746 there is motion, the lights say they are set to 100%, but then go on fading from where they left off.
I can't give you a solution only some tips on how you may want to debug / research the problem. Like you described, the crux of the problem is the dinning actions in the second screenshot. Perhaps setup a simpler test rule to try and debug the types of actions you are using and whether any other options may behave differently. I know there's been various rule delay / cancellation questions over the last 5-6 months, it may be worth looking at some of those threads for some options, if you haven't already.
I'm also wondering whether the rule can fire twice and cancel an earlier execution of itself. I'm pretty sure this has been asked, but don't know the answer.
In another post about this it was meantimeās that there is a stop rule actions actions. This might be needed to stop a fade in progress. As this isnāt a scheduled or delayed action.
So apparently this was renamed to cancel timed actions. Which you are already using.
@sburke781, I added in private boolean to keep it from stepping on itself unnecessarily. In theory, before it starts fading PB is set to true. If there is motion, then the actions from the prior iteration should be cancelled before the lights are turned back to 100%. If there's motion and PB is false, then nothing happens because the lights are already on.
I was hoping that I was just missing something stupid. As I said, it works about 90% of the time. I haven't noticed anything that seems to be consistent about when it fails. It just fails seemingly randomly.
I hate to spam my logs with this one rule, but I guess I'm going to have to turn on debugging and hope it will catch a failure that I can dig into.
I went over this a couple of times and I can't find the issue. I even went so as far as printing the rule and drawing all over it.
This rule is something way more complicated than I would write, but I get it. My kitchen is probably the most complicated collection of rules in the house.
The only other thing I can think of at this time is you could try to fake some of this rule with some virtual devices and see if you can get it to break the same way.
I agree with being way more complicated that I would suggest. It makes it so hard to figure out what is going south in cases like this.
@jabecker have you looked at any apps to do this instead? When you get to a certain complexity, apps make a lot more sense than RM. It is not that RM isn't capable but the sheer number of lines of code and IF/THEN and nested statements just are.... overwhelming.
Maybe Lights On Motion Plus? That seems to handle modes and motion very well.
Thank you for the replies. I don't think the rule is really all that complex. It looks complex because it's dealing with various conditions (mode, time of day, lux level). About the only way I could see to split it up would be to have motion in one rule and no motion in another rule, but I think they'd still be likely to step on each other.
I was going through other rules to see if something would hit me in the face. There's a second rule that handles changing the level of the dimmers based on a calculated lux value. I used to have that function in this rule, but moved it to a separate rule. (See... it could have been even more complex. )
Since that rule also dims the lights, it's a possibility that the two rules are stepping on each other. I changed the "Cancel Timed Actions" in both rules so that both rules are cancelled at the same time. I'm not absolutely convinced that's the problem because the second rule should dim the lights to zero only if the lux is really high. But it seems worth trying. It's about the only thing I can come up with.
Thanks again for responses.
ETA here's a screen shot of the second rule, with the cancels changed. Same change made to the above rule:
I would also suggest finding a way to break some of these up.
My kitchen lighting (under cabinet and a main fluorescent) are setup at 1 Motion lighting that triggers a virtual switch. And 3 other simple automation rules that turn on the under cabinet right away. And then the main if there is still Motion after 3 min. Then turns them all off, and dims the under cabinet to 25 if itās dark
EDIT: I went to go find my most complicated rule and honestly couldnāt find a nested IF within rule machine. I only have one user app and thatās simply to control my TV.
It might just be that my familyās automation needs are simple. We have a pretty straight forward routine.
Thanks for the response. I don't think it makes a difference. This rule has been around for a while, and I think they just changed the wording so that it was more clear what was happening. But I edited/saved those actions anyway, just in case. I think it's more likely that the other rule and this rule were stepping on each other. It hasn't happened again since I made the change to cancel actions in both rules. But then it doesn't happen very often anyway.
)
