Node-RED 0.20.0-beta.5 released

The next, and hopefully finally, beta of 0.20.0 is now available.

For the background on why we're doing betas, please read the post for the previous betas:

The CHANGELOG has the full set of changes.


These beta introduces a number of new features to Subflows.

Subflow Status

There is a new option to add a 'status' output to a subflow. This can be used to update the Status of subflow instance nodes. With subflows currently, if any node inside the subflow emits a status event, it would pass up to the flow containing the subflow instance - but it wouldn't appear to have come from the subflow instance. Now, if this new status output is used, only messages passed to it will get passed to the parent flow and they will be properly identified as having come from the subflow. This gives a lot more control and flexibility of working with status events and subflows.

Adding a status output:

Status appears against the subflow instance node just like any other node with status


Redirecting status events from inside a subflow


Accessing parent flow context

When using context within a subflow, it is now possible to access the context of the flow the subflow instance is on. This is done by prepending the context key name with $parent.. For example, if a flow has a context value of foo, a subflow could use flow.get("$"); to access it.

Accessing parent flow context in a Change node

Subflow Instance properties

It is now possible to define environment variables in a subflow. These are values that any node in the subflow can then reference in the same way as they can normal environment variables:

  • by setting a node property to $(ENV_VAR_NAME)
  • by choosing the 'env' type in a typedInput
  • by using env.get('ENV_VAR_NAME') in a Function node

These properties can be set on the Subflow template, but also on individual instances of the subflow. That means you can design a subflow that can be customised on a per-instance basis. Unlike the process-wide environment variables which can only be Strings, the env vars defined on a subflow can be multiple types - string, number, boolean, JSON, Buffer or even a reference to another env-var. This last option means you can create composite env-vars made up of other env vars... and oh my just think of the possibilities.

When a flow references an environment variable, if it is not defined on the subflow (or the subflow containing the subflow, or the subflow containing that subflow... and so on), it will fallback to the process-wide environment variables. If it isn't set there either, it will return an empty string "" - not undefined.

Adding env vars to a Subflow template

Here an environment variable FOO is defined with the value "red".

Adding env vars to a Subflow instance

When editing the subflow instance, the env var table lists the env vars defined on the subflow template. In this image you can see FOO is listed. Its value can be customised for this instance - if you do customise it, a button appears to the right that lets you revert it back to the value the parent subflow defined. You can also add new env vars just for this instance - as shown above with BAR.

These new subflow features address a lot of common requests and feedback we get about them. We think this will make them a much more powerful tool within Node-RED.

Node updates

  • The Catch node has a new option to only handle node errors that have not been caught by another catch node. This means you can have catch nodes targeting specific nodes in a flow, and then one that catches everything else.
  • The HTTP Request node can optionally automatically encode msg.payload as query string parameters for a GET request. It also has a new option to url-encode cookies (if, in rare circumstances, they need encoding rather than leave as plain text)
  • The MQTT In node can now be configured to assume messages it receives are JSON and to emit the parsed object. That will save you from adding a JSON node after your MQTT In nodes if you are sure that everything you receive will be valid JSON. If the node receives something that isn't valid JSON, it'll log an error that can be handled with a Catch node.

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 0.19.5.

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 #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

The list of outstanding issues and PRs for 0.20 is very small now. The main focus is documentation around the runtime/editor split packaging.

The goal is to publish 0.20.0-final before the end of February.


Happy to report that the "Max call stack size exceeeded" reported in beta-4 is now fixed.

The other problem I had, is somewhat still present but I'm not really sure if it's a bug or not.

Basically I have a mix of node packages installed "by hand" and via palette manager, so my package.json didn't reflect the whole list of my installed nodes.
The so called bug, is that, if I try to update a package (tried with the dashboard, which was present in the package json) the palette manager wipes from the file system the nodes not listed in the package.json file.
After that of course node-red doesn't find the necessary nodes simply because they are just gone.

I think that didn't occurre with 0.19.x (sorry but I didn't try to reproduce with the old version but I will do if it's helpful)

edit: i've forgot to say that the problem is not present, if you have all your installed nodes listed in package.json

Hi @juzam

what you describe is the behaviour of npm - nothing to do with Node-RED.

Ever since npm v3 (or was it 5... I lose track), it considers your package.json as the single source of truth for what should be installed. Whenever you run npm install it ensures you have what your package.json says you should have - nothing more and nothing less.

Thanks for the heads up Nick! glad to hear it's not a bug :slight_smile:

