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
cache=/data/.npm
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. 
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 https://registry.npmjs.org/node-red-contrib-msg-profiler failed, reason: getaddrinfo EAFNOSUPPORT registry.npmjs.org
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.
3 Likes
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.
5 Likes
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.
5 Likes
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.
3 Likes
FWIW, convenience aside, the computational expense of that extra change node is next to nothing.
2 Likes
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.
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.
3 Likes
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 
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.
https://nodered.org/docs/user-guide/editor/workspace/subflows
1 Like
