I'll clone the rule and modify it like that with an end repeat to see if that makes a difference 
Well, like you, Iām happy to be corrected, because Iāve never left a REPEAT unterminated. But there are two possibilities, one as you mention, and another where the WHILE does an implied āend ruleā, which falls off the end immediately. Iāve never seen the āmissing END-REPā behavior definitively defined.
1 Like
Everything between the WHILE and the END-REP will be repeated. In your example nothing is between the WHILE and the END-REP. Nothing will be repeated even if you add the end-rep.
1 Like
Thatās my understanding, too. The last action is not the same as a wait for condition.
Here's an example... RM evaluates the condition at the time of the WHILE. If the condition is true it will repeat all actions until the END-REP. If not it skips the whole block. In this example it will attempt to send disarm commands to envisalink every 5 seconds up to 10 times as long as the status does not contain Ready.
1 Like
This is correct. See the Rule 5.1 docs for a couple examples of repeats:
https://docs.hubitat.com/index.php?title=Rule-5.1#Repeat
More to come, but the Repeat, including "While..." syntax, is documented. 
You can also see this thread for some older examples, which let you do the same thing with a slightly different syntax (but it will still work): How to get Repeated Notifications using Rule Machine
1 Like
Also... @bertabcd1234 you may know better than I... but I think %time% is the time the trigger event occurred... ?
1 Like
Yes. %now% is current time.
2 Likes
@johnwill1 what you could do is put the WHILE statement at the beginning of the rule and the END-REP at the end... but in that case you need something to manipulate notificationOn... otherwise it will just loop forever every 10 seconds. Unless it's a hub variable manipulated outside of this rule.
OK. So I updated the rule like this:
That seems to sort it out so that the tile representing the variable "scrolls" through the switches that are on and it does now repeat though it doesn't seem quite right. Switches 1, 2 & 3 are all on and it is scrolling 1,2,1,3,1,2,1,3. Maybe altering a switch while the repeat is active is firing multiple instances - it's difficult to see from the logs. Perhaps there's a better way of achieving the same end result...
With regard to the time - I was hoping that %time% would give me the time that the specific switch was turned on and that the time would stick if another switch was turned on. However lets say I turn switch1 on at 19:15 - the variable will show that; However if I subsequently turn on switch2 at 19:25, the time for switch1 is also updated to 19:25. So it is displaying the time the rule was triggered last even if it is not that particular switch that triggered it. As such the %time% is unusable as it becomes "incorrect" as soon as the status of another switch changes. These virtual switches are intended to show the time the event happened that caused the virtual switch to operate.
One solution could be 3 rules, one for each switch.
It is - notificationOn goes false when all 3 switches are turned off via another RM url that also sets the votificationActive variable to null, so that I get a blank tile when nothing is active.
1 Like
Yes. Any change to any of the three switches will spin up a concurrent instance of the rule. This can be prevented with some logic involving the "private boolean" function if you want to go there.
And gotcha on the notificationOn!
1 Like
That seems to be the ethos of RM (at least in my limited experience). Why use 1 rule when you can do it with 3 
LOL. Let me phrase it another way. Sometimes three simple rules is easier than one more complex rule.
I do! If I can get this to work how I want I can go to bed both smug AND drunk!
1 Like
Anything I can do to advance your cause I am happy to.
Private Boolean is - wait for it - a boolean variable private to the rule. By default it is true. But it can be used to prevent a rule repeating, as in the example below... if private boolean is false it means the rule is already running so abruptly exit the rule. Otherwise set it false so a second trigger will just exit harmlessly. And at the end don't forget to set it true again!
You can do some sneaky stuff with PB too - like turn on one rule's PB from another rule. But all you need for this is the basics.
BTW the rule above was written before "use required expressions" became a thing. So you can use that instead to make things a bit smoother.
2 Likes
The reason I've set this up (or am attempting to) the way I have is to simplify it, as and when I need more notifications. With one virtual switch for each notification, one variable that goes true/false if any switch is on and one variable for the notification text itself; it should be relatively quick to amend. One rule and one virtual switch for each individual event and I'd simply need to add one. line in the main rule.
Good logic for sure.
Here's an example of some WHILE/END-REP and the private boolean used with required expression... kind of a busy rule but you get the idea. This particular one does a safety check of sorts of my security system and confirms that HSM, Envisalink, and the keypads remain in sync. Sorry for the eye chart. You'll have to read it before a few cocktails.
1 Like
