I've seen many of you using Dynamic Group Controller. I'm using it myself for monitoring device battery levels. I've read and re-read the Dynamic Group Controller docs and still cannot come to an answer for my question so let me paint my scenario:

I've migrated from EchoSpeaks in Hubitat ('cause borked and seemingly unmaintained) to Alexa Devices in Home Assistant ('cause not borked in 2026.11.0) to be able to send TTS to my Echo devices.

In EchoSpeaks I could create groups. Sweet.

In Alexa Devices I don't seem to be able to do so. As such, my thought was "wait - isn't there a way in MSR?"

Is this an effective scenario that Dynamic Group Controller can be used for?

@toggledbits I honestly did not recall implementing any ACL or Access Control settings outside of adding a user.

That to say, this morning when I went in to start that work, I found entries in place. No recollection of adding them - but it made all of the above suddenly make much more sense.

I can remove the above post if it's way out.

When working you'll get this prompt for the code:

@tamorgen I asked Lumo to pull together everything that WORKED to get to the end goal (we had a lot of trial and error at times).

Good luck. YMMV.

Here's the working procedure — tested end-to-end with your Reactor instance.

Setting Up MFA for Multi-System Reactor (MSR)

Problem: Requesting http://<reactor_host>:8111/api/v1/mfa.add/<username>?askauth=1 from a browser or host shell returns ACCESS DENIED, even after entering valid admin credentials.

Root Cause: When access control is enabled (config/users.yaml exists), MSR restricts API access by default to localhost only. Traffic reaching a Dockerised Reactor from the host appears to come from Docker's bridge gateway (172.17.0.1), not 127.0.0.1, so it fails the default loopback rule and falls through to the catch-all deny.

Working Setup Procedure

Prerequisites

• MSR installed and running in Docker
• Target user exists in config/users.yaml and is a member of the admin group
• You have shell access to the host running the container

Step 1: Enter the Reactor Container

docker exec -it <container_name> sh

Replace <container_name> with your container name (e.g., reactor). Find it with:

docker ps | grep reactor

Step 2: Request the MFA QR Code From Inside the Container

Run the following command inside the container:

curl -s -o /tmp/qrcode.png -u <target_username> \
  http://localhost:8111/api/v1/mfa.add/<target_username>

When prompted, enter the target user's password.

Notes:

• -u <target_username> makes curl prompt for the password interactively (safer than typing it in the command line).
• The request originates from 127.0.0.1 inside the container, which matches the default ACL allowing loopback.
• The ?askauth=1 parameter is not needed here — it's only for the browser-based flow.

Step 3: Verify the Image Was Generated

ls -la /tmp/qrcode.png
head -c 8 /tmp/qrcode.png | od -An -tx1

You should see 89 50 4e 47 0d 0a 1a 0a — the PNG magic bytes. If you see 41 63 63 65 73 73 20 64 ("Access denied"), the file is stale from an earlier failed attempt. Redo step 2.

Step 4: Copy the QR Code to Your Desktop

exit
docker cp <container_name>:/tmp/qrcode.png ~/Desktop/qr-mfa.png

Or from a separate machine:

scp root@<host_ip>:/tmp/qrcode.png .

Step 5: Scan the QR Code

Open qr-mfa.png in any image viewer and scan it with your authenticator app (Google Authenticator, Authy, Aegis, 1Password, Bitwarden, Ente, etc.).

Alternative: Manual Entry
If your viewer can't display the image, install zbar-tools:

apt update && apt install -y --no-install-recommends zbar-tools
zbarimg --quiet ~/Desktop/qr-mfa.png

This outputs an otpauth://totp/... URI. Use the secret= value in your authenticator app's "Manual Entry" or "Setup Key" option.

Step 6: Test the Login

Log into the Reactor UI as the target user. You should be prompted for a six-digit code. Enter the code from your authenticator app.

Step 7: Clean Up the Seed File

Both the host and container copies contain the TOTP secret in plaintext. Delete them after enrollment:

rm -f ~/Desktop/qr-mfa.png
docker exec <container_name> rm -f /tmp/qrcode.png

Anyone who photographs this image can generate valid codes indefinitely.

Recovery (If You Lose the Authenticator)

The same procedure applies for clearing MFA. From inside the container:

docker exec -it <container_name> sh
curl -s -o /dev/null -u <admin_user> -w 'HTTP %{http_code}\n' \
  http://localhost:8111/api/v1/mfa.clear/<username_to_clear>

You'll need admin credentials. The endpoint is subject to the same default ACL rules, so it must be called from inside the container.

What Not to Do (Common Pitfalls)

Don't	Do
Run curl from the host shell against localhost or the LAN IP	Run the command from inside the container via docker exec
Use ?askauth=1 with curl	Only use it for the browser-based flow
Edit users.yaml to add ACL rules	Not required for the initial setup; stick to stock defaults
Paste my suggested YAML without validation	Use python3 -c "import yaml; yaml.safe_load(open('users.yaml'))" to verify first
Re-run mfa.add after enrolling	It may rotate the secret and invalidate your existing setup
Leave the QR code PNG anywhere accessible	Delete it immediately after enrollment

Troubleshooting

Optional: Browser-Based MFA Setup (Requires ACL Change)

If you prefer the browser method from a LAN machine (http://<reactor_host>:8111/api/v1/mfa.add/<user>?askauth=1), you need to add an ACL rule in config/users.yaml:

api_acls:
  - url: "/api/v1/mfa.add"
    group: admin
    allow: true
  - url: "/api/v1/mfa.clear"
    group: admin
    allow: true

Place these at the top level of the file (same indent as users: and groups:). Then restart:

docker restart <container_name>

Validate the YAML before applying:

python3 -c "import yaml; yaml.safe_load(open('/var/reactor/config/users.yaml')); print('Valid')"

Note: This is optional. The docker exec method works on stock defaults and requires no configuration changes.

Documented based on real-world testing with Reactor in Docker, October 2026.

@tamorgen I beat it. With a lot of AI help, admittedly. But it's up and running. I'm using Portainer inside Proxmox so it had... challenges... with what IP it was "seeing".

I'll see if tomorrow I can pull together the full steps.

@tamorgen My experience is the same and I’m sure I’m missing something obvious. I’m at work and haven’t had time to dig in as yet.

@wmarcolin updated - thank you for this.

@wmarcolin this is very cool. It's picking up changes I made many many months ago that have impact on rulesets that haven't been called since those changes - so I never noticed they wouldn't have run.

Nicely done!

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

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

@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.

@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 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 TIL... thank you!

@toggledbits I just did a restart of Reactor and it's acting as expected (described by you).

In MSR's defense, I have been doing a LOT of rule optimization over the weekend. I can be quite the hack over the months and years some of these rules have been around lol

Closing this as likely a cache issue.

I have this condition:

It seems partlycloud is being picked up as valid since cloudy is one of the terms in my IN grouping.

How can I differentiate/isolate? Quotations in the IN grouping?

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.

What's the environment of your system? Docker, bare metal?

@toggledbits Damn you lol I'd just updated Brave a couple hours ago, then sat back lying in wait.

I just now went to test it and it worked normally, I was logged out with the login screen visible. I thought "huh - musta been a Brave issue, well it's fixed now" - and then I saw both this post and the version change.

Thank you, sir, as always!

@toggledbits I will the next time it times out. It's annoying but not debilitating so I deprioritized troubleshooting for other things. Dealing with a lot of work-related browser issues and this finally added to the pile