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_on
doesn’t have a delay reset option set on it. I would add one. - Activity
master_dimmer_off_on
has 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.