🎉 Node-RED 1.0 Released

I have a very odd situation here. I have been fiddling with this bit of a flow.
image
Ignore the Change node, it just happens to be in the screenshot. As you see there is a Join node, which produces key value pairs in msg.payload. Previously I had the debug connected directly to the Join node. I added the function node and moved the debug node to the output of the function node, which contains

// get all the properties in the payload
let max = -100
for (let property in msg.payload) {
    max = Math.max(max, Number(msg.payload[property]))
}
msg.payload = max
return msg;

In the debug pane I now see


The -100 values are correct, but there are interspersed occasional payloads that look to have come straight from the Join node.
In fact I have just added a line to the function node
msg.topic = "Set in function node"
and from the debug window I can see that the extra messages do not have that topic, which means that the messages must be coming direct from the Join node.
I have only been doing partial deploys, but have now tried a full Deploy in the full expectation the problem will disappear, but it didn't.
I have also now added a second debug and it is only showing the good messages.
I am now at a complete loss to understand what is going on. I have cleared the browser cache.

This is the flow of those nodes:

[{"id":"dbdcfa4e.84f408","type":"join","z":"526bdf59.6829a","name":"","mode":"custom","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":true,"timeout":"","count":"1","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":330.5,"y":632,"wires":[["7433395b.ae8f98"]]},{"id":"7433395b.ae8f98","type":"function","z":"526bdf59.6829a","name":"Max","func":"// get all the properties in the payload\nlet max = -100\nfor (let property in msg.payload) {\n    max = Math.max(max, Number(msg.payload[property]))\n}\nmsg.payload = max\nmsg.topic = \"Set in function node\"\nreturn msg;","outputs":1,"noerr":0,"x":479,"y":712,"wires":[["9c391fdd.68ab78","92252c5d.2cef9"]]},{"id":"9c391fdd.68ab78","type":"debug","z":"526bdf59.6829a","name":"","active":true,"tosidebar":true,"console":false,"complete":"payload","x":416,"y":823,"wires":[]},{"id":"92252c5d.2cef9","type":"debug","z":"526bdf59.6829a","name":"Second debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":705,"y":735,"wires":[]}]

[Edit]
Just tried a node-red restart and it is still doing it.

This is on a Pi running Jessie

1 Oct 12:04:13 - [info] Node.js  version: v10.16.3
1 Oct 12:04:13 - [info] Linux 4.4.21+ arm LE
1 Oct 12:04:17 - [info] Loading palette nodes
1 Oct 12:04:33 - [info] Dashboard version 2.16.3 started at /ui
1 Oct 12:04:34 - [warn] ------------------------------------------------------
1 Oct 12:04:34 - [warn] [node-red-node-pi-sense-hat/sensehat] Error: Can't find Sense HAT python libraries. Run sudo apt-get install sense-hat
1 Oct 12:04:34 - [warn] ------------------------------------------------------
1 Oct 12:04:34 - [info] Settings file  : /home/me/.node-red/settings.js
1 Oct 12:04:34 - [info] HTTP Static    : /home/me/.node-red/static
1 Oct 12:04:34 - [info] Context store  : 'default' [module=memory]
1 Oct 12:04:34 - [info] User directory : /home/me/.node-red
1 Oct 12:04:34 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
1 Oct 12:04:34 - [info] Flows file     : /home/me/.node-red/flows_pi-ade.json
1 Oct 12:04:34 - [info] Server now running at http://127.0.0.1:1880/
1 Oct 12:04:34 - [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.
---------------------------------------------------------------------
1 Oct 12:04:35 - [info] Starting flows
1 Oct 12:04:38 - [info] Started flows

Ah, further information. I added another function node and disconnected both debug nodes, so I now have the first function node connected to a second where the second is just using node.warn to display the topic and payload coming in, and can see clearly that the extra messages are coming from the first function node. It does appear that the function node is sometimes sending input messages direct to the output without operating on them.

@Colin very strange. I can't immediately reproduce that here, but I have spotted a bug in the Join node failing to clone messages properly. I can't immediately relate that bug to what you are seeing, but could you try the following steps exactly as written:

  1. delete the wire coming out of the Join node
  2. add a new debug node
  3. wire the join node to the debug node
  4. wire the join node back to the function node.

then see if you can reproduce.

For step 4 do you want me to remove the wire in step 3 or leave it connected?

You should end up with the Join node wired to both the Debug node and the Function node. But you must wire the Debug node in before the Function node.

The goal here is to force the runtime to clone the message passing from the Join node to the Function node. When it has multiple wires, it doesn't clone the first message it sends, but will clone the rest. So we want the first message to go to the Debug node (by virtue of its wire being first in the list) and the second, cloned, message to go to the Function node.

Yes, that does appear to have fixed it, and with a bit of analysis I believe I understand what is happening. Sometimes the Join node is passing on the same message (or at least a message with the same _msgid) as it did the previous time, so I imagine what is happening is that it is passing on a message, which my function node then modifies, then the Join node re-modifies that same message, filling the payload with the key/value pairs again, then my third node sees those message contents rather than the contents that the first function node set.
That is a bit serious I think as obviously it could break existing flows.

[Edit] I have worked around the problem by cloning the message at the start of my function node which helps to confirm that the problem is in the Join node.

Indeed, the fix is in git and we'll do 1.0.1 soon.

Great news on a significant milestone - many thanks Nick, Dave et al.

Interestingly I think the problem would not have shown itself (in this flow) in previous versions of node-red as the original message would have worked its way down the chain before the Join node got the chance to modify it. One could imagine cases where it would cause a problem but it would be less likely to show itself.

1 Like

Great news... and thanks for creating and maintaining such a wonderful and endlessly useful tool!

Question, does the "update-nodejs-and-nodered" script no longer create a "node-red-restart" script?

should do. (well - the online bash script should)

It did for me on a Pi, though I think it is a pity that node-red-restart does not do node-red-stop followed by node-red-start. It just restarts the service. That is a different issue though.

I let you guys work out how to create your own alias for node-red-stop && node-red-start

1 Like

I have done, but I want to call it node-red-restart.

Well done. I would have commented earlier but I'm on a boat. I look forward to the challenge of upgrading my 6 month out of date UK NR installation. A weekend job maybe. And 1.0.1 - yes I've read comments above😊

@colin I’m sure you can manage to delete the original one.

Certainly, but it would come back the next time I upgraded, and anyway I would not, as a matter of principle, override a provided script with one that does something different, that way lies confusion. It is not a big deal, I use a script with a slightly different name. It just seems odd that node-red-restart does not do the same as node-red-stop node-red-start.

Start uses - sudo systemctl start nodered
Stop uses - sudo systemctl stop nodered
Restart uses - sudo systemctl restart nodered

so it is hardly "not the same"

@dceejay @Colin lets keep this topic on topic. If you want to have a discussion about the install scripts, there was a post on that very topic earlier today.

Spent a good chunk of my afternoon using the new subflow environment variable features to slap together a watchdog template that should be no problem for even interns to use without needing to look up too much. So far I'm loving this.

4 Likes