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.
I tried this rule w/o the PB and it would just keep turning the VS on so... the way it's currently coded, the PB is required. It gives me a way to differentiate between the 2 states to satisfy the IF-THEN vs. ELSE-IF.
Here is the log for the same rule with only the 1 trigger, as you can see, it continues to repeat even after the VS is turned off, until I paused it.
So unless I am missing something Ryan is correct, the VS is Off is required. The rule stopped once I turned off the VS.
Now to be completely honest, this makes no F-ing sense to me. If you have a look at the rule, I have a third condition "Sunday" because I only want this to trigger 1 day per week, the day before trash day and guess what, Sunday is not required to be part of the trigger.
Here is the current rule, that does cancel when the VS is turned off. I would be open to having it written a different way if it makes it easier to create, edit and maintain since I use this exact format in a couple of rules and easy is well... good
You are missing something. As written, yours needs that trigger. But you're doing something different from Bruce's examples, where the conditional is inside the repeat (or is a simple conditional on the repeat itself). If what you have works, no need to change it, but that's the difference. The check needs to be in or on the repeat, otherwise indeed nothing can stop it without another trigger (or other workaround, like another rule stopping this one, but I digress).
(If someone else doesn't try first.)
