Upgrading to a more recent version of Node-Red would give access to new features as graphical interface but especially some nodes improvement. I think particularly to MQTT node with the dynamic subscription. With embedded MQTT broker and dynamic subscriptions we can make ND flow configurable and build start to build auto discovery flow.
Good call. I wrote a req for this. Let me see what I can do to get this done ahead of OS51.
Pete
A little update @youri.regnaud -
This is totally on the radar of the Edge team, but it’s a less trivial change than I had thought.
Point releases can generally be safely and automatically updated (1.1>1.2 can happen without risks of breaking your flows) but larger releases 1.0 to 2.0 often have fairly significant differences that we can’t just automatically apply (a 1.0 flow might not work in 2.0).
To get around this we will need to build a UI for users to be able to test their flows in 2.0, the opt-in to an NR update.
Something we are thinking about, but not something can push through as quickly as I had hoped.
Pete
This is biting me now. I just tried to update some nodes because Node Red was crashing on an Edge IO (I have to disable flows to even get the page to load).
After updating I can’t use the Modbus nodes because Node Red is too old.
[warn] [node-red-contrib-modbus] Node module cannot be loaded on this version. Requires: >=2
Hi @Richard-SNN,
Thank you for the post. We’re working on getting Node-Red v2+ on EdgeIO, but it’s not currently ready.
In the meantime, we’re talking with the maintainer of the Node-Red v1 Modbus Library to see if we can get them to publish a patch to prevents the crashes you’re experiencing.
I’ll update you here on the status of that patch. Sorry for the inconvenience this has caused. Let me know if there is anything else we can do to help in the meantime.
Adam
I strongly encourage the Tulip team to accelerate this upgrade, and to skip Node-Red version 2.0 and go directly to 3.0. 2.0 is already in maintenance mode, and there are a ton of compelling new capabilities in 3.0 that are worth the effort. Additionally, being on old versions of Node-Red limits the versions of the Node.js runtime that can be used, introducing cybersecurity risks for customers by requiring out-of-date runtimes. Lastly, the ecosystem of add-on nodes for the platform is also focusing its efforts on V3.
In summary, please focus efforts on Node-Red V3, not V2. Note that V4 will be released this summer also.
3 Likes
Thanks @RickBullotta for the post. Node-RED maintenance is on the roadmap for this year. How have you been using v3.0?
1 Like
Lots of use cases - edge connector to “odd stuff”, external integration, data transformation of course. But 1.X is ancient, and 2.X is obsolete. Any decision to go with 2.X would be a really bad one IMO. I encourage you to speak with the Node-Red team directly (Nick O’Leary) for roadmap and to understand why you should focus on 3.X.
FYI, I’m on the advisory board at Tulip (and an investor), not an end user.
And please feel free to reach out with any questions!
To also answer the question…
I use Node Red 3.0.2 on a RHEL 8.6 server to manage data in Tulip which I can’t do currently (at least not until Automations makes it into an LTS release).
Example 2 (as I posted example 1 earlier in this thread) :
We have a interval column in an order aging table. Every hour I pull all open orders (no disposition date) and calculate the interval in seconds from Date.now() and update each record.
Example 3:
The 1Hz poll rate limitation in getting data into Tulip from Kepserver is not fast enough for some of our continuous production machines. We use Node Red to calculate the correct delta of parts produced and push it back to MQTT and then pull in to Kepserver.
Example 4:
Tulip still does not have a proper way of handling reporting of analytics by shift. Especially in our case where we have a mix of 4 rotating 12 hour shifts (A/B/C/D) and 3-8 hour shifts (1/2/3). Ironically I created a table of the shifts in Tulip because I don’t have access to a general purpose database, I then poll it using the Tulip nodes, and when it changes, push it to Kepserver.
This allows me to record the shift on machine state changes which permits proper reporting that management wants to see.
Later, when table aggregations were implemented, we also started pulling the current shift into Apps.
I could probably come up with a few more but I think this is enough 
Node-RED 3.0 was released in July 2022. This release is widely used in the Node-RED community.
2 Likes
@Richard-SNN these are great examples. We use 3/ a lot with the higher sampling rates for Edge IO and general ETL prior to Tulip.
Hey @IanSkerrett thanks for joining and your post.
Edit: Also sent you a direct message to talk more about FlowForge and roadmapping.
1 Like
Hi @Richard-SNN,
Thanks for pointing this out. If you don’t mind me asking
- What version of
node-red-contrib-modbuswere you previously running? - What caused the crashes?
We are aware of some issues for <= v5.21.2 (the version that runs on Node-RED v1) that were fixed in >= v5.22.0 (only runs on Node-RED v2+), specifically uncaught errors on server misconfiguration. We don’t have an official solution until we upgrade Node-RED on the devices, so I won’t guarantee that this will work, but something that has worked for me so far is:
- Download the latest version of the node via an exec node:
cd /data/node-red && npm install node-red-contrib-modbus@5.25.0 - Use another exec node to overwrite the
package.jsonto allow Node-RED v1:sed -i 's/"version": ">=2"/"version": ">=1"/g' /data/node-red/node_modules/node-red-contrib-modbus/package.json - The module should now load. I haven’t run into any issues with it running on Node-RED v1 (I am guessing that the dropped support is based on Node version, and we’re on v16), but if you do try this, it would be great to hear if you do run into any actual incompatibilities.
I’ve attached a flow that can be imported to do the above:
node-red-contrib-modbus-install.json (6.7 KB)
I’ll give it a try when I’m back in the office next week.
On a side note, I’ve been thinking about the upgrade path for Node Red. I understand it’s difficult because you don’t want to break existing flows in production, but that has resulted in shipping new hardware with ancient Node Red.
I’m not sure if the Pi Zero in the EdgeIO can handle it, but maybe the easiest (but still not easy) solution would be to run Node Red as a docker container so that it could be independently updated from the base firmware.