So I'm in the process of moving my webCoRE pistons to RM. I have a question about repeating.
So in webCoRE I can set a repeat until and once that until is met it automatically stops what's happening. For example I have my own DIY alarm system. When the Security Alarm switch turns on it casts a 20 second file on my Google Homes. I want this to repeat until the door that's open is closed, see Piston example below. I tried doing this in RM and can set the repeat until but the casted file continues playing and always repeats at least once before it stops. I tried creating a separate rule to stop repeating actions and this partially works as the file will stop automatically. It will, however, still complete one more 20 second repeat though at the 20 second mark from the first set of actions.
For help with repeats, I like to refer people to the first post in this thread, which contains several examples:
The topic at hand here is notifications, but that doesn't really matter (that is just the contents of the repeat); the crux of the issue is how to stop repeats when a condition is met, which these examples demonstrate.
I attempted to do it this exact way last night. What happens in this scenario is the 20 second file will finish playing it's 20 seconds. Meeting the until condition doesn't stop a repeat action dead in its tracks like the piston does I have posted above. If i set a rule like that and have another one that tells the Google Homes to stop based on the contact closing it stops immediately. However, the repeat rule will run thru one more repeat and only then will it say oh the door is closed now I can stop.
I agree that it does run well albeit still a slight bit slower than rule machine. webCoRE also does take up quite a heavy load on the hub... but I'm guessing with only 5 pistons running that only fire if someone opens a door when they aren't supposed to that the load won't be too heavy. Plus my 'OCD' makes it where it'll bug me not to have everything on RM. lol
Well 5 Pistons plus variables that I wouldn't be able to move as those pistons subscribe to presence sensors and people in bed variables. lol.
That's going to generally run through one more repeat because you're checking it right as the repeat finishes (when the device is likely to still be in the same state), not before (or right after) it starts again. Any of the first three examples in the thread I linked to above show how to handle it in a way that won't do that, assuming this is concerning that issue: