if anyone would like to help test the latest version of the Pi/Debian install script then I would be most grateful for some extra testing... Of course it should work fine... but the whole point is to find out where it doesn't - so make sure you don't do this on a critical system - and do have backups of your flows etc...
The main changes (so far) are - if anything less than node12 installed - it will update to node14 (by default) - if 12 or above is installed default action is to leave alone.
There are now some more command line switches - --node12 will force reinstall of node12 and likewise --node14 will force install node14. (We'll add node16 as and when)...
There is also now a --restart option to auto restart the service if the install succeeds.
To see all command line switches just add --help to the following
Bummer. Just completely rebuilt one of my Pi4B test systems yesterday... Now worries, I 'll give this a spin today on that same pi4B.... but I'm going to do the force of node14...
Just ran the script... and selected the --Node14 option. I'm glad I did, as I identified a few critical nodes that are no longer working. node-red-contrib-i2c (sorry deejay), ncd-red-mcp32008 (another i2c related node), ncd-red-comm, node-red-node-serialport. I have never had an upgrade/update of anysort ever break these nodes (well since the path issues were fixed for i2c to use the correct libraries last year).
I attempted to remove them via the palette manager, and I'm stuck on node-red-contrib-i2c (just has that animated 'busy' affect going endlessly- the hourglass of sorts) and ncd-red-comm (ditto with animated affect).
Installed on a Pi zero ok, upgraded to nodejs 14. One minor point (which may not be new, I suspect not) it seemed to take much longer than the timestamps logged in the install log indicate
Started : Sat 15 May 16:29:51 BST 2021
.
.
.
Finished : Sat 15 May 16:29:51 BST 2021
Looks like I have to figure out how to manually remove these contributed nodes so that I can try re-installing them....
Recall this particular dev machine was built from the ground up yesterday (brand new MicroSD w/ RPiOS, NodeRED and import of a basic flow... The nodes in question were installed via the Palette Manager (yesterday) and not manually. I don't imagine that you are pushing too many updates today that weren't available yesterday, no?.... They worked yesterday. So perhaps there is some issue with node14 and these pieces?
Glad I had the opportunity to test this on my test platform! Thanks for the invite to do so DCeeJay..
To remove/install from the command line go into your .node-red folder and run npm remove node-red-whatever
And install with npm install node-red-whatever
I expect the developers will want you to post the install log from running the script.
Hmm - have tried clean install at 12 with i2c node - then upgraded to 14 - seems to re-compile ok and works. (on a Pi3) - Any chance you can PM me your original package.json file from your .node-red directory (ie with all the additional nodes in).
I did this... then rebooted..
upon reload of Flow Editor... nodes were gone...
I added them again. In the case of the NCD mpc23008 node, it was necessary to restart nodeRED service again so that the Palette would reflect the dependency ncd-red-comm.
I don't think the install.log will help you now that I am using node12 again.
All of that said... I'm going to refresh yet another Pi that I use for development. This one I will install the OS, NodeRED w/ node14.. Then I will install those nodes in question to the palette.. Then I will import some flows that use them. That process I will capture the install.log...
yeah, I'll get that one.... It's very simple and does very little.... but it contains nodes that were important to me. (well the flow inself doesn't use the NCD stuff as I don't have any hardware with mcp23008 chips on this dev pi , but those nodes are still included inthe palette).
It does contain i2c code for reading from the Atlas-Sci HUM sensor... using all of the defaults... and will be a good test for the contrib-i2c nodes under node14 (hook it up and go)...
I seem to remember that a little time ago there was a discussion about what the script should do in the event of upgrading nodejs. There was the idea that it should check for any outdated nodes and warning the user that there might therefore be build problems, and maybe giving him the option of automatically updating them all. I deduce from the fact that the system I did has some outdated nodes and I did not get the warning that this has not made it into the script.
Does that mean, then, that the build problems seen by @SonoraTechnical could be because the nodes installed are at earlier versions that are not compatible with nodejs 14?
I don't think it quite says that. If he restored the .node-red folder and ran npm install for example that would pick up the versions from package-lock.
@SonoraTechnical how did you install the nodes prior to running the script?
I think the install log gets added to each time it runs, so the log from the original run of the script should still be there in /var/log/node-red-install.log
On Friday I built the new Dev Pi (old SDMicro corrupted, so this was a new install on a 32GB samsung). I ran the normal NodeRed script... then I installed the i2c nodes from within the Palette Manager.
On Satuday, I tried the new script with the --node14 option.. and the --restart option together. that's when the i2c nodes were broken. They would not delete via pallete manager... would not remove via the command line.
Later Saturday, I re-ran the new script with the --node12 option. i2c nodes were now gone from pallete manager. So, I added them in via the pallette manager. A reboot allowed me to see the ncd-red-comm dependency in the palette manager as well.
here is the install log... I had to add a txt extension so it would upload.
Could you looked in the install log and see if you can find the build errors if they are there? The log files may have been rotated by now. Run ls -l /var/log/nodered* to find the right one to look in.
definitely most odd - as I have been installing and uninstalling various i2c nodes all morning on both node12 and 14 on Pi3 and PiZero so far without incident. @sonaratechnical maybe you can send me your package.json or package-lock.json from one of the failing devices so I can try to re-create 100%.
I think I've come to the conclusion the script should never change the version of node.js unless the user has provided the flag asking to do so.
Changing the version of node is disruptive, despite the script's best efforts. Plus, if the user has other apps using node.js, then we shouldn't be changing it unexpectedly.
When we come to 2.0, and will require at least node 12, I think the script should bail out with a suitable message saying node.js needs to be updated and they should rerun the script with the flag to do so.
That way we can direct the user to documentation about how to resolve any post node.js upgrade issues - and hopeful save some % of the questions that end up here. It also means the user is given fair warning of the potentially disruptive nature of the upgrade and the chance to seek advice before it happens.
