You’ve got the head plugging in to the tail on this, triggering from devices being modified and then modifying devices on the fly that caused the trigger. Nothing is atomic or guaranteed, including the timing of Z-Wave messages, so you’re fighting a losing battle here. The best I can offer you is these changes, but if this doesn’t cut it, you probably should rethink your approach.
-
master_dimmer_off_ondoesn’t have a delay reset option set on it. I would add one. - Activity
master_dimmer_off_onhas a Set Variable action with a re-eval forced; I would turn that re-eval off.
Also, just looking at this, master_dimmer_change and master_dimmer_off_on are going to trigger at the same time when the dimmer is going from off to anything, with two different activities. Short of using more delays, there’s no guarantee which will run first, or what problems that conflict may create.
Can you also go to the Tools page, you’ll find a link in Troubleshooting for the Logic Summary. Click that, and post the summary here. I’d like to see a little more about the overall environment.