OK. I think I found it. Patched and respun the 26193 build, so pull that again and let's see if it behaves better.

Did you check the log files? Whenever something isn't working right, that should be the first place you look.

Thanks for the inspiration!

Reactor build 26193

BARE-METAL USERS: nodejs v24.17 had a regression/injection that breaks HTTP connections, which has broad negative effect in Reactor. This version specifically is excluded from support, and users on that version are advised to upgrade to v24.18 (or higher).

BREAKING CHANGE: I'm guessing this will affect very few people, maybe none: the include_attributes selector for DynamicGroupController now requires that all listed attributes match when tested against an entity. Previously, if any listed attribute matched, the entity would be added to group eligibility. This forced users to use a filter expression if all attributes had to be matched together, which carries a greater performance impact and has other side-effects. The old behavior can be obtained by separating each attribute under its own include_attributes selector individually.

• DynamicGroupController: the include_attributes selector now requires all listed attributes to match, rather than any of the listed attributes, for the entity to be selected. See note above.
• A new lexp-cli.js utility in the tools subdirectory allows users to experiment with lexp expressions outside of Reactor. This tool doesn't have Reactor context, so functions like getEntity() and isRuleSet() are not available; nor are Reactor's global variables. It is strictly an environment to help with familiarization.
• Reaction Editor: when editing the Set or Reset reaction of a Rule, the Copy From... button will now list the contra-reaction at the top of the list, making it easier to find and copy the reaction within the current Rule.
• UI: The condition and action editors now support a right-click context menu on conditions and actions. The menu provides copy-paste of individual conditions and actions. Other menu actions are added where they make sense. Thank @therealdb for this power-user feature!
• UI: On dialogs, the Enter key will not perform any action if a modal dialog contains two or more buttons (i.e. where the meaning of Enter is ambiguous).
• nodejs version 26 is now explicitly supported, with v26.4.0 being the current version used for development (testing still occurs on v22 and v24).
• HassController: Bless HA to 2026.7.2

@Talisker said in Upgrade advice - upgrade from aarch64 to ARM64 image:

What is confusing me a little is that the exemplar docker compose .yaml 'volumes:' file structure is a bit different to my current .yaml file. Will this cause a problem?

The change in the newer file will be significant later, but no need to worry about it today. Make as few changes as possible. The only change you need to make here is from latest-aarch64 to latest-arm64.

There's information in this earlier post to help you confirm that your OS is 64-bit capable (or not). Take a look at that first. You can report here what the DEB_HOST_ARCH value is.

The issue with copy-paste is that the navigator.clipboard browser interface only works in secure context, meaning HTTPS or 127.0.0.1/localhost. I like your suggestion of using LocalStorage, and I'll look into that, but even so that's not the big challenge. For example, there isn't really a concept of "focus" on the condition/action rows. While a copy button can be added to each rather than trying to create and track focus, I have resisted adding buttons to the rows because it makes less room for useful displayed data). And how would you paste? And where, since there's no focus? The idea assumes a lot that doesn't exist here.

I have some other ideas. Sticky header has already been on my mind, so that's a likely upgrade coming. Stay tuned...

@therealdb You know you there's a button for that?

It appears that Ezlo is going to new levels of paid subscription for cloud services supporting Vera hubs. I have to congratulate them. It will soon be 8 years since Ezlo acquired Vera, and despite their purported financial and "intellectual" capital, they have to date not produced a viable full replacement for Vera. Now they are going to charge extra for services for a platform that they stopped updating years ago.

If you know anyone who hasn't yet fully moved on from Captain Ahab's White Whale Chase, please remind them that my Decouple project is still up on Github to decouple a Vera Plus/Secure/Edge from Vera/Ezlo's cloud services. Veras have been said to misbehave when they can't reach the mother ship.

I have also written my first new Vera plugin in... six years? more?... the AlertPushover project will send Vera hub alerts to Pushover, so you can still get messages generated by your Vera hub without paying for Ezlo's cloud service. It's crude but functional (i.e. better than nothing/worth every penny paid).

These two projects won't replace the functionality of their cloud service and app for those who need those things. But any that don't, this may help bridge the gap. Hopefully these stragglers who have waited so long and been disappointed so often will get the idea that it's time to move on.

@CatmanV2 A subsequent (to the prior post) respin of build 26177 fixed multiple profiles as well, so you're good either way.

That's a bug in Maker API... it's sending updates for a device that isn't enumerated for export. You can safely ignore those messages.

Nodejs v24.17 Not Compatible

Users on bare-metal installs... a security fix in nodejs v24.17 inadvertently broke a dependency of Reactor. This version of nodejs is therefore not compatible with Reactor. If you are using it, please upgrade to v24.18.

