OK. First suggestion here, go to the Tools tab, and in very small print in the footer of the page area, you will see a link that says Clear Local Storage. Hit that link, answer the confirmation question, and then hard-refresh the browser.

Those errors are benign -- they just say that there's a Rule or Reaction in the Rule or Reaction history that no longer exists (or it's a sub-reaction, like a Group or Repeat/While action in a Reaction). Everything else is as expected. There are probably a dozen or so lines preceding this screen shot that could have other errors, but since it got this far, I doubt it. Confirming... this is while "Loading Reactor..." is still the only thing displayed on the screen?

Also what was the prior build of Reactor you were using? Were you far behind, or just a build or three?

Since I don't have any Apple products, I don't really support Safari. That's stated in the docs. I'm happy to chase this a bit to see if we can figure it out, but only to a point.

Expected and known. Will be addressed later. Constraints are updated when the rule is evaluated.

@therealdb said in Home Assistant Connect ZWA-2 & ZBT-2:

are external Zwave controllers supported via USB?

Not an expert here, since I've never really embraced my C7 as a core of my home, but based on a little digging apparently not. The predecessor SmartThings hubs did, but as of the C7, the hub lacks the drivers to support an external Z-Wave stick, only its own internal chip. I'm sure C8 is even more entrenched.

Like many of us, I have a hundred+ Z-Wave devices in my home. If there's an upside to a piecewise migration, it's that it isn't Vera. Pairing was always a slow, anxiety-inducing activity on Vera... one device... maybe pairs... Luup restart (90 seconds or more before system is stable enough to proceed)... maybe bricks the Vera... if not, two identical devices end up with different configuration/capability... horrible. When I moved one level of my house to a USB stick last year, I could almost pair devices as quickly as I could walk up to them. You can tell me if the ZWA-2 experience is similar (can you walk it around self-powered or with a USB battery pack and pair devices?). It's not as easy as a migration, but there's always something to be said for starting with a clean slate, and as long as the process is smooth and I get to keep my hair and sanity by the end of it, I'll put up with the time it takes to get there.

Going forward, thinking to what may follow, I assume that you can back up the NVM on the ZWA-2?

Just on a lark, I took a little distraction trip on the Elevation downloadable (local/manual) backup files. It turns out, the backup files are compressed and encrypted, and I found all the resources for undoing all of that, but it's not productive to do it because the files don't have a copy of the NVM data on them, which is a bummer. The C7 to C8 upgrade process apparently worked because it used cloud-based backup and offered additional "Migrate radio" options for Z-Wave and ZigBee, which presumably pushed the additional radio data up to the cloud specifically for that process; no local option. So no win to be had from the backup files, it appears.

@therealdb said in [MSR] Feature request: For Each action on arrays/groups:

There's no way to filter the group devices.

This is a comment I'm curious about, because there actually is a way to filter a group. But that may not be much help on its own without a couple of additional changes. I am working on parameters for reactions. I think that will address the need for different scripts. Delays in scripts also came to mind when I did the alarm() function, so that's a distinct possibility in the near future. I'm bookmarking this thread so that the work I'm doing on reactions trends toward making this easier. Thanks for the detail!

@therealdb said in [MSR] Feature request: For Each action on arrays/groups:

Correct me if I'm wrong, unless I create two separated groups (one with on and one with off devices), but this seems messy.

You can send power_switch.on and power_switch.off to the same group, you don't need two groups.

Help me understand the problem more fully. Let's get into detail here. How are you creating the groups now?

Now on my Christmas wish list...

OK. I DM'd you something else to try.

DynamicGroupController has the ability to enable actions on the group that pass through to the device in the group (i.e. if you have a group of dimmers, you can set them all at once by sending dimming.set to the group). Does not that fully address your need?

Ref: DynamicGroupController Group Actions

@gwp1 great news!

@therealdb are you seeing better as well?

Don't worry about the OpenWeatherMap messages, that's just the occasional query failing, and Reactor will retry the query to get what it needs.

Since it's UI side, the best thing to do is to press F12 or whatever key opens up the Developer Tools on the browser you are using. You can usually find it on the browser's menu with a little digging. From there, there is a console where there will be messages for the UI side of things, and just copy-paste that as you've done with the log entries. HTOP on the host... just for my own clarification, that to me means you are running it on the server side, and if it's the UI that's bogging down for some reason, I expect that to not tell us more. If you are on Windows, open Task Manager and look at the browser's performance stats and memory consumption. If Mac, I'm sure there's an equivalent tool.

I would also be curious to hear if the problem resolves (even just temporarily) if you do a refresh on the browser.

Please don't make any big changes (like moving off docker) — I'm almost 100% certain we will find this issue on the UI side and moving Reactor around won't matter, just make unnecessary work for you and a moving target for me. Stay with me, and we'll get to the bottom of this.

You don't need an "at" because an "after" will trigger at the set time. It also has the advantage that if the system is down when the set time arrives, it will trigger as soon as the system comes up (when used in a Rule's trigger conditions; any time until midnight), so the event is less likely missed. If you want to make sure something only happens at the set time or within a smaller error, set a between <time> and <time+minutes> (there are other clever things you can do as well, exercise for the reader).

Between 1300 and 1300 means between 1300 today and 1300 tomorrow. That won't change.

BTW, this behavior (and explanation) goes back to the Reactor plugin for Vera.

When I'm working on my laptop, this section on the right takes up about 25% of my screen width, and I never look at it or touch anything in it. Is there a way to turn it off? I've been tinkering in the settings but not finding anything effective so far.

You list Hubitat and HASS as hubs, and the default logging for both of these hubs should tell you what you need to know. I've tried to keep these messages fairly consistent across the controllers, generally in this form:

