Hi, i have some blinds controlled by a number variable (6 blinds). The number variable is controlled by a dimmer connector. This side of things works great with no issues. However sometimes one or two of my blinds don't open/close as expected. so i'm trying to get the rule to repeat if all 6 blinds don't open to the level which the variable dictates. For example: if variable is set to 25 then REPEAT open blinds to 25%, wait until all blinds don't reach 25% then repeat actions.
My rule doesnt work as expected and keeps jamming, i know its something to do with the wait and the repeat but i cant quite put my finger on it. Any help would be great 
PS, the ELSE is a trigger switch which runs a routine on alexa to say that the blinds are trying to close but the doors/windows are open.
Hi, @672southmain , you've been very helpful in the past which is extremely appreciated. I've not had any uptake on my query. Do you think you could offer any pointers please 
He may have more ideas, but unfortunately the screenshot of the logs you posted isn't very helpful: basically all of your actions are being skipped because that first conditional evaluated to false and the actions you're asking about it are contained inside it (and the ELSE-IF is also false, which is odd unless you set the variable to the same thing again since it should either be an increase or a decrease...). Or perhaps it is helpful: if this is unexpected, I'd start by investigating that. I've never used numeric variables increasing/decreasing as part of a conditional, so there may be something odd with how that works. Or, if you can get it to work as you expect and the actions inside still don't work as you hoped, then the logs may be more useful at showing why. Looking at just the repeated actions, it's not exactly like some examples I've seen (this thread is my favorite; it's about repeated notifications, but the pattern is applicable to any kind of repeat: How to get Repeated Notifications using Rule Machine), but it still looks like it should work to me.
Looking at this rule makes my head hurt. I’ve never seen a twisted interaction like this before.
First, I agree with Robert’s comments.
A minor nit that doesn’t affect operation: the final ELSE-IF (4 lines from the end) serves no purpose doing a test for increased because the initial condition on the first line, testing if decreased, when false, necessarily means that the ELSE-IF ... increased will always be true. You can only get into the rule if changed - it’s either increased or decreased.
Now for my observation: As I understand it, every time a rule triggers, all pending Waits are cancelled. So, initially, when you change the Dimmer Variable, you start out with nothing hung on the Wait for conditions.
As I understand your problem, your issue is that sometimes, some of the dimmers don’t dim. To me, that indicates a mesh issue, or else the commands are being tried too quickly. That’s hard to fix with a Rule. One approach would be to put the lights in a Group, Dim the Group, and let the Group handle the spacing of commands. If the lights are Zigbee or Hue, that would be even better because a Zigbee Group Messaging command could be sent. But that may not be the case, so you could let Hubitat Group handle the command spacing. That’s what I believe the underlying issue to be.
Now to the Rule. You haven’t shown how the Dimmer Variable is set up. Something odd is happening here, as shown in the logs.
Logs show that the Dimmer Variable went to 28, triggering the rule. However, the outermost IF and ELSE-IF testing that Dimmer Variable show it evaluating as 15. Not sure what is happening there.
I believe I can see why the Rule is jamming up, especially if your devices are correctly reporting their status (you don’t say whether these are Z-Wave, Z-Wave Plus, Zigbee, Lutron Caseta, or Hue; I’ve never had a Hue light or Caseta dimmer fail to execute a command properly).
Follow this (and ignoring the oddness of the Dimmer Variable evaluating as 15; perhaps a logging statement at the beginning would help debug):
You change the Dimmer Variable to 28. That triggers the Rule. Because it didn’t decrease, the first IF isn’t satisfied, and none of the interesting parts of the Rule execute. The last ELSE-IF did, as expected. A log showing decrease of the Dimmer Variable is needed.
But let’s assume the first IF had been satisfied. You fall through, and the Dim starts. You then hit the Wait for Conditions.
As I understand it, there are two types of drivers (and you haven’t said what type dimmers/lights these are): one type sends the command and prays that it works; another type sends the command and watches for the device to acknowledge - if no ack comes, the command is sent again. Also, some drivers immediately update device state when the command is sent, others wait for the acknowledgment.
Let’s assume your device’s driver updates state immediately, but the device never sees the command. In that case, the Wait will immediately be satisfied, the Repeat will stop, but your lights don’t all dim.
Or, let’s assume that your device’s driver only updates state when the acknowledgment comes, and even retries if necessary, but the device never sees the command. Your Wait will hang forever, which sounds like what you are seeing.
Again, my best suggestion would be to Dim the lights as a Group and let it be handled that way.
The other alternative would be to but a non-cancellable delay after the Dim, then, one by one, test each light to see if it’s in the correct state, and, if not, do another Dim on that light. This only works if the driver can interrogate and get the true state; some can’t and can only guess.
The real solution is to figure out why commands are being dropped and fix that. If it’s that the commands are being sent too quickly, then let Hubitat Groups or Zigbee Group Messaging handle that. If it’s a mesh issue, then address that.
Hope this helps you analyze the issues. Robert is much more knowledgeable than I am on home automation; I’ve only got him beat (by about a factor of two, at least, I would guess) on age.
@672southmain cheers for this very detailed response. I'm trying to digest everything you've written but it clearly makes sense on the face of it. Your knowledge has given me more insight into how RM works and is helping me greatly in becoming more advanced.
I've unpicked my rule and broken it down somewhat. I've split it into 2 separate rules for now. There's more work to do, but athough it's not completed yet, it's yielding the results as expected.
I didn't realise that a "repeat " evaluated the conditions each time it repeats, this clearly was causing many of my issues. Basically I thought the conditions were evaluated only once and then the repeat just repeated the bits and bobs immediately after the repeat actions.
So see image below, I assumed that once the upper red-blue was evaluated, then the repeating only occured between sections blue and blue. I don't realise that the repeat actually evaluates and repeats everything between red-red for every repeat.
I assume my interpretation is correct?
So for now and as a starting point, I've split my rule into 2 separate rules. One for blinds open and one for closed. The repeats work when one of the blinds (dimmers) don't open as intended. See below.
Hi @bertabcd1234 your help has been invaluable in enabling me to understand the repeats. The link from Bravenel really didn't disappoint. It took me a short while to understand, particularly because I was 6 beers in initially 
. However, you can see from the thread that between your input and @672southmain . I've managed to get my head around matters. I really do appreciate your support. I'm finding that RM is extremely addictive and I thoroughly enjoy learning. I just wish there were more users and devices in the UK. Thanks again
Robert Morris (@bertabcd1234) has often suggested (and I agree) the first post in the following thread as a good way to understand Repeats.
It’s a good supplement to the Rule Machine documentation for Repeat.
.
Yes.
Just for your understanding, not important for your rule, really:
The proper way to think about Repeat, Wait, and Delay is to remember that Hubitat is an event-driven system at its core. It doesn’t spin-wait on a timed delay or wait or “Repeat every xx seconds”. Instead, an event is scheduled to occur at the end of the time. When the END-REP occurs, execution stops, and only resumes when the timed event occurs, at which time the Repeat loop restarts. The “Stop Repeating Actions”, and Cancel Delayed Actions and Cancel Wait, etc., operate by unscheduling the scheduled event.
I note that you have not used “Simple Conditional … Action” for your Repeat loop. For the “Repeat While” construction present in other programming languages, RM has the “Simple Conditional Action” idiom where the Action is a Repeat. The drawback of this is that the Simple Conditional is, um, Simple, and cannot be a complex Boolean expression. However, your IF statements do involve a single condition, rather than a complex Boolean expression. If you need a complex expression, see my rule here for evaluating an alarm condition on the Litter Robot. The rule in question is the last rule in that post “Litter Robot Flash on Alarm”. It’s explained in the comment for that rule.
Fabulous! Just another couple of questions whilst I have your attention guys. (Cheeky) I can't seem to find any info on what This comparison means !=
Also is there any way for a trigger to work if a dimmer "drops" below or "rises" above a certain level. I know there is < and this > but I assume they relate to moving below/above rather than drops below/rises above.
Quite hard to put this one into words 
Not equals. Same as other programming languages.
Again, remember that Hubitat is an event model. Triggers are events, not Conditions (which are states).
Trigger A < B will only be satisfied when A becomes < B. If A is already < B from previous execution of the Rule, the trigger event will not occur until A becomes < B (i.e., A >= B and then A becomes < B).
Clear?
You learn by reading documentation and asking questions. We were all there once. As you gain experience, pay it forward and help others in areas where you have gained expertise.
Guys, many thanks for your help on this one. I now have my rule working perfectly which is a credit to your support. I've attached it for information. But basically, if one of my 6 blinds dont fire in the first instance, the rule checks and repeats until the blind matches the dimmer level of the trigger. Also if any of my doors/windows are open, then the blinds wont close and the V Blinds Closed Switch is triggered which creates some TTS using the Device Status Announcer App. Finally the very first IF in my rule turns off may patio lights if the blinds drop below 80%. Once again, thanks for your support guys. Very much appreciated @672southmain and @bertabcd1234
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
