Scared of upgrading ancient Node-RED (1.1.3) to 3.x

I have a large and complicated Node-RED system that uses quite a few contrib nodes, some of which haven't received updates in a long time (camerapi, nut-ups, owfs, to name a few), and I'm worried that such a large jump forward might break some of these, or indeed much my own code. At the same time I don't want to remain stuck on 1.x forever. My system has Node.JS 12.8.3 and the Node-RED update bash script suggests going to Node-RED 2.2.2 as a "safe" option, but the --nodered-version="2.2.2" command line argument seems to be ignored by the script:

$ ./update-nodejs-and-nodered --nodered-version="2.2.2"
Node-RED v3.x no longer supports Nodejs 12 
  You can force an install of node 14, 16  or 18 by using the --node14, --node16 or --node18 parameter.
  However doing so may break some nodes that may need re-installing manually.
  Generally it is recommended to update all nodes to their latest versions before upgrading.
  If you wish to stay on nodejs 12 you can update to the latest Node-RED 1.x or 2.x version by adding
  --nodered-version="1.3.7" or --nodered-version="2.2.2" to that install command. If in doubt this is the safer option.
  Please backup your installation and flows before upgrading.
  Exiting now.

Grateful for suggestions / recommendations!

Dont be scared - just back up everything, start fresh, import your old flows & try it out.

Start with node-red v3.0.0 and nodejs v16.

If too much is broken that cannot be worked around, try again with nodejs v14 (its slightly more forgiving)

Lastly, if you must, try specifying --nodered-version="2.2.2" --node12

If you cannot get these going, you can always revert to your backup that you made at the start.


Thanks, that's reassuring! I decided on a different plan though; I saw that the Pi this is running on is a Pi2 v1.1, whereas I do have a spare Pi2 v1.2, so I'm thinking imma go for a hardware upgrade as well; the 20-30% extra performance of the A53 over the A7 will be quite useful - and it can be overclocked for moar. It's also about time I do a complete rebuild from scratch; the image I'm running is six years old, and a lot of things have changed. I just hope my build notes remain usable as a guide...

While I'm at it, I might even jump to a 64-bit distro, though I'm unsure whether that's a good idea? Everything else being equal, would Node-RED perform better or worse on a 64-bit system compared to a 32-bit one? Given the choice, what would you pick?

I suspect you would only add to your potential upgrade woes moving to 64bit

I suspect you may be right about that - but I'm in the mood for pain today, so I'm going with pre-release Devuan Daedalus 64. What could possibly go wrong!?

:popcorn: :popcorn: :popcorn:


It boots! And only uses 75 MB RAM.


1 Like



looks good

First issue encountered: when installing spi-device with npm (required by node-red-contrib-monarco-hat) I get an error from nan

npm ERR! In file included from ../../nan/nan.h:294,
npm ERR!                  from ../src/
npm ERR! ../../nan/nan_new.h: In instantiation of ‘typename Nan::imp::Factory<T>::return_t Nan::New(A0) [with T = v8::Uint32; A0 = long unsigned int; typename Nan::imp::Factory<T>::return_t = v8::Local<v8::Uint32>]’:
npm ERR! ../src/   required from here
npm ERR! ../../nan/nan_new.h:208:30: error: call of overloaded ‘New(long unsigned int&)’ is ambiguous
npm ERR!   208 |   return imp::Factory<T>::New(arg0);
npm ERR!       |          ~~~~~~~~~~~~~~~~~~~~^~~~~~
npm ERR! In file included from ../../nan/nan_new.h:189,
npm ERR!                  from ../../nan/nan.h:294,
npm ERR!                  from ../src/
npm ERR! ../../nan/nan_implementation_12_inl.h:177:1: note: candidate: ‘static Nan::imp::FactoryBase<v8::Uint32>::return_t Nan::imp::Factory<v8::Uint32>::New(int32_t)’
npm ERR!   177 | Factory<v8::Uint32>::New(int32_t value) {
npm ERR!       | ^~~~~~~~~~~~~~~~~~~
npm ERR! ../../nan/nan_implementation_12_inl.h:183:1: note: candidate: ‘static Nan::imp::FactoryBase<v8::Uint32>::return_t Nan::imp::Factory<v8::Uint32>::New(uint32_t)’
npm ERR!   183 | Factory<v8::Uint32>::New(uint32_t value) {
npm ERR!       | ^~~~~~~~~~~~~~~~~~~
npm ERR! make: *** [ Release/] Error 1

This looks like a 32/64-bit problem, but I have no idea what to do about it; searching web & git turns up nothing relevant. All other nodes I need have installed without issue, including


node-red-node-openweathermap gives deprecation warnings for request and a few others but seems to function anyway.

What happens if you install nan yourself? Same issues?

BTW, my recommendation was going to be: install a 2nd instance of nr on the latest version and slowly migrate over everything you can. Leave what you can't migrate on the old version and plan for re-writing those bits when time permits. Since you have a 2nd device, this is even easier. I think I've done that approach 3 times now.

1 Like

I don't see where in the node docs it says to install that manually.

What version of nodejs are you running?

Nono, you misunderstood me, I mean when installing node-red-contrib-monarco-hat it falls over while installing the spi-device dependency; I did not ask for it to be installed myself.

Sorry, I misunderstood.

What version of nodejs are you using (node -v)

$ node --version

Did you follow the readme...

Install prerequisites
Install required build-dependencies on your Raspbian running on Raspberry Pi:

sudo apt update
sudo apt install build-essential

Additionally, there is a similar open issue on that repo from a few months back. Maybe add your voice and details to it?

1 Like

It installs ok on 64 bit ubuntu with nodejs 16, so it is more subtle than the nodejs version.

1 Like

That's exactly what I'm doing, and precisely because I have a second device to do it on. TBH I consider this to be little more than an experiment at this point. If I can make it go; good. If not, at least maybe I've learned something new.

Is this on an Arm A53 system? The error looks to me like it has to do with 32 vs 64 bit int sizes; could it be something to do with the instruction set?

No, Intel. I was just confirming that it is not the nodejs version, which can often give errors similar to yours if the node is not compatible with later nodejs versions.

1 Like