🎉 Node-RED 3.1.0-beta.3 released

:tada: It has been a couple moments, but we have now published the final (:crossed_fingers:) beta release of Node-RED 3.1.

Node-RED 3.x requires at least Node 14.x, but that has already reached its end-of-life. These days you should really be using Node 16 at least or even 18.

This is mostly a bug-fix beta with a couple small new things included. I hoping this gets us back on track to get 3.1.0 finally released.

The Change Log has the full list of changes.

If you haven't tried the previous beta releases, please check their release posts for details on what's included:

Note: if any issues are reported against the beta, we'll update this post to list them here. If you hit a problem, please do check back here before adding a comment.

Known Issues

  • JSONata value in Global Env Variables causes 2 warnings in debug sidebar (#4196)
  • catch and status nodes title not correct when set for Group Scope (#4197)

Group-level scope for the Catch/Status

The Catch/Status nodes could already be configured to handle specific nodes within a flow. They can now also be configured to handle just the nodes in the same group as them (or any nest groups).

This gives you more options for organising your flows and their error handling.

Lots of minor enhancements

Based on community feedback, we've made quite a few minor enhancements:

  • When merging groups, the style of the first selected group is the one that is used (previously it would use the 'earliest' group). It will also now merge any env-vars defined on the groups, rather than discard them.
  • When adding subflow ports, their nodes are added relative to where you have scrolled to in the workspace, rather than always in the top left corner

Dependency updates

We've updated lots of our core dependencies including the latest available Monaco editor.

The module underneath the HTTP Request node has been updated to a new major version; this picks up some useful security fixes.

Be sure to read through the Change Log to see what else is in there.

Installing the beta

If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 3.0.x

So on a Pi you'd do:

sudo npm install -g --unsafe-perm node-red@next

Reporting problems

If you hit any problems, please report them either as a reply on this topic, or in the #core-dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.

Outstanding work

There are couple small PRs making their way through the system that will hopefully land in the next week. But they shouldn't warrant a new beta. So I'm hopefully we can finally get 3.1.0 released to the wider world in the next month.

We'll then be turning our focus on Node-RED 4.0, with the EOL of Node 14 having already happened.


Something peculiar about the group scoped catch and status nodes. Always shows :5 in the title. Bug :thinking: ?


Yes - please raise an issue. The label property hasn't been updated to account for this new property

Anyone else see this?
Cannot name a group which contains a group.

Create a group or two, name them.
Make a new group enclosing them.
Attempt to name it - the Done button does not work.

Can you check the browser console please? May be the same issue I've seen: Max call stack exception editing group node (3.1.0-beta.3) · Issue #4198 · node-red/node-red · GitHub

Uncaught InternalError: too much recursion
and so ad infinitum

Ah. But I did install beta3. Let's just reboot everything ...

Problem persists, error message different

Uncaught InternalError: too much recursion

Presumably it is the same problem @Steve-Mcl , messages different from yours due to different browser? (FF113)

Yeah, call stack exhaustion can/is caused by recursion so I agree. Thanks for confirming.

This problem with delay node I reported in beta 2 still seems not to be working correctly. 🎉 Node-RED 3.1.0-beta.2 released - #45 by Colin

With this flow click the timestamp inject a few times to put some messages in the queue, then click flush to release them one at a time, which does work. However the number in the queue does not go down and after all of them have been released it then proceeds to release empty messages by itself each time the delay runs down.

[{"id":"b219a79eb50cc3ef","type":"delay","z":"43c7680367acf21b","name":"Queue","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"10","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":310,"y":940,"wires":[["c9e8b552e8c90995"]]},{"id":"c9e8b552e8c90995","type":"debug","z":"43c7680367acf21b","name":"debug 96","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":480,"y":940,"wires":[]},{"id":"7a0a1660829ec91f","type":"inject","z":"43c7680367acf21b","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":140,"y":900,"wires":[["b219a79eb50cc3ef"]]},{"id":"d10c601ae39443d3","type":"inject","z":"43c7680367acf21b","name":"Flush","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":110,"y":1020,"wires":[["66b752c1530c4806"]]},{"id":"66b752c1530c4806","type":"function","z":"43c7680367acf21b","name":"Flush","func":"return {flush: 1}","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":250,"y":1020,"wires":[["b219a79eb50cc3ef"]]}]

@Colin can you raise an issue with details so it doesn't get missed?

Done Delay node Flush when in rate limit mode leaving empty messages in the queue (3.1.0-beta.3 and 2) · Issue #4202 · node-red/node-red · GitHub

Thank you for all your work, node-red 2.2.2 allowed us to install data monitoring systems in power plants, wastewater treatment plants, and desalinization plants both in Brazil and the USA.

Our concern is that if we upgrade node.js 14.17.4 to version 16.x and node-red from 2.2.2 to version 3.x will it break our existing code? These systems are live and are running and they are providing compliance to our customers both in North and South America.

Asking this question in another way - is version 16.x and 3.x reverse compatible to version 14.17.4 and version 2.2.2?

Thank you @knolleary or anyone else for any information you can provide,

Kind regards,

Not sure that any issues were reported in the forum for people moving Node-RED from v2 to v3? I don't remember any.

Moving from node.js v14 to v16 is seamless though you would probably be better off going to v18 which is now also an LTS version. That would let you put off a further node.js upgrade for longer.

One wrinkle however is that, when using node.js, some compiled libraries used in various modules should be recompiled when moving between major versions. Several Node-RED dependencies such as the serial node generally require this. Thankfully it is easy to do though it can be a bit slow on some single-board computers. To do this, all you need is something like this:

cd ~/.node-red
npm rebuild

Of course, doing major version upgrades for any production service, it is always recommended to have test system(s) to do a trial upgrade on before upgrading live.

1 Like

Obviously you must try it in a non-production system first. But presumably you have staging systems set up to do that anyway, for any system or flow updates.

Also I presume you have backups so you can quickly restore a system to a working state if it fails for any reason.

1 Like

While it should work, there are never any guarantees. You really have to test your specific configuration offline if you want any real assurances.

Never assume it's going to work. Always test offline first.

Hi all,

I'm seeing a difference between 3.1-beta3 and 3.0.2 with the write file node when using a JSONata expression for setting the filename.

EDIT: I now see that the newline is a red herring, the JSONata for filename isn't evaluated anyway. With the newline present I get an error because Windows doesn't allow file names with newlines in it. The flow shown below still shows the problem I have.

  • in 3.0.2 a trailing newline in the expression would be ignored
  • in 3.1-beta3 a trailing newline in the expression causes the expression to not get evaluated - and this leads to a non-working filename
  • when using a JSONata expression with a trailing newline in for example the change node, the newline will still get ignored in 3.1-beta3

I'm running Node-RED on Windows 11, Node.js 18.16.0.

Here's a screenshot:

And here's a test flow:
flows-jsonata-test.json (3.3 KB)

[{"id":"ab3c7ced726901fd","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"22ccdcc7.90b7a4","type":"inject","z":"ab3c7ced726901fd","name":"write payload to test.txt","props":[{"p":"topic","vt":"str"},{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"write payload to test.txt","payload":"this is a test","payloadType":"str","x":160,"y":120,"wires":[["c5d75c36b6f6846c"]]},{"id":"c5d75c36b6f6846c","type":"file","z":"ab3c7ced726901fd","name":"write file to expression-defined location","filename":"$globalContext('sublocation') & '\\\\test.txt'\t","filenameType":"jsonata","appendNewline":false,"createDir":true,"overwriteFile":"true","encoding":"none","x":450,"y":120,"wires":[["48292418.2b6f34"]]},{"id":"48292418.2b6f34","type":"debug","z":"ab3c7ced726901fd","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":690,"y":120,"wires":[]},{"id":"bfb28ba748648136","type":"inject","z":"ab3c7ced726901fd","name":"","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":110,"y":60,"wires":[["988282fe56b7a9f0"]]},{"id":"988282fe56b7a9f0","type":"change","z":"ab3c7ced726901fd","name":"set global location variables","rules":[{"t":"set","p":"location","pt":"global","to":"C:\\nr","tot":"str"},{"t":"set","p":"sublocation","pt":"global","to":"$globalContext('location') & '\\\\sub'\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":420,"y":60,"wires":[["27dbd560986f35f2"]]},{"id":"27dbd560986f35f2","type":"debug","z":"ab3c7ced726901fd","name":"debug global variables","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"'global.sublocation = ' & $globalContext('sublocation')","targetType":"jsonata","statusVal":"","statusType":"auto","x":740,"y":60,"wires":[]}]

Another issue?

When I reload the Editor, the right-hand panel always goes back to the Information tab rather than the first tab in the tab list. This is different to the previous release where the first tab is the default.

This is super annoying because I always make the debug tab the first one so that it always opens first on loading the Editor.

Hi @TotallyInformation - I don't see that locally; it is restoring the last used tab as per previous releases.

Any relevant errors in the browser console?

Only the usual warnings:

It doesn't do this if:

  1. You haven't changed the order of the tabs
  2. You don't do a complete reload - e.g. pressing F5 on its own doesn't always do it. But ctrl-F5 does (forces the local cache to be ignored).

I haven't figured out why this happens but it has happened more than once. I'll start up node-red and it starts up using a default flow file. But if I shut NR down and start again, it starts up using the project I last used. Yesterday morning I closed down NR and everything else only Mac since I had to take a looong ride (another story) and when I started up today here is what I see:

Last login: Mon Jul 10 05:33:48 on ttys000
paul@PaulsM1 ~ % node-red
10 Jul 06:16:42 - [info] 

Welcome to Node-RED

10 Jul 06:16:42 - [info] Node-RED version: v3.1.0-beta.3
10 Jul 06:16:42 - [info] Node.js  version: v18.12.1
10 Jul 06:16:42 - [info] Darwin 22.5.0 arm64 LE
10 Jul 06:16:42 - [info] Loading palette nodes
10 Jul 06:16:44 - [info] Worldmap version 2.37.3
10 Jul 06:16:44 - [info] Dashboard version 3.4.0 started at /ui
10 Jul 06:16:44 - [info] Settings file  : /Users/paul/.node-red/settings.js
10 Jul 06:16:44 - [info] Context store  : 'default' [module=localfilesystem]
10 Jul 06:16:44 - [info] Context store  : 'memory' [module=memory]
10 Jul 06:16:44 - [info] User directory : /Users/paul/.node-red
10 Jul 06:16:44 - [info] Projects directory: 
10 Jul 06:16:44 - [warn] No active project : using default flows file
10 Jul 06:16:44 - [info] Flows file     : /Users/paul/.node-red/flows.json
10 Jul 06:16:44 - [info] Server now running at
10 Jul 06:16:44 - [warn] 

Your flow credentials file is encrypted using a system-generated key.

If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.

You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.

10 Jul 06:16:44 - [info] Starting flows
10 Jul 06:16:44 - [warn] [telegram sender:2a8cc13f57e5f3c3] config node failed to initialize.
10 Jul 06:16:44 - [error] [e-mail in:Simply GET-Mail] No e-mail userid set
10 Jul 06:16:44 - [error] [e-mail in:Simply GET-Mail] No e-mail password set
10 Jul 06:16:44 - [info] Started flows
^C10 Jul 06:17:13 - [info] Stopping flows
10 Jul 06:17:13 - [info] Stopped flows
paul@PaulsM1 ~ % node-red
10 Jul 06:17:18 - [info] 

Welcome to Node-RED

10 Jul 06:17:18 - [info] Node-RED version: v3.1.0-beta.3
10 Jul 06:17:18 - [info] Node.js  version: v18.12.1
10 Jul 06:17:18 - [info] Darwin 22.5.0 arm64 LE
10 Jul 06:17:18 - [info] Loading palette nodes
10 Jul 06:17:19 - [info] Worldmap version 2.37.3
10 Jul 06:17:19 - [info] Dashboard version 3.4.0 started at /ui
10 Jul 06:17:19 - [info] Settings file  : /Users/paul/.node-red/settings.js
10 Jul 06:17:19 - [info] Context store  : 'default' [module=localfilesystem]
10 Jul 06:17:19 - [info] Context store  : 'memory' [module=memory]
10 Jul 06:17:19 - [info] User directory : /Users/paul/.node-red
10 Jul 06:17:19 - [info] Projects directory: /Users/paul/.node-red/projects
10 Jul 06:17:19 - [info] Server now running at
10 Jul 06:17:19 - [info] Active project : 0-00-email
10 Jul 06:17:19 - [info] Flows file     : /Users/paul/.node-red/projects/0-00-email/flows.json
10 Jul 06:17:19 - [warn] Using unencrypted credentials
10 Jul 06:17:19 - [info] Starting flows
10 Jul 06:17:19 - [info] Started flows
10 Jul 06:17:20 - [info] [mqtt-broker:47ceb8725b07d445] Connected to broker: mqtt://

Device: Mac mini M1 16GB
OS: Ventura 13.4
NR: v3.1.0-beta.3
node.js: v18.12.1

[UPDATE] I shutdown NR on my Mac last night and when I started it this morning I hit the same problem. I did notice that the first time I start it up, the Projects directory line is empty"

11 Jul 05:19:17 - [info] Projects directory: 

and filled in after I quit and restart NR:

11 Jul 05:25:37 - [info] Projects directory: /Users/paul/.node-red/projects

@zenofmud That is very odd. But I'm fairly sure this isn't going to be related to the beta as I cannot think of any code path that has changed in this area.