I am having trouble finding the official recommended guide to update to latest version of node red. I am using Pi devices, so know that a bit of unique case. But I have seen references to node-red-upgrade command or script, my installation has no such script I can find.
I believe I can just rerun the install script pulling it via curl? But have yet to see anyone recommend that specific step in some older topics in this forum?
The official node red install on Pi page has no reference at all to upgrade of an existing installation that I found, did I miss it?
We provide a script to install Node.js, npm and Node-RED onto a Raspberry Pi. The script can also be used to upgrade an existing install when a new release is available.
Suggestion, add a section to that web page that explicitly notes how to do an upgrade. Just one line of text that is more of a footnote than not, is easy to miss. Also, recommending that flows should be backed up, and how to do that, would not hurt either.
It seems pretty clear to me, what do you find confusing?
This has not been raised before by other users...
The node-RED update script is written in such a way that user data, such as flows, are unaffected. Have you had a specific update problem that supports your recommendation to back up user flows?
Confusing, no. Just not explicit. I have written 10,000s of pages of guides, procedures, etc. And the one feed back item we got routinely, as IT engineers, also writing our own technical documentation, was add stuff to the TOC, and Index, make it easy to find by scanning the page, in other words don't bury the lead so to speak. So as example:
HOW TO INSTALL
What to do before you install!
HOW TO UPGRADE
What to do before you upgrade!
HOW TO UNINSTALL
What to do before you uninstall!
(Caps just to illustrate what catches the eye)
Whereas....
HOW TO INSTALL
-How to upgrade
The above is easy to miss. It is more than just a style thing, it was key for my world, to always have key topics as key sections, hard to miss. At 2 AM in the morning, at a remote site... you lived and died by the TOC and Index.
I knew the script did the upgrade... because this forum told me such. But had no clue how it did it, or what was at risk with said upgrade in place. Given my history and experience, I was looking for such detail.
I have learned a lot, and the forum is great, but some of the questions in the forum should be clearly noted in the documentation, IMHO. Sure, documentation takes time and matures. So call this suggestive feedback to future additions to the documentation.
I'm going to stick my big fat nose into something that's none of my business here. As a long time hardware guy my mantra was and still is "blessed are the pessimists for they shall have made backups." Whether that's every hour, every day, every week or whatever your comfort level is. If you are doing anything on a computer that is remotely of value to you and you haven't made a backup then shame on you. Some of the people on this forum answer a huge amount of questions and I frankly don't see how they can possibly have that much time in their day.
This is really a hobbyist thing (node red) and if there is a business running it all the more better but for the most part it is really up to each individual to decide how much or how little they want to learn. I personally have spent hours on the web looking up answers to different problems with the result of having learned a lot but really only a small bit of what some of these people know. Every time I come to the forum it is only after spending hours over several days and not finding an answer. And every single time someone has bailed me out. There are reams of information out there to read, so much so I am over whelmed at times.
I think it is incumbent on the users of this forum to try to fathom out the answers to their questions before coming here and at least make an attempt at an answer.
Things such as backups and upgrades seem to be all over the place and there are Pi forums that deal with backing up a Pi as well, not just for node red.
I'm not wanting to bash anyone nor discourage but for the most part the small details of backing up or upgrading or even a virgin install seem to be well documented to me even if I personally don't understand every little detail of what's happening. Not just in this forum but as mentioned in other Pi forums.
So to the handful of people who spend hours assisting others here (and you know who you are) many thanks for your efforts and keep it up.
And if there is documentation that needs to be added, anyone can feel free to jump in and write some.
I don't know about big noses, but one of the first things I did was write a script that pulls all the flows from all my devices to my shared storage. It has saved me twice now. Beyond, I also archive SD card images at key points.
And yes, I agree researching things is key, I consider it accountable and responsible on my part to do due diligence on topics. An honest effort to figure it out, find out the answers first. Before coming to the forum.
Hence why when I did not find any official guide, I asked if such exists. That simple. The nice guys in this forum answered my original question. To which there is no official guide. IMHO there should be something, even if it is just a few suggestions in bullet point form. But, and I stress, that I am sure it is also a question of time and resources as to if or when it gets done.
To that, once I feel I have enough experience with node-red, which total now is about 2 weeks, I am serious about contributing to the community, both in developing nodes, and of course enhancing documentation. Fortunately... for me... I actually like writing documentation.
I can but it is just a simple cmd file on windows 10. My shared storage is just disk space hanging off a windows 10 based usb 3 bus, to leverage a usb 3.0 disk I had handy. I use pscp to just to a simple file copy from each Pi device. The pscp executable is part of the standard putty package.
@ECHO OFF
@CLS
::
@SET _Server_=%1%
@SET _User_=pi
@SET _Install_=/home/%_User_%/.node-red
@SET _Archive_=D:\Raspberry Pi Images\Flows\%_Server_%
@SET _Password_=XXXXXXXXXX
::
@IF ."%_Server_%".==.. GOTO _Error
@IF EXIST "%_Archive_%\" RD /S "%_Archive_%\"
@IF EXIST "%_Archive_%.log" DEL "%_Archive_%.log"
::
@ECHO.
@ECHO Pull Flows From %_Server_%...
@ECHO | SET /P Bogus=
@MKDIR "%_Archive_%"
@FOR %%X IN (
flows.json
flows_cred.json
.config.json
settings.js
package.json
.sessions.json
) DO (
pscp -pw %_Password_% %_User_%@%_Server_%:%_Install_%/%%X "%_Archive_%\%%X" >> "%_Archive_%.log" 2>&1
ECHO | SET /P _Bogus_=.
)
@FOR %%X IN (
lib
nodes
) DO (
pscp -r -pw %_Password_% %_User_%@%_Server_%:%_Install_%/%%X "%_Archive_%\%%X" >> "%_Archive_%.log" 2>&1
ECHO | SET /P _Bogus_=.
)
@ECHO.
@ECHO ...Pull Flows From %_Server_% Complete.
@GOTO _Exit
::
:_Error_
@ECHO.
@ECHO No Node-Red Instance Provided?
@GOTO _Exit
::
:_Exit
@ECHO.
@ECHO | SET /P _Bogus_=Press Any Key...
@PAUSE >> NUL
@EXIT
You just run the script passing in name (FQDN) of the Pi device. My implementation of node-red is always under the pi user, always at the /home/pi/.node-red path.
I did this just to get something in place, at some point I will write something in powershell, or in python. I plan to archive the flows to my linux server in time, using cron to set up a schedule. A nice enhancement would be to setup a round-robin queue, so that you could have several days of flows captured in different sub directories.
Although we seem to be drifting off topic...
Have you considered an off-site backup routine?
This routine backs up 4 week's worth of daily backups to Dropbox - node-RED Backup Flow
Yes, I have thought of something along that idea. On my todo list. I also want to retire my CMD file for something native to node-red as well, that is next on the list. Maybe a custom node that hides the details of the archival.
I think it might be worthwhile having an Upgrading page, linked from the docs home page, even if all it does is itself link to the pi page or others as appropriate.
It could also talk about upgrading nodejs there, which is a common issue here.
As I said, we had this page before and it was full of if/but/maybes because there are so many different ways users might have installed everything to begin with. And it was a common source of confusion.
There are so many ways a user may have installed Node.js, we simply cannot enumerate all of the different ways that might be right for them to upgrade.
That is why we, if I can be so bold, approach this as best practice type of thing, not with an explicit detailed procedure.
For example:
WHAT TO DO BEFORE UPGRADE
Backup flows file to a safe location. Suggested backup is to different media than where node-red is at present, a different disk, SD card, etc. At a minimum copy the .node-red/.flows*.json.backup and flows*.json files.
Upgrade in place of node-red may or may not update npm and node.js. So if other applications or solutions on the same device/system use node.js, use the upgrade script with caution.
Document the node modules that are installed, this information may be needed in the event that the upgrade in place encounters unexpected or unforeseen issues. Refer to the command 'npm list' for additional details.
It is recommended that on initial restart of the node red after upgrade is done with the --safe option, to ensure that all flows are present as expected, and any automatic flow execution is not done by default until validated on just installed version of node red.
Note: Some environments may have unique requirements or qualifications, such as, processor architecture dependencies, specific to the existing node.js installation. For example, upgrade in place will not update node.js to ARM v7 binaries if ARM v6 binaries are already present, regardless of the processor architecture present.
Yes this is a bit generic, but it covers a lot of ground, that right now, is not covered, no? And this is just off the top of my mind, so I am sure it needs some word smith effort. As a newer node-red enthusiast, such a section or page in the official documentation would have been well received. Answered a few questions I posted to the forum as well.
On the Getting Started page there are nine ways to get started. The upgrading page might effectively be a repeat of that page saying to find the upgrade instructions there, for each of the installation methods.
I think I meant little more than a link to our existing instructions, which are on the Supported Node Versions page. I think that page does not have the best title.
It is a possible way. But it doesn't cover all the ground that needs to be covered. It assumes there is a script to run. That is only true if you installed using the script, which only applies for Pis (or ubuntu/deb based systems).
If you're running on IBM Cloud or with docker or with a local npm install or with a global npm install the upgrade path is entirely different.
Having a page around backing up flows would be a good addition. Again, it was information on the old how to upgrade page that got lost when we split it out to the individual pages for different platforms.
