Still struggling with getting this RM 4 rule to cancel
Use Case: Trigger: At a specific day/time each week (I will adjust the trigger once it's working, for now I am using a Virtual Contact Switch) What I want to happen: Send notification, turn on a virtual switch (VS) (Trash Reminder), repeat notification until the VS is turned off. (which I will do via Echo voice command)
What I don't want is multiple notifications when the rule starts up, thus the usage of the PB
Issue, even after turning off the VS, the notification keeps repeating as everything after the ELSE is skipped.
I have moved the End-REP to before the ELSE, and in several places after the ELSE, no luck so far.
Notice in the bottom of the log, the VS (Trash Reminder) is still on, thus the skip which is right. The next 2 repeated sections moving up, the VS is now off (TRUE), yet it keeps skipping everything in the ELSE section.
There are a few problems. First, your repeat can't straddle an ELSE. It needs to be contained entirely within one part of a "block." You could have an IF...ELSE...END-IF inside it or outside of it (or both), but not half in and half out. That might explain the error you see in the logs. Possibly also becsuse of this, your indentation appears a bit messed up--the ELSE-IF should be out one more level. You can't control this, but RM should do it automatically if everything is nested correctly (watch for this after you fix it, though--maybe it won't and you'll need to start over).
Second, nothing is canceling your repeat. I see where you think this might be happening, but since the repeat isn't set up correctly, that's unlikely to really happen. You have a few options for solving this. Just moving the END-REP before the ELSE is unfortunately not one of then because nothing will trigger your actions to run again (thus possibly executing that part of the rule) when the switch state changes. You could add that state changing as a trigger. There are probably other solutions, too. Hopefully some of these ideas help.
I also don't understand your justification for the private boolean--what would cause multiple notifications without it? You might be making this more complex that it needs to be.
I will look into re-structuring the If-Else-Then section, TY for the suggestions
Regarding the PB, It was something Bruce noted in the RM4 document as a way to keep things from happening when no change was made.
So far, I have found that if I don't use a PB, when a rule starts, I get 2 or 3 pushes right away, then only 1 after the repeat time kicks in. The PB appears to solve this, at least that is my impression.
"If we don't want the actions to run unless there was a change, the equivalent of change in rule truth of a 3.0 Rule, we can do that explicitly using Private Boolean. In the example above, if one of the two motion sensors went inactive, and then became active again before the lights turned off, the actions would run again, turning the lights on again. Generally, this is harmless.
What this accomplishes is that once the lights are turned on from motion active, Private Boolean is set to false, and the lights will not be turned on again until the full delay timer has run its course and the lights have been turned off. When that happens, Private Boolean is set to true, and the whole cycle can repeat."
Ah, I see where that comes from now. However, that usually only matters if a trigger fires again (or any of them if you have multiple), which would cause the "Actions" section to run again. If your eventual goal is only a time-based trigger, that shouldn't happen, though still can't hurt--and I suppose you might want to keep it if adding a second trigger helps.
Your rule sounds similar to one a few of us helped someone with a while ago here (notify every so many minutes if a garage door stayed open, if I recall). If I can find that, you might find a good starting point there.
LOL that might have been me and to be honest it's still not working correctly either. I get one to work, then try and duplicate the logic into the next rule and the same logic just doesn't work, it's like starting the learning process all over again.
So, to stay on this rule, nothing I try is working, even rewrote the entire rule in reverse...
Can I ask you to write a rule based on my use case and let's go from there?
I'm about to head out for a bit, but when I get home, I'll see if I can come up with something that looks like it should work. (If someone else doesn't try first.)
That being said, "notify every X minutes if Y is true" seems like such a common pattern people are making with rules that I wonder if staff would consider just putting something like that in the stock Notifications app (did @bravenel write this one?). I guess it's not as simple as it sounds since some people only want it to start at a certain time (restrictions as-is won't quite do that--the event will just ignored if it changes inside of those restrictions and doesn't again change when the restrictions are no longer in effect), so we get into the complicated territory Rule Machine does best, but it something like that seems like it could help some people avoid these pitfalls.
Thanks @bertabcd1234, and anyone else who might be interested in tackling this.
Let me clarify the use case just a bit so we are on the same page
Use Case: Trigger:
At a specific day/time each week (I will adjust the trigger once it's working, for now I am using a Virtual Contact Switch)
What I want to happen:
Upon trigger, send notification
Turn on a virtual switch (VS) (Trash Reminder)
3: Repeat notification every x mins until the VS is turned off. (which I will do via Echo voice command)
Once VS is closed, turn off repeating notification
You also have to have a trigger being the VS turning off. Otherwise, the rule will not trigger and you will not be able to cancel the repeating actions.
And I am telling you....if you want the to cancel based on the VS turning off, you need to have the VS turning off as a trigger for the rule. Otherwise, the rule won't fire to stop the repeating. You're asking a question and I'm answering. I don't understand the push-back.
No, your end-rpt is in the wrong place. it should come before your else-if. Also, i think your else-if should have the PB being false since that's what you want to have tested then.
I did--the original poster isn't using it, but I'm not convinced the private boolean is necessary here, so a simplified conditional could be used (I hinted at the former above, and the latter would then be possible since you don't need to test for multiple things). Then, the repeat will stop when the simple conditional (the virtual switch being on) becomes false. Same effect with a bit less clicking.
In either case...
...this would not be true, as you can just test for the virtual switch state in a conditional (either a simple one on the repeat as suggested above, or a full-fledged conditional inside the repeat, where every repetition contains a (re)evaluation--no trigger necessary--and you can take the appropriate actions, including stopping the repetition when the desired conditions are no longer true).
Like you, I also considered using the virtual switch state as an additional trigger. I'm sure you could make this work, too. But I've seen cautions against multiple triggers, and Bruce (unknowingly) smacked some sense into me by posting a couple examples in the thread he split from this one. As written there, this is not necessary.
I think creating that thread was a great idea, by the way--there have been a few similar requests here for this kind of rule, so I see it becoming a helpful resource.
(If someone else doesn't try first.)
