Node-RED nodes for hubitat

That file does not exist.

I have rebooted the host machine and the problem remains the same.

Can you verify each of those location

None exist outside the container and only /usr/local/etc/npmrc exists inside. It contains a single line


I've been using NR almost 4 years and your nodes for the last 3. Never have I had anything close to this issue with any nodes/packages.

EDIT: I suspect a broader issue but nothing else is broken, that I know of. The only substantial change I made today to my environment (all hosts/systems) is disabling IPv6. All have been rebooted and seem to be fine. :man_shrugging:

I'm even more convinced that something more global is wrong on my end after trying "npm outdated" in a docker shell and getting this error:

39 verbose stack FetchError: request to failed, reason: getaddrinfo EAFNOSUPPORT
39 verbose stack     at ClientRequest.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/minipass-fetch/lib/index.js:130:14)
39 verbose stack     at ClientRequest.emit (node:events:527:28)
39 verbose stack     at TLSSocket.socketErrorListener (node:_http_client:454:9)
39 verbose stack     at TLSSocket.emit (node:events:539:35)
39 verbose stack     at emitErrorNT (node:internal/streams/destroy:157:8)
39 verbose stack     at emitErrorCloseNT (node:internal/streams/destroy:122:3)
39 verbose stack     at processTicksAndRejections (node:internal/process/task_queues:83:21)

I apologize for involving everyone here.

Just to close the loop on this, re-enabling IPv6 in the kernel fixed the issue. Of course I'll take this up on the NR site but every outbound connection from Node-RED was failing with the EAFNOSUPPORT error with IPv6 disabled. Only within NR though. I could issue the same commands from the command line and there was no problem.


Since this is a very active thread for a long time already and it is well appreciated and viewed, i added it to the “wiki” list I created as a starting point for the community. Hope you are ok with that @fblackburn.

Suggestions, links, contributions etc are welcome.


Any C-8 beta testers migrated their Node-RED setup? Anything to watch out for?

My Node-Red flows have been working without change - had to reauthorize the MakerAPI interface.


Wow, this is such an eye-opener to me! Thank you!
I wrestled with RM way too long, and not being able to make simple changes without a lot of head scratching is awesome.

Note-to-self: goodbye RM!

1 Like

Hi @fblackburn, first of all thanks for developing and sharing this amazing extension!

Would it be possible to add expressions to the Arguments field of the Command node?
Something like {{msg.payload.value}}.

I can add a Change node and set the msg.arguments there, but I'd rather have less nodes and use the original message.

Currently I find myself always having to add a Change node before a Command node.


FWIW, convenience aside, the computational expense of that extra change node is next to nothing.


It is really just for the convenience, less nodes to deal with, less maintenance, easier to copy and change flows, etc.

Nodes are the bread and butter of Node-Red. More nodes is more or less the expectation. Nodes are bite-sized steps along the way to a perfect automation.

I have a bunch of Change nodes who's only purpose is to normalize the names. The Function can certainly accept the original names but I have two Thermostat drivers and I want a common Function.

Are you sure? The Command Node doesn't require that.. but maybe it's just that I commonly use two command nodes.

Screenshot 2023-04-27 at 8.22.08 AM

I would find that convenient as well. Many of the built-in nodes support mustache referencing, so this certainly would not be unheard of.

That said, it is a nice to have not have to have for me.


Yes, some commands like on/off or open/close don't require arguments, then you don't need a Change node.
I have just started automating my apartment, and I have lots of shades. I'm using the setPosition command which requires the position argument. I'm sure there will be other flows without arguments, I just didn't get to them yet.

That is the beauty of programming, you have unlimited ways of solving things!
What I have proposed wouldn't change anything in your organization style, since it would be optional.

1 Like

I typically use a single change node to provide both a command and an argument (if needed). And then I recycle the same change node in other sequences that have a similar outcome .....

1 Like

Me too. Because I'm also paranoid and strip out any other arguments/ commands.

A few times I had daisy chaining logic and a few extra argument parameters made their way to places they shouldn't.

So now I sanitize the input before it goes into the hubitat nodes (when I have multiple commands in a chain anyway).

Same. And I have had a similar issue as well; for example, a command failing because an illegal argument from much earlier in the sequence was passed along.

For some time I was selecting devices via change nodes as well, but stopped doing that because of the high possibility of errors occurring due to sloppy sequence building.

1 Like

As a software developer, code duplication is the source of all evil in my opinion.
I'm just starting with Node-RED, so if you could provide more details on how you avoid node duplication, it would be great :slight_smile:
I have few automations and I'm already having bad feelings about the spreading duplications.

1 Like

You may want to look at subflows to see if they work for your use case.

1 Like