Now I know to keep my package.json up to date.

It should not generally be an issue from here onwards as the default for npm install is --save so package.json should be kept up to date however you install. Not sure about things like npm link though.

1 Like

Maybe one day dashboard instanced groups?

Great work.

You'd have to talk to the node-red-dashboard department. This is the Node-RED department. Go up two floors and down the corridor on the right. Last door to the left. Ask for Dave.


Just waiting for the hoard of architects, designers, coders, testers and technical writers to step forward. Any day now...

In the meantime I’ll keep the sticking plasters coming


This may set off a discussion of my personality type, but here goes. I use a few contributed nodes that produce fairly long status messages, and I've never really liked the way they are displayed in the editor. The new option to hide the node label adds to my discomfort. I'm not sure what to suggest except possibly an option in the Settings menu to center status text under its node. Feel free to tell me to take a couple of days off.

[{"id":"90598bef.ba5ff8","type":"function","z":"b76138e7.d11088","name":"","func":"node.status({shape:'dot',fill:'blue',text:\"This is a long status text.\"});\nreturn msg;","outputs":1,"noerr":0,"x":470,"y":340,"wires":[[]]},{"id":"fe5e8bcf.20c76","type":"inject","z":"b76138e7.d11088","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":340,"y":340,"wires":[["90598bef.ba5ff8"]]},{"id":"39699d9b.ef465a","type":"function","z":"b76138e7.d11088","name":"","func":"node.status({text:\"This is a long status text.\"});\nreturn msg;","outputs":1,"noerr":0,"x":470,"y":400,"wires":[[]]},{"id":"73f8a513.e500d4","type":"inject","z":"b76138e7.d11088","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":340,"y":400,"wires":[["39699d9b.ef465a"]]},{"id":"c20088b6.14be08","type":"inject","z":"b76138e7.d11088","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":340,"y":460,"wires":[["8ee4fc08.0b1b18"]]},{"id":"8ee4fc08.0b1b18","type":"function","z":"b76138e7.d11088","name":"","func":"node.status({text:\"This is a long status text.\"});\nreturn msg;","outputs":1,"noerr":0,"x":435,"y":460,"wires":[[]],"l":false},{"id":"2449404e.2dd03","type":"comment","z":"b76138e7.d11088","name":"# 1","info":"","x":190,"y":340,"wires":[]},{"id":"71631ccd.e2015c","type":"comment","z":"b76138e7.d11088","name":"# 2","info":"","x":190,"y":400,"wires":[]},{"id":"16d18d17.c69f53","type":"comment","z":"b76138e7.d11088","name":"# 3","info":"","x":190,"y":460,"wires":[]}]

You can of course toggle the status display off completely, but i get your point.

Have nudged the text only status left for 0.20-next

1 Like

There is something wrong with the new "parsed json" functionality in the mqtt-in node. (20.0-beta.5)

If the incoming message is not a json string anymore and i change the setting in the node to "auto", "string" or whatever, it still tries to parse every incoming msg as json and throws the error "Failed to parse JSON string".

are you sure you deployed ? working here... - any more info you can share how to recreate ?

The problem is getting looks like the error comes from a deleted mqtt-in node. As the problem occurred i tried all kind of settings and finally deleted the node, but it still throws the error...

Also the node id is not a link and without the praefix "node: "

You can try to recreate it by feeding first this msg:

qos : 0, retain : false, cmd : publish, dup : false, topic : so/stat/spot/RESULT, messageId : , length : 35

and then this one:

qos : 0, retain : false, cmd : publish, dup : false, topic : so/stat/spot/POWER, messageId : , length : 22

Do we have anything to enable/disable tabs - info, context, debug etc or at least disable context tab in this new version.
Thank you

Hi @doccirrus

there are no plans to allow individual sidebar tabs to be disabled/hidden - that isn't something that has ever been discussed or proposed.

There is an outstanding item related to the context sidebar from your previous comments that we haven't addressed yet.

Just to clarify - you're main requirement was to not show functionGlobalContext in the context sidebar? Or was there a wider issue here?

Main concern is to be able to hide/show the "context" tab in UI.
May be some flag in settings.js should be set to be able to hide/show the tab in UI.

@doccirrus so to hide the whole tab and not just functionGlobalContext?

Hiding functionGlobalContext will also do.

@doccirrus Earlier today, I started this topic to get some more feedback on a proposal for this - Feedback wanted: Hiding functionGlobalContext from Context Sidebar - would appreciate your input.