In my case I also have a couple repeats that repeat wile true and also with an N times specified. Similar to a time out on a wait statement.
So not a fifth type but combining the possibilities.
To be honest with you I was not aware that repeat offered a condition option. I always repeat with N specified and then use a IF in the body to stop repeating if a condition is true. I have found with RM4 that the loop still runs a couple times though after the stop repeating occurs.
@bravenel what's the reason we cant use HV as a trigger any more? I know we can create the connector which is what I have done. but it just seems like a extra step and some what less efficient?
I almost always use the conditional while for this reason, I find it works better. I just have a LV that I set in the rule with the conditions, then at the end I use the simple condition with the Boolean and repeat action to do what I want.
Any more?
Global Variables, as a part of Rule Machine Legacy could be used as triggers, as the parent app did all of the work (hence Global Variables could be slow).
Hub Variables do not generate events. We didn't think we should create an entirely new event infrastructure just for Hub Variables, especially when Connectors exist and do generate events. When a Hub Variable (with Connector) changes state, it calls the Connector parse method, and that causes the appropriate event to be thrown. These events can be used like any other events in the system, i.e., in this case, as triggers.
We will continue to evaluate whether or not Hub Variables should generate events, and if so how that should be accomplished. But, Hub Variables are a brand new feature of the hub, and we are taking it slow in this regard.
Sorry I meant as in HV are a replacement for GV and you could do it with GV.
Thanks for the explanation 
@bravenel I'm not sure if it is just me, but when I have time announced via TTS in a rule it no longer says AM or PM. It changed with 2.2.8. I'm using %time%.
When you use %time% you can pick the time format. This shows up on the Action page after you've created an action with %time% in it. The default omits AM/PM, but that can be selected,
I'm having a problem with HV connectors in hub mesh. I've reproduced the error with multiple HV connectors and multiple hubs. Here's my process.
Except the connector switch on hub 2 is showing OFFLINE. On hub 1, the HV and its connector look and operate normally AFAIK. No other devices in the same mesh are showing OFFLINE. Are we not allowed to use HV connectors in hub mesh?
Did you share the parent device for the Connectors? That would have to be there as well.
I could not reproduce it, changing connector value either in Hub Variables or in the connector switch device would also change value on a linked device for me.
Which hub is the connector on and which hub doesn't pick up the value change? Hub names are ok, I can look them up.
Yes.
Actually, my description above was wrong. I didn't add the connector switch to the hub mesh (I don't think that's even possible, is it?)--I added the "Variable Connectors" parent device to the mesh. My understanding is that, just like GV Connectors, you add the parent holistically, not individual connectors.
My problem isn't with value change -- it's about the fact that the remote connector shows up as OFFLINE, even though other devices are fine. See "HE Upstairs Ground-SW" for remote hub and "Server" for hub where HV's are.
When I did it it showed the same issue, clicked sync all a few times at it seemed to take ( I also tried clicking other stuff but can't remember)
It was strange one time I looked it was OK, then went back to use it and it was off line then back it did it a few times
Are there other linked devices from the same hub and if yes, do they show up as offline? Is "Upstairs Ground-SW" hub reporting "Server" hub as visible on Hub Mesh page?
I suspect this is an issue of how hub mesh does discovery and maintains the list of active nodes afterwards as opposed to anything specific to remote connectors. My theory could be wrong, but it also is pretty easy to make hub mesh send more discovery requests and wait for replies longer.
This is exactly my experience too. The device seems to rotate between OFFLINE and normal, and back again periodically. Can't find a pattern. Even when it's offline, the hubmeshdisabled state shows as FALSE, per the device details page. Also, I'm seeing repeated situations where, on the main device listing view, the device does not show as OFFLINE, then you click on the device to access the individual device details view, and it says DEVICE IS DISABLED in red text. Makes me wonder.
No, that's what I mentioned in the original post. It's what makes me suspicious of some other problem I'm not understanding.
Yes.
Is this something you want me to try somehow. Not sure what you're suggesting, but I'm game for anything! 
Edit: @gopher.ny, one other bit of insight that will hopefully be helpful to problem solving....from the device listing page, I see this:
If I simply reload the page, I get this:
Every time I reload the page, it cycles back and forth between those two states. Odd.
As a predicate, the day is tested at midnight. If I were to edit the rule at 9am to change one of the predicate days to today, does this mean I am too late for anything in the rule to run today, or will it re-evaluate the predicate when I save the changes?
It is re-evaluated when you hit Done (or Update Rule).
In the earlier discussion here about Predicate Conditions not allowing Local Variables, @bravenel suggested this wasn't a useful combination (so was disallowed) because only the rule could change the local variable, and the rule is already running.
However, there can be multiple instances of a rule running concurrently, and its common in Rule-4.X to use a local variable to help protect against these colliding (IF local-var=true EXIT-RULE as the first statement) . Since RM doesn't appear to have a nice mechanism to stop multiple instances of a rule, using a Predicate Condition with the same local variable seems natural in Rule 5.0, but that is not allowed.
@bravenel what is your recommendation in Rule 5.0 to protect against multiple instances of the same rule executing at the same time ? Thanks!
Download the Hubitat app
