If I do a "Cancel Rule Timers" against another rule, should it "abort" right then or what would I expect to happen?
Here's a log where you can see that the "Garage Inside Door Exit and Arm Cancel" RM App issued a cancel against the executing "Garage Inside Door Exit and Arm" RM App.
However, the RM App I thought I was cancelling actually continued waiting on the "wait" and then, when that wait was satisfied, it executed all the remaining instructions. It clearly didn't get cancelled. Am I doing/expecting the wrong behavior? How can I cause an RM app to be cancelled during execution from another RM app?
It's supposed to cancel any waits, at least according to how it's "documented" in the UI, and it might be clearer if you showed a screenshot of both rules. But I threw two rules together to test quick and think I demonstrated the same failure.
Here's the first rule, which I manually triggered via the UI to set into motion:
I verified that there was a subscription in "App Status" to a location mode event. Then, I created Rule 2 and ran "Cancel Rule Timers" on Rule 1 from it:
Again, I just manually ran these actions from the UI. Even after doing this, the subscription in Rule 1 remained:
Importantly, changing mode (my "Wait for" event, in this case) also caused the subsequent action to run.
I'm guessing this is a bug, perhaps something related to the new wait type in Rule 4.1 (I didn't compare this to 4.0) or the recent removal of the explicit "Cancel wait" action in recent hub firmware (again, didn't compare to anything earlier). But perhaps it's a misunderstanding of how this is supposed to work. As always with RM, @bravenel would know for sure, and hopefully the above is enough to see what the problem--if there is one--is.
It is supposed to unsubscribe the mode subscription, so I'll have to investigate why that is failing. First glance at the code shows it certainly attempts to unsubscribe mode when waits are cancelled. Waits are definitely cancelled by Cancel Timed Actions.
Please check that there is a setting for Rule 2 called "stopAct... ", and that its value is the appId of Rule 1.
I wasn't sure what you wanted me to check and when, so I just looked at things in their "normal" mode (the above snips came long after the issue last night).
I can do a test fairly easily, if I know what you're wanting.
Currently, in the "normal" situation with nothing running, neither shows any scheduled jobs.
The only event subscription either has is for the button presses that trigger them.
It appears the cancel happened while the rule was executing (not waiting at that exact moment)--the "wait for door open" came a fraction of a second later and it waited for the event before continuing.
Cancel rule timers from one rule to another simply hits the target rule to do a bunch of things, killing all pending delays, repeats, waits etc. So your timing for when you are doing that is whatever it is.
So, is there any way to just "terminate" another rule in progress (aka, "kill task")? If not, is that something that could be added (e.g, some sort of "kill flag" that would cause the rule to abort itself)?
Or do I need to look at creating my own "kill flag" (e.g., global variable or private booleans) and inserting "if kill-flag is set: exit rule" logic throughout rules I want to kill?
Prior to 2.2.7, the cancel seemed to terminate executing rules no matter what--but it seems to be acting differently now (in that rules are now executing to completion even if cancelled).
Just trying to understand the most desirable way for me to handle this going forward (if there is a bug, I'll likely wait for a fix; otherwise I'll need to add code to address it differently).
No there is not a way to terminate a rule. You can pause a rule, but a paused rule will resume where it left off. If you have a "need" to terminate another rule, you're in the wrong ballpark. This is not a 'feature' that makes any sense to add. Overall, seems like you're in way over your head with complexity. Time to learn Groovy and write a custom app....
Where I've done that in the past isn't super complex. I use it in mostly to make sure that "conflicting" RM Apps aren't running at the same time (such as killing my long running "wake up" app if I wake up before it's done and want to turn on the lights normally). Or, for a few rules, they try to kill any currently executing instances of themselves if they are re-triggered before they have completed.
After I get my taxes done (yuck), I'll do more testing and see what I can come up with then. Thanks.
Indeed, I do have some rules/situations that are too complex for my own good.
But I'll share an example of where I use it in a fairly simple/common situation:
When the RM App to turn on my lights triggers from I disarming my system, I cancel the rule that runs when I arm the system (because the "arm" rule can run for a minute or two as it gets everything done, which mostly involves turning off lights and locking doors with some "exit delays"). I do this to cover the (not infrequent) situation where I arm the system on my way to the car and then realize I left the car keys in the bedroom and have to disarm things 15 seconds later to go in and get my keys--then, 30 seconds later, arm it again on the way out.
Those are types of the use cases I'm thinking of--and need to address differently going forward. Indeed, I do have other situations that are way more complex (too complex for my own good), but I ran into this in a situation where I simply wanted to cancel a rule that was "arming things" as I left when I changed my mind after I kicked it off.
