Global Moderators group | Smart Home

toggledbits

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.

toggledbits

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.

toggledbits

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

toggledbits

Ha!

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

Onward!!!

toggledbits

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.

toggledbits

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

toggledbits

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:

Reboot your hub
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.

toggledbits

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.

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

toggledbits

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>

toggledbits

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]}}}

Global Moderators

Posts

Nodejs v24.17 Not Compatible

Member List