Would you use Node-RED in a production environment for IoT industry applications?

Been using it for over 3+ years for integration and automation.
Also have many clients using the MultiTech AEP LoRaWAN Gateway with Node-RED.
These have been globally deployed at scale.

With v1 you have a production grade solution.
I've ported industrial HMIs to dashboard.

... because they think they can write more efficient code that uses much less of the cpu
I've not met a developer who thinks they can do better than what someone else has done!!
If your company has money then throw resource at it.
But I would bet they won't get anywhere near the maturity of 4 yrs hard work by the NR team & community contributors.

5 Likes

I've not had any of those on either of my 2 "live" Pi's (a 2 and a 3) in over 3 years now even with occasional power failures. Since I moved to Samsung EVO 32GB cards. Not only are the cards very reliable, being 32GB gives lots of room for wear levelling. Both Pi's run continuously.

Yes, the I/O speed of all but the Pi4 is quite limited.

1 Like

Ok, let me tell you our experience.
First of all: I recommend using Node-RED for industrial applications, what I do not recommend is to use a domestic PC Desktop for industrial applications.
To make it industrial you need hardware and software that are both prepared for the "amenities" of a production line.

When we started the development of ST-One we spend several months preparing the OS to make it reliable. Things like whatchdogs, configuration interfaces and most important, security layers, are what makes it Industrial.
For example: on ST-One you can only access Node-RED through HTTPS, the user and password is unique per device, the OS is in a ReadOnly partition (which brings reliability to the SD card), and many many other things that we customized/created to be robust.

Today we have more than 100 ST-One running Node-RED in important customers like Volkswagen, Audi, Bosch, Schott, Mercedes, Dürr, Ambev, Renault and many other. Most of them are running 24/7 in critical applications where if Node-RED stops, the complete line stops.

9 Likes

Hi,
i defenitely forget Raspberrypi for any industrial project. I keep it only for domestic project.
Of course it' s better to use industrial pc and industrial components. We need to give a try with NR. I need to see real project examples.
Do not go with Rpi, keep it for garage project or anything else....

1 Like

Hi,

We use Node-RED in a 'production' environment. There are 7 people on my team using NR all day to automate the testing of APIs and web applications (GUI testing). It replaced some VERY expensive test automation tools and allows us to iterate faster and connect to many different data sources. We find NR very stable and reliable. Hosting it on Windows 10 VMs and are moving to AWS / Docker instances over the next few months.

I've been very impressed with how few issues emerge. Upgrades don't break existing functionality.

Cheers,
Paul

6 Likes

We utilize NR in production with 1000s of remote nodes. In order to manage this complexity we built a system that we call Nebula. With Nebula we solved many of the major concerns with production deployment. Security, OTA upgrades, SD card degradation, run-time monitoring, etc. all utilizing a dashboard to manage the deployments.

You can take a look at Nebula here www.iotobox.com

We are looking for people who want to beta test Nebula for us.

For clarity, I am the founder of iotobox.

Joe

4 Likes

Ah, now that would be a very interesting post - about your workflow and how you go about things.

Yes, that's always been pretty amazing.

All, I am very impressed by the amount of feedback we got already, that was quite fast and super informative! Thanks all and thanks to this amazing Node-RED community!!

@PaulKeates1 +1 for the suggestion above from @TotallyInformation! You used Node-RED for testing automation?!! Use Node-RED for Development/Prototyping >> Testing Automation >> Production
Isn't that a utopia right there? :smiley:

1 Like

Hi,

We actually use it for MORE than I stated earlier - we also have RPA (Robotic Process Automation) workloads that run to support business groups. Over the last day I automatically extracted 1,300 image files from a very ugly / proprietary loan management system and store the results in PDF files. I have some RPA tasks that run 50,000 iterations over a period of days...

I consider NR to be 'IT glue' in that it joins systems together that never could 'speak to each other' previously.

We've given back to the NR community - we wrote the 'WDIO' nodes which completely replace native Selenium for GUI automation (webDriver.IO). They are stable and run 20X faster than Selenium.

We have extended NR in other areas internally as well - can access Snowflake DB directly from NR nodes as well as extended MySQL nodes to externalize credentials etc.

We do things like allow user to drag / drop upload an Excel file into a MySQL DB, map the columns in a GUI, then process that DB record set as a RPA workload.

The Dashboard nodes allow us to write control panels etc. to do things in our automation environments. Charts, or configuring the number of execution engines to process tasks etc.

I'd say we're pretty far along the development curve compared to most - especially as NR is being used heavily in a corporation rather than as a hobby / side project.

Yes, we use GitHub for our repos and even write (sometimes!) unit tests in NR to test NR flows at deploy time... with integration points to all toolsets including Slack chat. We've pretty much solved the 'CI' part of CI / CD and will solve CD in the coming year.

Agree with the sentiment of 'nirvana' - we've been thrilled with NR and I actually think it is a mistake to consider NR for 'IOT'. This is a better tool that any of the RPA tools and could have crushed a 10 billion market in the RPA space - go study that area for what is being invested in companies like BluePrism / Pega / Automation Anywhere / UIPath etc. I estimate 2 billion spent last year.

