RM 3 - Lights Off With Cancel On Truth Change Help Required


Hi all
I’ve built a new rule with RM 3 to control lights. On the whole, Lights always come on with motion. But it must be about 50% of the time the lights don’t go off. The rule I’m using is:

Can anyone suggest a better way of turning lights off after a set period of no activity? The motion sensors are either Aqara (modified to be super sensors) or Philips Hue.

As an example, the following rule hasn’t turned off the lights (they are on while capturing this rule). As you can see, the condition is false so should have switched off:

Rule machine 3 bug
Rule not logging correctly, missing ENDIF not working right

When the rule fails to turn off the lights after the delay (with cancel on truth change) can you please show your app states section using the "gear" icon in the app configuration or the from the app list? I've been working with @chuck.schwer and @bravenel trying to pinpoint the cause of a similar issue I've been having. You might be the first person to confirm I'm not alone :blush:

It's important that you DON'T select "update rule" or "done with rule" as this will clear the state I'm talking about.


Show the logs from the rule.


@halfrican.ak I turned the light off in Hue app for the kitchen light however is this what your looking for?


Partially, also need to see the scheduled jobs at the bottom.


@bravenel here you go:


@halfrican.ak sorry, I missed that bottom one. Here’s the full screen:


I'm also having major issues with this. See my posts all over the forum.



I'm finding that cancel on truth change is actually cancelling the true action, not running the false action. I'm not able to show Bruce yet how this happening.


Yep, that looks like exactly the problem I've been having. Unfortunately Bruce and Chuck haven't been able to duplicate the problem, up until now I was starting to believe the issue was ONLY me.

The problem seems to be that the cancelList and cancelListPend states are not being "cleared" properly and as a result, the action gets canceled when it shouldn't. Now that there are more users reporting this it should help in pinpointing the issue :crossed_fingers:


Cancel on truth change cancels any pending delay that has "cancel on truth change" selected, irrespective of whether it comes from True Actions or False Actions. Also, cancel on truth change has nothing to do with whether or when the True or False Actions of a rule run. That is determined by the rule evaluation, not by the actions.


OK, sorry about the lingo. Then false doesnt always run when there is cancel on truth change.


Interesting. It's the last one in the sequence where there is a failure. It says the rule became False, but it did not execute the False actions. I will see if I can reproduce this. Are you running


This is what I'm seeing too, but have been unable to prove it. I'm running


I can't get it to fail, so have to keep digging to find what is different between my rule and yours.


This may be true, although I cannot reproduce it. If you have one of these that misbehaves, look at the app state at those two variables. If the rule hasn't run for some time (i.e., all delays have expired) they should both be empty, look like []. If not, there is a problem with that rule and it should be removed and recreated. One thing we don't want to do is to chase after a broken rule acting broken. Of course, we do want to figure out how it gets broken in the first place.


@bravenel yes, I’m running


Yes, but I'm seeing this all over the place. I've been saying this for a week, but not getting any traction.

Edit: here is my example...


@bravenel I will give it a go deleting and recreating the rules (10 in total). They were all created with this newest firmware, not the previous one


I have deleted and re-created multiple rules all of which still exhibit the issue intermittently. This issue isn't limited to false actions either, I've got the same problem with true actions that use the "cancel on truth change". Unfortunately, I've been unable to pinpoint a specific series of events that causes the issue, short delay/long delay, rule change infrequently/frequently, etc, doesn't seem to matter.