This is set up in conjunction with a dashboard to give a visual indication that intrusion alert delay is active. It is then intended to stop when delay expires or system is disarmed. Several times it has gotten stuck even after disarm. I'd appreciate any thoughts.
It's really hard to read your screeen shot... looks like it came from a phone.
Without pouring over the logic too much I'm guessing it has something to do with your use of the alertHSM boolean. I don't see where that variable is getting manipulated so it's hard to see exactly what it's doing but that would be my first place to look.
1 Like
I just noticed that the global variable alertHSM did not have a connector. I was still able to use it though. Would this have anything to do with it?
I can't see anything offhand, though in case this affects the logic you intended to use, the repeat will continue when either HSM is not armed or the variable is false (the NOT is scoped over only the first condition). So if that variable isn't getting set to false for some reason, the loop will continue regardless of HSM status.
To get to the bottom of your problem, I'd suggest turning on at least events and actions logging for the rule, as well as as leaving "Display current values" checked (as it appears you currently do). The logs will then reveal what is happening when and should be helpful in figuring out the "why" part.
I can offer a couple comments on the rule in general, as well, most of which I can't imagine would cause this problem but still might be good to know:
- No need (and in fact, no effect) to put a delay as the last action inside a repeat. It doesn't do anything, since the repeat interval is determined on the "Repeat every..." line itself (9 seconds), not how long it takes to complete the actions inside the repeat.
- No need (and again, no effect) to put a "Stop Repeating Actions" after the
Repeat ... END-REPblock, as if you've reached that line, the repeat has already stopped. Your logic in the "Repeat while..." should determine when the repeat stops (and it does not need to be marked as stoppable in this case, though it won't hurt).
I assume you mean "hub variable"? Your screenshot must be Rule 5.x ("Repeat while" didn't exist yet in Rule 4.x, and global variables are a pre-5.0 feature...unless you did, in fact, create a connector and managed to use it here somehow). Rule 5.x, as well as an increasing number of apps, can use hub variables directly--no connector needed, and in fact, the creation of new connectors will be deprecated at some point as more apps allow this kind of usage.
1 Like
I don't think the fact that there's no connector would affect how you use the variable within RM. If you're trying to manipulate it externally to RM, then perhaps. The variable itself? Possibly.
I had added those elements in an attempt to "cut off" the audible and visual results of the repeat actions. I was getting a run on where the repeating would stop but only after it finished the "cycle" it was on. This seemed very clunky to me.
Yeah, that's normal--the check happens before the next repeat, not constantly throughout the actions inside the repeat. If you want that, you'll have to put a conditional before or around the actions you want and proceed appropriately.
I'm not sure I follow
So right now, inside your repeat, you have a series of actions like:
Delay 0:00:06
Speak...
If you want to not proceed with that Speak action if some condition/expression is true or false, you'll need to check that--something like:
Delay 0:00:06
IF (Condition is true) THEN
Speak...
END-IF
(And really, you'll probably want to nest the remainder of your actions inside that conditional--and consider the possibility that you may need to nest even more conditionals inside if you want to perform additional checks at any future point inside the repeat.)
A "Stop Repeating Actions," again, doesn't cancel an in-progress repeat--just stops it from starting again.
2 Likes