I'm off for 2 weeks but will think deeply about this request and respond.

Cheers,

Paul

11 Likes

We use a mix of plane old PI's and one based on the compute module.
We use plane old PI's when RTC and industrial grade isolation isn't an issue.
That's mainly in building automation & monitoring.

For industrial/RTC needs we use https://revolution.kunbus.de/shop/en/revpi-connect
So have to say our experience is use a PI we've been doing so for years

3 Likes

That looks really interesting! I looked because I thought they would have a multi pi compute module version, which would be interesting for industrial applications,

I'd be interested in testing it on a few of our devices, drop me a PM if you're still looking and I'll get back to you when I'm off my holiday.

Always late to the party, I was going to note that I know of NR being used in a factory environment in by Siemens in Germany -- because I work for Siemens and eagerly follow those guys hoping to be able to do the same here in one of our factories here in TX/US. But you have already pointed to our big cloud/IoT solution of which NR is a big part ("MindSphere").

4 Likes

I'm also (very much) late to the party on this, but I work in manufacturing and use AB, siemens, codesys, etc. I also use node-red for scada and database bridging. Our site has well pumps in remote areas where data and commands are being sent over 900mhz ethernet radios and node-red handles the MQTT <> modbusRTU processing. Node-red has been as stable and quick if not quicker than any siemens or AB install with comparable network functionality. In fact, I struggled to get my S7-1200 to properly communicate with modbusRTU devices at all. I was completely baffled by their lack of documentation on getting it to work. Their answer? "Use profibus/profinet". So, I myself prefer node-red for anything to do with serial or network communications. Now, if I need high speed I/O sampling, I'll use a real PLC.

7 Likes

We have implemented NR solutions in production at various customers. We are connecting machine controls via OPC-UA, OPC-DA (840D advanced), S7 protocol, Heidenhains, MTConnect (FANUC). We have also done various tests with Beckhoff (TwinCAT C++ API via socket to NR tcp-in – not in production so far).

It really runs robust and reliable. We do not have high data volumes. A typical NR instance connects to an average of 15 controls, using the protocols mentioned before. Each control performs a data read access approx. every 500 milli secs, reading about 20 data items per read. We then do some computations on each message (via function node) and finally store the results in a mongo db. In addition, such data is the source for dashboards.

8 Likes

My 50 cents here.
When you deploying something in production, be sure you will need to support it. And it‘s not about efficiency or speed of deployment - these things are nothing, when after one year your project suddently stops working, loosing real money and you need to fix it as fast as possible. Or becomes obsolete, which is basically the same. This is real pain of using open-source.

So how about commercial support on Node-red? Is it available?

Let me refer you back to my original post 4 in this thread.

2 Likes

Sorry to be late to this party (just signed up today after taking a break from my first month (or so) on Node-RED).

Here are my thoughts on Node-RED and production after some extensive testing with ESP devices (ESP32, ESP8266, WIMOS D1 (ESP8266) on WIFI and along with an Arduino UNO on serial with macOS in a variety of MQTT tests.

The only problem I have seen so far which would be problematic in a critical production application is the fact that I have seen Node-RED freeze during a Javascript exception. This happened to me just this week when, for some reason, the serial port mangles (I assume it was mangled by the serial driver) a JSON string and when Node-RED did not like that JSON string, it froze and needed to be restarted at least two times. The error was in the log file since I was running NR "nohup node-red &" on Ubuntu in this instance, and have all the logging in nohup.out.

In production, I would expect Node-RED to trap this "NR does not like the JSON" error, log it, and move on, but NR freezes. The poorly designed serial driver for the macOS (a macOS issue, not NR) was more-than-likely the cause, but seems to me, as a NR rookie, what NR should have trapped it, logged, it, and continued down it's merry processing path, versus locking up.

Please do not take this comment as negative; as I am a huge Node-RED fan... YUUUGG FAN :wink: and this issue did not dampen my passion for NR in the least. In fact, I just stopped testing on the USB serial interface, as it was just a test (and most of us macOS Arduino users know how unreliable the serial drivers can be....) . I was testing three ESP devices on WIFI and one Arduino UNO on macOS serial at the same time for about a week, stress testing over MQTT.

Should I report this error in a bug report?

I don't believe I have deleted the log file so that exception which caused NR to freeze a few times should still be in the logs, if needed by the NR team. Otherwise, I don't want to trouble anyone with the "untrapped" exception.

Node-RED is really great. In fact, it is one of the most interesting application development frameworks I have come across in years. I'm "in love".....

Considering I have only seen the one issue after building and testing myriad Node-RED flows, I can only say "WOW, great job NR Team". This is especially true for a V1.x version!!

CONGRATS!

1 Like

What did you see in the log when it appeared to freeze? I have never seen node-red freeze in situations like this, but serial ports drivers do seem have a habit of freezing up which might make it look as if node-red had stuck.

No, I know the difference. LOL

The Node-RED instance that froze (at least twice) was on the other side of the planet (Ubuntu server) than the serial port on macOS at my desk.

The log message for NR was clear on a remote Ubuntu instance that it took exception to a mangled JSON string it received via MQTT.