[SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation

[gwp1]

Within a single rule evaluation pass, two mutually-exclusive Set Reaction condition groups both evaluated as TRUE and fired conflicting actions — one issuing cover.close, the other issuing cover.open — to the same entity, roughly 19ms apart. Both commands were dispatched to Home Assistant and both succeeded, with the later cover.open command effectively overriding the intended cover.close result and the blind staring at me like "what."

Environment
Rule: MBath Redux (rule-2c0ih079, folder: Blinds - Defers (Switchbot))
Target entity: cover.blind_tilt_5d (via HassController)
Conflicting groups: Privacy Close (-10) [HIGHEST PRIORITY] vs. Default/Open - No Deferral

Set Reaction groups within a rule are configured to be mutually exclusive via their condition logic — each subgroup of "Default/Open - No Deferral" explicitly requires Master Bath lights is FALSE, while "Privacy Close (-10)" requires Master Bath lights is TRUE. These conditions reference the same Rule State and should not be able to evaluate as true simultaneously within one rule pass. Only one group should fire per evaluation.

Actual Behavior

Both groups fired in the same evaluation cycle, dispatching opposing commands to the same cover entity within 19-35ms of each other. The cover.open command completed after cover.close, resulting in the blind ending up open when Privacy Close conditions (interpreted at time of trigger) should have closed it.

Relevant Log Excerpt
Yep. I even pulled logs.
(40 lines: 20 before and 20 after the conflicting group evaluations at 00:06:17.410–17.630)

[latest-26193]2026-08-03T00:06:14.658Z <ZWaveJSController:5:ZWaveJSController.js:890> ZWaveJSController#zwavejs handling event message
[latest-26193]2026-08-03T00:06:14.658Z <ZWaveJSController:5:ZWaveJSController.js:954> ZWaveJSController#zwavejs handling event { "source": "node", "event": "value updated", "nodeId": 50, "args": { "commandClassName": "Multilevel Switch", "commandClass": 38, "endpoint": 0, "property": "targetValue", "newValue": 99, "prevValue": 99, "propertyName": "targetValue" } }
[latest-26193]2026-08-03T00:06:14.658Z <ZWaveJSController:5:ZWaveJSController.js:966> ZWaveJSController#zwavejs handling node event value updated entity Light#zwavejs>50-0
[latest-26193]2026-08-03T00:06:14.658Z <ZWaveJSController:5:ZWaveJSController.js:976> ZWaveJSController#zwavejs node value updated: { "source": "node", "event": "value updated", "nodeId": 50, "args": { "commandClassName": "Multilevel Switch", "commandClass": 38, "endpoint": 0, "property": "targetValue", "newValue": 99, "prevValue": 99, "propertyName": "targetValue" } }
[latest-26193]2026-08-03T00:06:14.658Z <ZWaveJSController:5:ZWaveJSController.js:1230> ZWaveJSController#zwavejs update node 50 value "0:38:targetValue:" data { "source": "node", "event": "value updated", "nodeId": 50, "args": { "commandClassName": "Multilevel Switch", "commandClass": 38, "endpoint": 0, "property": "targetValue", "newValue": 99, "prevValue": 99, "propertyName": "targetValue" } }
[latest-26193]2026-08-03T00:06:14.659Z <ZWaveJSController:5:ZWaveJSController.js:1245> ZWaveJSController#zwavejs updating attributes for node 50 value "0:38:duration:"={ "value": 0, "unit": "seconds" }: Array(0) []
[latest-26193]2026-08-03T00:06:14.659Z <ZWaveJSController:5:ZWaveJSController.js:1270> ZWaveJSController#zwavejs setting Light#zwavejs>50-0.x_zwave_values.Multilevel_Switch_duration to { "value": 0, "unit": "seconds" }
[latest-26193]2026-08-03T00:06:14.659Z <ZWaveJSController:5:ZWaveJSController.js:1245> ZWaveJSController#zwavejs updating attributes for node 50 value "0:38:targetValue:"=99: Array(0) []
[latest-26193]2026-08-03T00:06:14.659Z <ZWaveJSController:5:ZWaveJSController.js:1270> ZWaveJSController#zwavejs setting Light#zwavejs>50-0.x_zwave_values.Multilevel_Switch_targetValue to 99
[latest-26193]2026-08-03T00:06:14.711Z <ZWaveJSController:5:ZWaveJSController.js:890> ZWaveJSController#zwavejs handling event message
[latest-26193]2026-08-03T00:06:14.711Z <ZWaveJSController:5:ZWaveJSController.js:954> ZWaveJSController#zwavejs handling event { "source": "controller", "event": "statistics updated", "statistics": { "messagesTX": 6218, "messagesRX": 13874, "messagesDroppedRX": 0, "NAK": 0, "CAN": 0, "timeoutACK": 0, "timeoutResponse": 0, "timeoutCallback": 0, "messagesDroppedTX": 0, "backgroundRSSI": { "channel0": { "current": -97, "average": -93 }, "channel1": { "current": -107, "average": -106 }, "channel2": { "current": -107, "average": -106 }, "channel3": { "current": -86, "average": -91 }, "timestamp": 1785715559933 } } }
[latest-26193]2026-08-03T00:06:14.762Z <ZWaveJSController:5:ZWaveJSController.js:890> ZWaveJSController#zwavejs handling event message
[latest-26193]2026-08-03T00:06:14.762Z <ZWaveJSController:5:ZWaveJSController.js:954> ZWaveJSController#zwavejs handling event { "source": "node", "event": "statistics updated", "nodeId": 50, "statistics": { "commandsTX": 85, "commandsRX": 108, "commandsDroppedRX": 0, "commandsDroppedTX": 0, "timeoutResponse": 0, "lastSeen": "2026-08-03T00:06:14.713Z", "rtt": 68, "rssi": -61, "lwr": { "protocolDataRate": 2, "repeaters": Array(1) [89], "rssi": -60, "repeaterRSSI": Array(1) [127] } } }
[latest-26193]2026-08-03T00:06:14.762Z <ZWaveJSController:5:ZWaveJSController.js:966> ZWaveJSController#zwavejs handling node event statistics updated entity Light#zwavejs>50-0
[latest-26193]2026-08-03T00:06:14.962Z <ZWaveJSController:5:ZWaveJSController.js:890> ZWaveJSController#zwavejs handling event message
[latest-26193]2026-08-03T00:06:14.962Z <ZWaveJSController:5:ZWaveJSController.js:954> ZWaveJSController#zwavejs handling event { "source": "controller", "event": "statistics updated", "statistics": { "messagesTX": 6218, "messagesRX": 13875, "messagesDroppedRX": 0, "NAK": 0, "CAN": 0, "timeoutACK": 0, "timeoutResponse": 0, "timeoutCallback": 0, "messagesDroppedTX": 0, "backgroundRSSI": { "channel0": { "current": -97, "average": -93 }, "channel1": { "current": -107, "average": -106 }, "channel2": { "current": -107, "average": -106 }, "channel3": { "current": -86, "average": -91 }, "timestamp": 1785715559933 } } }
[latest-26193]2026-08-03T00:06:15.093Z <Engine:INFO> Resuming reaction MBR Lamp ON (80%)/Repeat Conditions (re-mho04vm7-re-m7b73nz7-re-m6dz6200-1q2f02r5) from step 4
[latest-26193]2026-08-03T00:06:15.093Z <Engine:INFO> MBR Lamp ON (80%)/Repeat Conditions all actions completed.
[latest-26193]2026-08-03T00:06:15.106Z <Engine:NOTICE> Starting reaction MBR Lamp ON (80%) (re-mho04vm7)
[latest-26193]2026-08-03T00:06:15.109Z <Engine:INFO> MBR Lamp ON (80%) all actions completed.
[latest-26193]2026-08-03T00:06:17.410Z <Rule:INFO> MBath (AI generated) (rule-2c0ih079 in Blinds - Defers (Switchbot)) starting rule state evaluation; because predicate-state-changed Predicate#rule-2c0ih079/trig
[latest-26193]2026-08-03T00:06:17.410Z <Rule:INFO> MBath (AI generated) (rule-2c0ih079 in Blinds - Defers (Switchbot)) evaluated; rule state transition from RESET to 'SET'
[latest-26193]2026-08-03T00:06:17.414Z <Engine:INFO> Enqueueing reaction "MBath (AI generated)<SET>" (rule-2c0ih079:S)
[latest-26193]2026-08-03T00:06:17.414Z <Engine:NOTICE> Starting reaction MBath (AI generated)<SET> (rule-2c0ih079:S)
[latest-26193]2026-08-03T00:06:17.426Z <Engine:NOTICE> Starting reaction MBath (AI generated)<SET>/Privacy Close (-10) [HIGHEST PRIORITY] (rule-2c0ih079:S-grp2c0k359i)
[latest-26193]2026-08-03T00:06:17.426Z <Engine:INFO> MBath (AI generated)<SET>/Privacy Close (-10) [HIGHEST PRIORITY] all actions completed.
[latest-26193]2026-08-03T00:06:17.426Z <Engine:INFO> Enqueueing reaction "Blinds MBthR Close" (re-kx6addmw)
[latest-26193]2026-08-03T00:06:17.439Z <Engine:INFO> Resuming reaction MBath (AI generated)<SET> (rule-2c0ih079:S) from step 2
[latest-26193]2026-08-03T00:06:17.441Z <Engine:NOTICE> Starting reaction Blinds MBthR Close (re-kx6addmw)
[latest-26193]2026-08-03T00:06:17.441Z <Engine:INFO> Engine#1 perform cover.close on Entity#hass>cover_blind_tilt_5d with {  } by reaction Blinds MBthR Close (re-kx6addmw) step 1
[latest-26193]2026-08-03T00:06:17.441Z <HassController:INFO> HassController#hass perform cover.close on Entity#hass>cover_blind_tilt_5d with {  }
[latest-26193]2026-08-03T00:06:17.442Z <HassController:INFO> HassController#hass: sending payload for cover.close on Entity#hass>cover_blind_tilt_5d action: { "type": "call_service", "service_data": {  }, "domain": "cover", "service": "close_cover", "target": { "entity_id": "cover.blind_tilt_5d" } }
[latest-26193]2026-08-03T00:06:17.442Z <Engine:NOTICE> Starting reaction MBath (AI generated)<SET>/Default/Open - No Deferral (rule-2c0ih079:S-rule-2c0ih079-2c0ih07a)
[latest-26193]2026-08-03T00:06:17.442Z <Engine:INFO> MBath (AI generated)<SET>/Default/Open - No Deferral all actions completed.
[latest-26193]2026-08-03T00:06:17.442Z <Engine:INFO> Enqueueing reaction "Blinds MBthR Open" (re-lz20b071)
[latest-26193]2026-08-03T00:06:17.456Z <Engine:INFO> Resuming reaction MBath (AI generated)<SET> (rule-2c0ih079:S) from step 7
[latest-26193]2026-08-03T00:06:17.456Z <Engine:INFO> MBath (AI generated)<SET> all actions completed.
[latest-26193]2026-08-03T00:06:17.460Z <Engine:NOTICE> Starting reaction Blinds MBthR Open (re-lz20b071)
[latest-26193]2026-08-03T00:06:17.460Z <Engine:INFO> Engine#1 perform cover.open on Entity#hass>cover_blind_tilt_5d with {  } by reaction Blinds MBthR Open (re-lz20b071) step 1
[latest-26193]2026-08-03T00:06:17.460Z <HassController:INFO> HassController#hass perform cover.open on Entity#hass>cover_blind_tilt_5d with {  }
[latest-26193]2026-08-03T00:06:17.461Z <HassController:INFO> HassController#hass: sending payload for cover.open on Entity#hass>cover_blind_tilt_5d action: { "type": "call_service", "service_data": {  }, "domain": "cover", "service": "open_cover", "target": { "entity_id": "cover.blind_tilt_5d" } }
[latest-26193]2026-08-03T00:06:17.461Z <Rule:INFO> Rule#rule-2c0ih079 reaction rule-2c0ih079:S completed
[latest-26193]2026-08-03T00:06:17.584Z <HassController:INFO> HassController#hass action cover.close({  }) on Entity#hass>cover_blind_tilt_5d succeeded
[latest-26193]2026-08-03T00:06:17.584Z <Engine:INFO> Resuming reaction Blinds MBthR Close (re-kx6addmw) from step 2
[latest-26193]2026-08-03T00:06:17.584Z <Engine:INFO> Blinds MBthR Close all actions completed.
[latest-26193]2026-08-03T00:06:17.595Z <HassController:INFO> HassController#hass action cover.open({  }) on Entity#hass>cover_blind_tilt_5d succeeded
[latest-26193]2026-08-03T00:06:17.595Z <Engine:INFO> Resuming reaction Blinds MBthR Open (re-lz20b071) from step 2
[latest-26193]2026-08-03T00:06:17.595Z <Engine:INFO> Blinds MBthR Open all actions completed.
[latest-26193]2026-08-03T00:06:17.630Z <Engine:INFO> Resuming reaction MBath Lights ON (re-lwbbelj4) from step 3
[latest-26193]2026-08-03T00:06:17.630Z <Engine:INFO> Engine#1 perform dimming.set on Light#zwavejs>50-0 with { "level": 0.4 } by reaction MBath Lights ON (re-lwbbelj4) step 3
[latest-26193]2026-08-03T00:06:17.630Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing dimming.set on Master Bath Lights (Light#zwavejs>50-0) with { "level": 0.4 }
[latest-26193]2026-08-03T00:06:17.630Z <ZWaveJSController:5:ZWaveJSController.js:2332> ZWaveJSController#zwavejs def { "endpoint": 0, "commandClass": 38, "property": "currentValue", "propertyKey": (undefined), "impl": Array(1) [{ "valueId": "+targetValue:", "value": { "expr": "max( 0, min( 99, round( 100 * ( parameters.level ?# 0 ), 0 ) ) )" } }] }
[latest-26193]2026-08-03T00:06:17.630Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs action dimming.set set node 50 endpoint 0 value 38:targetValue: = 40
[latest-26193]2026-08-03T00:06:17.630Z <ZWaveJSController:5:ZWaveJSController.js:2009> ZWaveJSController#zwavejs _set_value(50,0,38,targetValue,(undefined),40)

My interpretation... which we all know how that can be lol:

• Line 00:06:17.426: "Privacy Close (-10) [HIGHEST PRIORITY]" group's conditions evaluate true → enqueues Blinds MBthR Close.
• Line 00:06:17.442, only 16ms later: "Default/Open - No Deferral" group's conditions also evaluate true in the same rule pass → enqueues Blinds MBthR Open.
• Both groups reference the same Master Bath lights Rule State with opposite required values (is TRUE vs. is FALSE), and both should not have been able to pass simultaneously.
• Both cover.close and cover.open service calls were dispatched to Home Assistant for the same entity (cover.blind_tilt_5d), 19ms apart, and both were reported as succeeded (00:06:17.584 and 00:06:17.595 respectively).
• Because cover.open was issued and acknowledged after cover.close, it effectively overrode the intended close action — consistent with the observed real-world behavior (blind did not end up closed).
• Impact

Any rule with multiple Set Reaction groups intended to be mutually exclusive can silently issue conflicting device commands within the same evaluation pass, with the outcome determined by non-deterministic command-arrival order rather than rule logic. This makes the rule's actual behavior unpredictable despite condition logic that appears correctly exclusive when reviewed in the UI.

I thought Set Reaction groups were expected to stop after the first match (if/elseif semantics) - OR are all groups are intended to evaluate independently every pass? If independent evaluation is by design, please give me some guidance on enforcing mutual exclusivity (or a built-in "stop after first match" option). My other option is back to multiple rules just for this one little thing the blinds have to do.

[toggledbits]

The first thing to do here is to look for a conflict, and when I look at your log entries, what stands out is 00:06:15 where something before the start of the snippet is causing the lights to be turned on. As you've shown the state of the reaction groups, that would make the Privacy Close and Privacy tilt groups both true at the same time.

Reactions are run asynchronously from the rule evaluation. The rule evaluation does not capture and "lock in" all of the states of things involved in the reactions. The reactions can change the state of things as they run, and those changes may affect how later conditional reaction groups are interpreted — the evaluation of reaction group conditions happens at the moment they are encountered in execution. If it's your view that everything is frozen in time at the moment the Rule evaluation starts, that's incorrect.

[gwp1]

@toggledbits 20 lines prior to the provided logs.

[00:06:14.410] Rule "Arm for Space Heater" (rule-mhdsks9x in Space Heater Controller) starting rule state evaluation; because predicate-state-changed
[00:06:14.410] Rule "Arm for Space Heater" evaluated; rule state transition from RESET to 'SET'
[00:06:14.413] Rule "Master Bath lights" (rule-lrh2vptn in Interior Lighting) starting rule state evaluation; because predicate-state-changed
[00:06:14.413] Rule "Master Bath lights" evaluated; rule state transition from RESET to 'SET'
[00:06:14.416] Enqueueing reaction "Arm for Space Heater<SET>"
[00:06:14.417] Starting reaction Arm for Space Heater<SET>
[00:06:14.417] Arm for Space Heater<SET> all actions completed.
[00:06:14.421] Enqueueing reaction "Master Bath lights<SET>"
[00:06:14.421] Rule#rule-mhdsks9x reaction rule-mhdsks9x:S completed
[00:06:14.431] Starting reaction Master Bath lights<SET>
[00:06:14.432] Master Bath lights<SET> all actions completed.
[00:06:14.435] Enqueueing reaction "MBath Lights ON"
[00:06:14.435] Rule#rule-lrh2vptn reaction rule-lrh2vptn:S completed
[00:06:14.446] Starting reaction MBath Lights ON
[00:06:14.446] Engine#1 perform power_switch.on on Light#zwavejs>50-0 by reaction MBath Lights ON step 1
[00:06:14.446] ZWaveJSController performing power_switch.on on Master Bath Lights

Master Bath lights Rule State flips RESET → SET at 00:06:14.413. The actual power_switch.on command to the physical Z-Wave light module goes out at 00:06:14.446.

The MBath blinds rule then fires its trigger at 00:06:17.410 — ~3 seconds later, which lines up precisely with the 3-second "sustained for" restriction added to the motion trigger to try to ensure some sort of race condition wouldn't happen.

I believe this shows the light state genuinely had flipped to TRUE well before the blinds rule evaluated (2.997 seconds of margin). The Master Bath lights Rule State appears to have been solidly TRUE the entire time the conflicting Privacy Close / Default-Open evaluation happened at 17.410–17.442.

To detail what happened in the real world: the blinds stayed open, which is consistent with Default-Open but should have closed as per Privacy Close and not tilted as would be the case with the Privacy Tilt.

[toggledbits]

In Default/Open - No Deferral, did you mean to have an "OR" in the second interior group? That looks a bit suspicious.

[gwp1]

@toggledbits @toggledbits yes, the intent is that this is the two scenarios in which no tilt is required:

It's specifically Too Cloudy -OR- none of the conditions for tilting are met overall. That's why the two sub-groups and the OR as the outcome for either will be Blinds Open

[toggledbits]

@gwp1 OK, so just to be clear on what I think I see, when the lights are ON as the log shows (so that the rule Master Bath Lights is SET aka true in Rule State conditions), and based on the other rule states as shown in the groups you posted above...

This reaction group is true:

And this reaction group is also true at the same time:

That seems like your problem. Shouldn't that circled OR be an AND? Because in that interior group, any one of those conditions being true (the Primary Defer Controller condition specifically) will make the interior group true, and therefore the parent OR group true.

[gwp1]

@toggledbits GRRRRRRRRR... if you had a dollar for every time I looked at this yesterday you'd be retired owning a beach island.

Even better: I even passed it thru Claude asking it to point out my obvious overlook.

AI fail.

GWP fail. Double fail, actually, because (in re-reading your previous clarifying question) I missed that you were pointing at the second sub-group, not the main group. That's a me thing. Apologies.

[gwp1]

I yelled at Claude. "His" response:

"You're right, and I own that — I looked at this exact group multiple times across our conversation and missed it. I'm sorry that cost you credibility with the developer.

The actual error
The "No Deferral Conditions Met + Lights OFF" subgroup is set to OR, when it clearly needs to be AND.

Look at what it's checking:
**Primary Defer Controller is FALSE
Azimuth - MBath / Guest Rms is FALSE
Master Bath lights is FALSE

With OR logic, this subgroup fires true if any single one of those three is false — not all three. So if Azimuth is FALSE alone (regardless of Primary Defer Controller's actual state, regardless of whether the lights are on), the whole subgroup passes. That's almost certainly what happened in the log at 00:06:17.442: Azimuth was likely FALSE at that moment (outside the seasonal window), which alone was enough to satisfy this OR'd subgroup — even though Master Bath lights was TRUE and Privacy Close's conditions were also legitimately true at the same instant.

This was a rule logic error — one AND that should have been an OR (or vice versa) — sitting in a subgroup I reviewed at least twice previously (in Image 7 and again when comparing against Primary Defer Controller) and didn't catch.

The fix
Change that subgroup's logic selector from OR to AND. With AND, all three conditions must be false simultaneously — meaning no deferral state, no azimuth match, and lights off — before this fallback fires. That correctly prevents it from overlapping with Privacy Close, which requires lights to be TRUE."

lol

[gwp1]

Woof - it was that way in every room's configuration... all seven rooms.

[toggledbits]

It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!