[...]2025-11-25T12:45:08.121Z <xxx:INFO> xxx#house perform power_switch.set on Switch#house>device_396 with { "state": false }

Search using the canonical entity ID. There are several capabilities that can turn a light on, so searching by capability is harder. The idea is to find a perform ??? on ??? with ??? at the right time with the right entity ID.

From there, start looking backwards for a message like either one of these:

[...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)

    or 

[...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3

If this line is within just a couple of lines, maybe even directly before, the perform log entry you found above, then that's the name of the Reaction that manipulated the device. If that has :S or :R at the end of its ID and the tag <SET> or <RESET> appended to the Reaction name, the Reaction is part of a Rule with that ID and name, and that is the rule that is manipulating the entity — you're done!

If the Reaction ID doesn't have the :S or :R suffix, then the Reaction is not rule-based (e.g. it's a global reaction), and you need to find what launched it.

If the line you've found is of the form Resuming "<reaction name>" (reaction id)" from step n, then keep looking backwards. You may find more Resuming lines for other steps of the same reaction, but your goal now is to find the line that looks like Starting "<reaction name>" (reaction id).

Once you are on the Starting "<reaction name>" (reaction id) line, you should not have to look very far to find an Enqueuing "<reaction name>" (reaction id) line.

Once you are on the Enqueueing line, you should not have to look very far to find another Resuming or Starting reaction line. This line may have the :S and :R on the reaction ID that you are looking for to indicate the rule that launched the reaction. If it doesn't, then the reaction was launched by another reaction, and you just repeat the above process looking for what started this reaction. This path will eventually lead to the responsible rule.

Live example from my host this morning. The perform action we found above is for an outdoor flood light that lights a parking pad at my house. It got turned off. By what, though? Well, we already established that is was by a reaction called Parking Area Light Off because we found a Resuming line for that reaction right before the perform line for the entity. Let's keep digging to find the responsible rule. Here's are some more relevant lines from my log:

[...]2025-11-25T12:45:00.067Z <Engine:INFO> Enqueueing "Morning Lighting Off<SET>" (rule-knjifbn1:S)
[...]2025-11-25T12:45:00.078Z <Engine:NOTICE> Starting reaction Morning Lighting Off<SET> (rule-knjifbn1:S)
[...]2025-11-25T12:45:00.078Z <Engine:INFO> Enqueueing "Outdoor All Off" (re-kl73syb6)
.
.
[...]2025-11-25T12:45:00.088Z <Engine:NOTICE> Starting reaction Outdoor All Off (re-kl73syb6)
[...]2025-11-25T12:45:00.089Z <Engine:INFO> Enqueueing "Parking Area Light Off" (re-lk5lrx5a)
.
.
[...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)
.
.
[...]2025-11-25T12:45:00.118Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 2
[...]2025-11-25T12:45:00.119Z <Engine:NOTICE> Parking Area Light Off delaying until 1764074708119<11/25/2025, 7:45:08 AM>
.
.
[...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3

Working backwards from the last line, which is the Resuming line that we found earlier (reaction step 3), we find a Resuming line for the previous step (2) of that same reaction at 12:45:00.118. Notice also that reaction had a delay at that step that was logged immediately after, which accounts for the time gap between reaction steps 2 and 3.

Keep working backwards to 12:45:00.100 and we find the Starting line for that Parking Area Light Off reaction. And continuing to look backwards for that same reaction ID, we eventually find the Enqueueing line for it (12:45:00.089). Usually these two lines are pretty close together, but it's not usual to have other things logged between.

Now just looking backward line by line (not searching for any ID here), we soon find a Starting reaction Outdoor All Off line (12:45:00.088) very close to our Enqueueing line, indicating that Outdoor All Off launched the Parking Area Light Off reaction.

Now we just repeat this process with Outdoor All Off — find it enqueued at 12:45:00.078 by Morning Light Off<SET> also at 12:45:00.078. The <SET> on the name and :S on the ID means it's a rule reaction, so Morning Light Off is the rule that triggered and started the sequence of two other reactions that eventually turned off the light.

So to recap:

1. Find the perform line (search using entity ID) that occurs at about the right time.
2. Look backwards a short distance and you will find either a Starting <reaction> or Resuming <reaction> line. If that's a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, a global reaction manipulated the entity/device, so proceed to the next step.
3. Find what launched the current reaction. Keep looking backward until you find the Enqueueing line for it. Then very shortly preceding it, you should find a Starting <reaction> or Resuming <reaction> line for a different reaction. That's what started the current reaction. If this new reaction is a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, find what launched this new (global) reaction by repeating this step.

NOTE: Almost all actions in Reactor are asynchronous, meaning the Engine launches them in a separate process and the Engine can move on to working on a different reaction if multiple are running concurrently. Some in particular can take a lot of time (like HTTP Request). Depending on how busy your system is in that moment, all of these lines can be separated by other lines for other things going on, and you have to be careful and patient sifting through them.

Tested. It's working and not. It looks like if the condition is evaluated (e.g. Reactor restart or rule edited) in the period between midnight and its end time, it's getting the wrong result (should be true but reporting false). That's a regression in 25315. I've already got a fix for that based on your DM.

What docker image are you using specifically?

You might also try 25325 now and see if it goes away (or at least becomes less frequent -- there may be more than one similar case to one fixed in that release).

Reactor build 25325

• Rules/Expressions: fix an additional evaluation case from @Crille
• UI: silence an error that could occur during restarts (the shutdown process could stimulate the Set Rules status widget to fire queries at the inoperative host that eventually time out).
• HassController: Bless HA to 2025.11.3