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

Noticing since 170 that the lock screen doesn't switch to the logon prompt but, rather, stays on the active UI until such time as you go to click something within it. Then it jumps to the login screen.

Brave browser
Brave 1.92.139 (Official Build) (arm64)
Chromium: 150.0.7871.114

@toggledbits I'll say it aloud: I've never noticed that button LOL

@toggledbits I checked, rechecked, RErechecked and couldn't find any issue with that YAML.

That being said, I completely removed the extra rule logging I had added and restarted. Brought down the new image and everything is fine.

So... my question NOW is: why did it run fine until this build? That logging has been there for several weeks.

@toggledbits Repulled, same thing happened: unreachable.

2026-05-31T19:33:04.533976919Z     at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
2026-05-31T19:33:04.533978974Z     at Module.require (node:internal/modules/cjs/loader:1600:12)
2026-05-31T19:33:04.533980967Z     at require (node:internal/modules/helpers:153:16)
2026-05-31T19:33:04.533983008Z 
2026-05-31T19:33:04.533984917Z Node.js v24.16.0
2026-05-31T19:33:56.035775922Z Reactor latest-26150-7b86db04 app 26150 configuration from /var/reactor/config
2026-05-31T19:33:56.053129729Z NODE_PATH /opt/reactor:/opt/reactor/node_modules
2026-05-31T19:33:56.054371749Z Failed to parse /var/reactor/config/logging.yaml YAMLException: bad indentation of a mapping entry in "/var/reactor/config/logging.yaml" (56:34)
2026-05-31T19:33:56.054391711Z 
2026-05-31T19:33:56.054396228Z  53 |     - type: file  # filename is derived from rule ID
2026-05-31T19:33:56.054399741Z  54 |       keep: 2
2026-05-31T19:33:56.054402822Z  55 |       level: 999
2026-05-31T19:33:56.054405736Z  56 |       recycle: true#      recycle: true
2026-05-31T19:33:56.054408789Z ---------------------------------------^
2026-05-31T19:33:56.054456413Z At about line 55; near
2026-05-31T19:33:56.054461049Z    >    level: 5
2026-05-31T19:33:56.054464372Z    >    streams:
2026-05-31T19:33:56.054509289Z    >    - type: file  # filename is derived from rule ID
2026-05-31T19:33:56.054513314Z    >      keep: 2
2026-05-31T19:33:56.054515586Z    >      level: 999
2026-05-31T19:33:56.054517599Z    >      recycle: true#      recycle: true
2026-05-31T19:33:56.054478049Z Use https://yamlvalidator.com/ and correct all indicated errors.
2026-05-31T19:33:56.054522741Z failed to read configuration file /var/reactor/config/logging.yaml; attemping last-known-good
2026-05-31T19:33:56.054619109Z unable to load configuration data for logging
2026-05-31T19:33:56.056778406Z /opt/reactor/server/lib/Logger.js:429
2026-05-31T19:33:56.056793267Z         const _0x98a8e2 = a22_0xf250f4, _0x36af7e = log_config['getConfig'](_0x98a8e2(0x14d), _0x98a8e2(0xfd), {});
2026-05-31T19:33:56.056795940Z                                                               ^
2026-05-31T19:33:56.056798247Z 
2026-05-31T19:33:56.056800114Z TypeError: Cannot read properties of undefined (reading 'getConfig')
2026-05-31T19:33:56.056801991Z     at Logger.getLogger (/opt/reactor/server/lib/Logger.js:429:63)
2026-05-31T19:33:56.056803906Z     at Logger.getDefaultLogger (/opt/reactor/server/lib/Logger.js:460:40)
2026-05-31T19:33:56.056805752Z     at Object.<anonymous> (/opt/reactor/server/lib/Logger.js:761:619)
2026-05-31T19:33:56.056807789Z     at Module._compile (node:internal/modules/cjs/loader:1854:14)
2026-05-31T19:33:56.056809659Z     at Object..js (node:internal/modules/cjs/loader:1985:10)
2026-05-31T19:33:56.056811482Z     at Module.load (node:internal/modules/cjs/loader:1577:32)
2026-05-31T19:33:56.056813567Z     at Module._load (node:internal/modules/cjs/loader:1379:12)
2026-05-31T19:33:56.056815388Z     at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
2026-05-31T19:33:56.056817221Z     at Module.require (node:internal/modules/cjs/loader:1600:12)
2026-05-31T19:33:56.056819018Z     at require (node:internal/modules/helpers:153:16)
2026-05-31T19:33:56.056820871Z 
2026-05-31T19:33:56.056822616Z Node.js v24.16.0

This is what the container logs show.

@toggledbits if I have time here I'll try to pull the image again and capture logging.

Following up here, did a backup restore of my Portainer VM from 05/29 (most recent) and MSR is back on 26143.

@toggledbits I pulled the image (well, Watchtower did) and within minutes the whole system went offline.

The log looks like it ends with 26143.

[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mkahsmgf/26qq82mw-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lqyfljfi/22f8on0t-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lsb61rw8/24oenqi2-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/rule-lrh58he0:S-1c00gfib-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1c00dylr-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1nam9w5u-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miuh2qqi/22ls4lql-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1vj8sdfc-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1qanz01x-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/24lq19p6-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mk0o8iox/23oy468y-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miscg2h3/rule-miscg2h3:S-22gmbq1c-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrfjke/238p0old-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-m7ccsso5/re-m7ccsso5-1r0myjxa-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/19nl9wq2-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3xk9t-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3vv5m-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/re-ln7j2nqp-22mx9lzd-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/22mx87c8-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-licneppy/1mzwe7ht-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ml3194ih/25jqt1j4-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrg7kf/227hshak-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13ua1p95-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13uagam7-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x4cbv-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x2fyl-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-lscjrws1/238p5c22-cons
[latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lbwr0jvq/1xkczf03-cons
[latest-26143]2026-05-31T15:23:44.547Z <Structure:NOTICE> Structure Structure#1 stopped
[latest-26143]2026-05-31T15:23:44.547Z <app:NOTICE> Closing APIs...
[latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: closing...
[latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: disconnecting from "192.168.1.23#82" (1001 service closing)
[latest-26143]2026-05-31T15:23:44.548Z <httpapi:NOTICE> HTTP API closing...
[latest-26143]2026-05-31T15:23:44.549Z <wsapi:NOTICE> wsapi: server closed
[latest-26143]2026-05-31T15:23:44.549Z <httpapi:INFO> HTTP server closed.
[latest-26143]2026-05-31T15:23:44.549Z <app:NOTICE> Stopping timers...
[latest-26143]2026-05-31T15:23:44.551Z <app:null> Shutdown complete, process ID 1
[latest-26143]2026-05-31T15:23:44.551Z <app:null> Closing logs...
[latest-26143]2026-05-31T15:23:44.551Z <default:null> Closing log

I can SSH to the VM. Alas, I do not have the previous image for 26143 as I'm a little too quick sometimes on housekeeping.

@toggledbits I don't care what that @therealdb says about you I never doubted you for a second.

Got home from doggo playtime and walked thru the MBR and it didn't even dawn on me until 10' later that the lights had gone on with the OLD rule, not the workarounds.

Ran to the front door (ok, slow walked...) and opened the door and 90 seconds later the porch lights dropped back to "ambiance" level from "don't fall on your face" level.

Well done, sir! Stick the proverbial fork in this one.