What is the simplest way to achieve a EVERY <period condition> DO <action> UNTIL <expiration condition> THEN <exit action> with just one rule?
Similar to making a recurring a calendar event, but with and action added at the start and end.
My goal is to be able to use any arbitrary frequency to execute an action and then after an arbitrary period of time (Or even better an arbitrary event so it could be anything from elapsed time to whatever you can come up with) execute an exit action.
An example could be (with wonkyness inserted for genericness sake):
Every 3rd Monday of months with 31 days, start the merry go round until the cows come home, then spin it up to 1000RPM and stop it to get rid of the riders.
I know it is simple enough with two rules (bar some lack of generic period specifications) but I have been scratching my noodle on whether it is possible with just one, and now I am obsessed
I am thinking of something down the line of combining the "trigger with a delay" pattern to do the end action with something else, but I haven't figured out how to combine that with a recurring trigger/action pair.
Hoping there is someone out there who figured this out Maybe there is a super simple answer I just have overlooked. Kinda hope so!
Sorry I wasnāt clear on that. To use the calendar analogy it would have completed that occurrence. I guess occurrences could overlap. I donāt know the underlying implementation but if each occurrence is an individual instance created upon trigger then I assume that would be possible. Thatās not really a case I would consider super important though. Restricting each end to not overlap with the next start would be reasonable I think.
Thanks for your quick reply!
Please clarify what further information you need about that.
Regarding your second question that should hopefully be clear from my original post; a periodic rule similar to what you would do when creating a recurring calendar event. Typically these consist of a period and a point in the period and can have various modifiers depending on implementation. Crontab is a pretty good implementation example. Please let me know if you have further questions.
Just to be clear and avoid any confusion; I am not looking for a solution to a specific problem, but rather another gadget in the toolbox to pull out when these kinds of challenges presents themselves. A design pattern you might call it.
Iāll take a stab, based on how I understand what you want. It seems that what you want would be solved by the āSimple Condition Actionā idiom, where the Action is a stoppable REPEAT.
A bit of discussion before I show my rule.
Simple Condition Action, where the action is a REPEAT, followed by a REPEAT block that is terminated by an END-REP, evaluates a single (simple) condition before entering the REPEAT block. If the single (simple) condition is false, the REPEAT block is not entered; if the single (simple) condition is true, then the repeat block is entered, the actions in the REPEAT block are executed, and the initial condition is scheduled to be tested again after the period of the REPEAT has ended, at which time the single (simple) condition is tested again before re-entering the REPEAT block.
This special idiom (Simple Condition Action, where the Action is a REPEAT) is the equivalent of a WHILE ... DO ... END in other languages. The reason I keep saying āsingle (simple) conditionā is to emphasize that only a single condition can be tested. If you need to have a complex Boolean expression be the condition, then you have to build that Boolean expression, e.g., (A OR B OR C) into a single local variable result, and test that variable as the single (simple) condition.
Now for my rule, which does this. It builds up an OR of a number of conditions, both before entering the REPEAT loop, and before restarting the loop.
There are those in the forum who have said that the re-building of the expression at the end of the REPEAT block is unnecessary because of the re-trigger that will occur. My response to that is (1) I was trying to preserve the āretest on each loop restartā that the Simple Condition Action idiom does, and (2) I have seen multiple concurrent process threads in the REPEAT block unless it is done this way.
That is brilliant. Great explanation!
To recap, what my vision is for context: Have a trigger that is periodic which when it triggers executes an action, then after a certain duration does something else. Rinses and repeats. @672southmain your solution looks like it would work perfectly for that inner loop to do the thing and then the other thing, pardon my French
So that really just leaves me with how to create a trigger at some arbitrary interval. I still haven't figured that out. All I can find is a time of day and a days of week mechanism. Do you know if there is anything that lets you state the period and point time?
Example: Period=Month, point = day 7 & 13 & 28 (Similar to what you can do with cron, hence my calendar reference )
It is all coming together ( I hope, please correct me if I am into the weeds here), I am so excited Thank you so much!
Well, you have the sample rule from my earlier post to use as the model for the core actions.
Then, because you havenāt given a specific periodic problem that you want to solve, but seem to want some sort of periodic triggering of the rule, use a cron string trigger. You do know that you can use a cron string as a rule trigger, donāt you?
Maybe there is a super simple answer I just have overlooked. Kinda hope so!
