[2.3.0.124 C7]
Today an RM4 rule set the target lights to the wrong dim value. This RM4 rule (see below) has been working every day for a long time. Nothing in the hub or hub firmware has changed in weeks. BTW both devices are NOT Z-Wave Plus but have been working fine.
Looking for other automations that may be the culprit I found nothing. And if something else had caused it, it would have had to happen at the exact second of the below rule AND it would have somehow squelched the below rule without a log error.
My solution will be to rewrite this rule in RM5.1 but I will wait until tomorrow to see if it happens again ( I doubt it but will see).
Anyone have any similar occurrences?
This is not a very good way to do what you're trying to do, with 3 triggers and a Conditional action, and your rule has a spurious condition in the first ELSE-IF. Instead, trigger it at 10:00 AM only. Then do the first actions. Next, Wait for Event 10:30 PM, do the action for that time. Next, Wait for Event 1:00 AM and followed by the last action. You also have a Mode action that appears to be broken.
If you install the rule described above after 10:00 AM but before 10:30 PM, do a Run Actions on it to get the first Wait for Event set up. If you install it after 10:30 PM it wouldn't work until the next day.
Thanks, I'll study the differences and hopefully learn 
John
@JohnRob did you notice the light not at the correct level or are you using the value in the logs to say is wasn't set correctly? I think it's odd that your trigger is 10:00 AM and this light turned on 5 seconds later, seems slow. It also seems odd that the light level report 2 milliseconds after it was turned on. Did the device page also show the light at 2%?
Both. I first noticed the lights were off (actually really dim). Then the logs showed the very low dim levels.
However as bravenel pointed out my first else-if had an error where I had change some of the mode structure without remembering this rule uses the Mode as well. So the NOT in the else-if was an error.
I've rewritten it in RM5.1 and I expect it to be fine.
I still have to understand why bravenel's suggest approach it better.
Instead of triggering at three different times and then having to use conditional actions to figure out why the rule triggered and what to do, you can just trigger at the first time, then do a "Wait for event" for the subsequent times. This frees you from doing the work of needing to figure out what to do in the actions--you already know what's happening if you got to that point. It's also marginally easier on the processing side of things, though that difference should be negligible; the biggest impact is just fewer clicks for you (and an easier rule to read).
Another thing you might want to consider are those "Dim: 0" actions. For most devices, this is the same as just doing an "Off," though for some it provides an advantage of letting you specify a transition time (which you aren't doing here, so presumably that wasn't your motivation). Rarely, the device/driver just doesn't like 0% as a value for "Set Level" (the command this action calls). If you aren't having problems with the devices actually tuning off, this might not be worth changing, but since you're re-writing the rule anyway, "Off" is normally a safer choice if that's all you care about.
If the rule still doesn't work as you expect, you may wish to consider turning on logging. That will tell you what the rule is doing when, so you won't have to guess quite as much based on the times in your logs (or info logs from the device, which generally just show what was reported back from the device and not necessarily what was sent to it).
Thanks for the detailed reply, I appreciate your time and effort
I'll admit currently I am shying away from wait or delay as I have another issue (different two rules) where when one rule attempts to turn ON a light that is currently ON in a Delay function of another rule, the light never gets shut OFF from either. But what I suggest is the issue may not be.
Having said that, I'm not sure how the suggested approach is all that much easer to enter and think through.
The 1st ELSE-IF should have been:
ELSE-IF (time is 10:30PM AND MODE is NOT PartyMode) Then
......
.....
So if instead of the above I used;
WAIT EVENT (time = 10:30PM AND NOT PartyMode) Then
.....
....
Or some such as I'm not familiar with complex WAIT EVENT statements.
BTW I have been using switch off for dimmers for a while. The above is a RM4.0 Rule and I switched to RM5 as soon as it came out.
OK, I said "Wait for events," but in your case you could "Wait for expression" since you're looking to test multiple states. But since I think you want the rule to proceed to the next wait regardless, I'd probably stick to "Wait for event" and then just test the state with a conditional before performing the (possible) actions. So that first ELSE-IF could be replaced with something like:
Wait for event: time is 10:30 PM
IF (Mode is NOT Party Mode) THEN
Off: Light X, Light Y
END-IF
(A note on the difference: "Wait for events" proceeds when any of the specified events happens; "Wait for expression" proceeds when the provided expression--condition or combination of conditions--becomes true, or if it already is true.)
Then, you could follow that with a:
Wait for events: Time is 1:00 AM
Off: Light X, Light Y
Set Mode: Z
or whatever it is you were intending to do in that last set of actions.
I'm not sure what the on/off issue is in your other rules, but if you're having trouble with those, you might want to post more information about each.
Good luck!