@wmarcolin I'm still looking at your Telegram issue. Now that I know nodejs v24.17 is a problem, I will post a note for it. Apparently the same change that broke v24 was also made to v22, so I'm trying to identify/confirm that version as well.

Ha!

And... it's a known regression, with a specific fix applied to v24.18, so confirms all.

Onward!!!

OK. Here it is... I switched my nodejs to the same v24.17 you are using... and my system broke! Same behavior as yours.

Upgrade your nodejs to v24.18. Whatever was broken in 17 seems to have been fixed for 18.

I'VE GOT IT!!!! Stand by... don't do anything more yet...

OK. That all looks good. I upgraded my hub to 2.5.0.159, and it works fine. I'm just not seeing any of the issues you are having here. The only things I can suggest at this point:

1. Reboot your hub
2. If that doesn't resolve it, delete your Maker API instance on the hub and create a new one; update Reactor's configuration to reflect the new app ID and access token.

If you look at the error messages being reported by HubitatController, you can see it is not able to talk to the hub. What do the startup messages for HubitatController look like? Something really does not seem right network-wise with either your host or your hub.

Let's clear a few baseline things out of the way.

1. Post the first 20 lines of Reactor startup messages.
2. Run npm ls in your Reactor directory and post the output.
3. From the Hubitat GUI, post the version number of your Hubitat firmware.
4. Post your HubitatController config

The second argument to find() is a regular expression, not just a string. Dot . is a special character in regular expressions that matches any character, so your first find() returns zero because it quickly matches the first character in the string. The comma doesn't have a special meaning in a regular expression, so it just matches as a comma.

If you want to match one of the characters like dot . that has special meaning in a regular expression, you have to escape it: find(SpeedPTY, "\\.")

Now, your approach to solving your problem can be done a little differently/better, I think. Rather than picking apart the string by looking for specific characters, try using split() to convert the comma-separated string into an array of strings. The first element of the array (at index 0) will be the true (as a string, not boolean). The second value (at index 1) will be the string 301.5. You can put that into int(), float(), floor() or round() as needed to make a number out of it, and do whatever you need to do from there.

(venv) patrick@drupal:~/Documents/lexpjs$ node cli.js
lexp CLI, library version 25308
Type CTRL-C or 'quit' to exit
lexpjs> org="true,301.5,150.49,2.09,UFINET PTY,2026-06-27T21:00:20.435581"
Result: string true,301.5,150.49,2.09,UFINET PTY,2026-06-27T21:00:20.435581
lexpjs> find(org,".")
Result: number 0
lexpjs> find(org,"\\.")
Result: number 8
lexpjs> split(org, ",")
Result: object [
  'true',
  '301.5',
  '150.49',
  '2.09',
  'UFINET PTY',
  '2026-06-27T21:00:20.435581'
]
lexpjs> split(org,",")[0]
Result: string true
lexpjs> split(org,",")[1]
Result: string 301.5
lexpjs>

Your post should ideally indicate if your runtime is bare-metal or docker, and the OS and architecture being used, because I can't keep that kind of info in memory. If you're bare-metal, make sure you've updated packages npm run deps.

Most of the errors you are showing are expression errors downstream of the HTTP request, so that's not really showing me anything useful. The last two lines are suspicious, though... NUTController isn't able to establish a connection with the NUT service, saying that the server is reachable but it refused the connection. Right after is an attempted query apparently to a Hubitat hub that fails with the connection closing before the response is complete. This looks more to me like you're having other network-related issues.

While you say you can run successful queries from the browser, if that browser isn't on the same IP address as the Reactor instance, it's not a great test of network reachability for this. What you need to do is run a curl query from the Reactor host system; if that's a docker container, you need to attach your console to the container and run curl from within the container (e.g. docker exec -it reactor /bin/sh).

I am, of course, running 26177 for my house, and use a lot of HTTP requests (e.g. most of my Blue Iris control). No issues for me. I am able to run your query URL from an HTTP Request action and get a valid response to a global variable (advanced response format shown here):

{"ok":true,"status":200,"message":"OK","data":{"latitude":9.033392,"longitude":-79.41177,"generationtime_ms":0.023484230041503906,"utc_offset_seconds":-18000,"timezone":"America/Chicago","timezone_abbreviation":"GMT-5","elevation":12,"daily_units":{"time":"iso8601","precipitation_sum":"mm"},"daily":{"time":["2026-06-22","2026-06-23","2026-06-24","2026-06-25","2026-06-26","2026-06-27"],"precipitation_sum":[16.6,6.1,2.2,4.4,8.2,0.1]}}}