Evaluated in isolation as a novel way to program computers, Node-RED scores high. I got up and running with my serial communication projects much more quickly than writing code in a UWP application, it was easy to plot a graph of data fed by my Mitutoyo SPC connector project. While I did have to climb the learning curve of a new way of thinking and a new set of vocabulary, but once I climbed it (pretty shallow, all things considered) I understood another huge attraction of Node-RED: the collection of community contributions.

I got a brief glimpse of this when I installed the Node-RED Dashboard extension, where I went in to the extension menus to search for Dashboard. The fact there was a search function implies a sizable number of extensions, so I made a note to check it out later. This was affirmed when I went to search for the serial port node, but again I put it off to later.

Returning to browse the “Flows” directory of Node-RED, I’m very excited by the extensive toolbox people have shared and made easily usable by others. This is a clear sign of a virtuous cycle at work: an attractive and useful tool attracts a seed group of users on its own merits. These users share their improvements, making the tool more useful and attractive to other users, and the cycle repeats until we have a big toolbox with contribution by people everywhere.

I queried for functionalities that I knew I would need for many projects on the hypothetical to-do list. Majority of queries came back with something that looked promising. After a few successful hits in a row, I was half expecting to find a Node-RED extension to control a webcam attached to a 3D printer carriage. Alas, no such extension existed to trivialize my current project. Fortunately, there’s a community contributed battery information node that could pick up where a past project left off, so I’ll try that first.

Exploring Node-RED has been a lot of fun, working with both the freedoms and limitations of a different way of programming. It was novel enough that a very important part of software development workflow didn’t occur me until I had a nontrivial program: Without source code text files, how do I handle source control? Thankfully it turns out there are still text files behind the scenes of graphical flows, and I can use them with git just like any other software development work.

There are two options: doing it automatically via integrated git client, or manually. The procedure to setup integrated git client is outline in Node-RED documentation but I’m not sure I’m ready to trust that just yet. There’s an additional twist: it requires that I have my git credentials sitting on the computer running Node-RED, which isn’t something I’m necessarily willing to do. I keep a strict watch over the small set of computers authorized with my git credentials for software work. In contrast, a computer running Node-RED is likely only running Node-RED and not used for any other development. (This is especially true when Node-RED is only running in a FreeBSD Jail on my home FreeNAS server, or a Raspberry Pi.)

As a side note, the git integration instructions did explicitly confirm something I had suspected but hadn’t found confirmation before: “Node-RED only runs one project at any time.” This makes the FreeBSD Jail approach even more interesting, because running multiple isolated Node-RED projects on a single physical machine can be done by keeping each in their own jails.

Back to source control: for the immediate future, I’ll use a manual workflow. Under Node-RED’s main menu is the “Export” option. I can click “all flows” to include every tab, click “formatted” to make it readable, and click “Download” to receive a text file (in JSON, naturally) representing my Node-RED project.

By doing this on one of my machines configured for git access, I can put this file in a git repository for commit and push operations. Regretfully, the file is not terribly readable in its native form, and the GitHub text diff mode is cluttered with a lot of noise. There are many generated id fields linking things together, and those ID tend to change from one download to the next. However, it is far better than nothing and at least all the important changes are also visible within the noisy churn.

To verify that I could restore a project, I set up Node-RED on another computer and imported the flows. All the nodes in my visible flow appear to have survived the transition, but I’ve run into some sort of problem with the configuration nodes. Serial communication nodes lost their COM port information like baud rate, timeout, and line termination. This is odd, as I could see that information in the exported JSON. Similarly, my dashboard layout has been lost in the transition. Hopefully this is only a matter of a beginner’s mistake somewhere. For now it is relatively easy to manually restore that information, but this would quickly become a big headache as a project grows in size.

[I have no idea why anyone would want it, but if someone desires my air bubble packing material squish test flow, it is publicly available on GitHub.]

In addition to JSONata, there’s another very important project that is technically not part of core Node-RED. But it is rare to see one without another, and I’m speaking of the Node-RED Dashboard add-on module.

Every single Node-RED project I’ve seen makes use of the Dashboard module to build a HTML-based user interface. Which was why when I started learning Node-RED tutorials I was confused there were no mention of how to build an user interface. It took some time before I realized the Dashboard is not considered part of the core system and had to be installed separately. Once installed, there were additional nodes representing UI and additional editor interface. (Some UI to build UI…)

Once I finally realized my misconception and corrected it, I was able to build a functional interface in less than ten minutes, an amazingly short time for getting up and running under a new user interface construction system. Basic input controls like buttons and sliders, basic output controls like gauges and charts, they all worked just by connecting nodes to feed data.

However, the layout options are fairly limited. While it is extremely easy to build something closely resembling what I had in mind, I see no way to precisely adjust layout details. The rest of Node-RED reminds me of snapping LEGO pieces together, but the Dashboard exemplified the feeling: I can quickly snap together something that resembles the shape I had in mind, but if a distance is not an even number of LEGO stud spacing, I’m flat out of luck.

But even if I don’t see options for custom layout, I found instructions for building my own display widgets. Node-RED Dashboard is built on AngularJS a.k.a. Angular 1.x. I’m not sure I want to invest the time to learn AngularJS now. I can probably pick up enough AngularJS to do a custom widget if all I want is that single widget and reuse everything else. But AngularJS is currently on long-term support status receiving only security updates. Fortunately the fact Node-RED Dashboard is an add-on means people can (and have) built their own dashboard using other UI frameworks by hooking into the same extensibility mechanisms used by Dashboard. So if I want precise control over layout or other custom mechanism, I can do that while still using Node-RED as the underlying engine. I’m impressed we have that extremely powerful option.

But those dreams of grand expansion and customization are for the future. Right now I still need to build experience working with the system, which means putting it to work on a simple test project.

Node-RED is built on sending messages from one node to the next. While there are some recommended best practices, it is really a wide-open system giving users freedom on how to structure the relationship between their nodes. As for the messages, they are JavaScript objects and there’s a convention to structuring them within a Node-RED project. While I can always fall back to writing JavaScript to work with messages, for the most part I don’t have to. Between the Cookbook and the Best Practices document, there are many methods to accomplish some commodity programming flow control tasks without dropping to a JavaScript function node.

But the built-in nodes have limited data manipulation capabilities. So I thought anything that requires actual data manipulation requires dropping to code. I was pleasantly surprised to find I was wrong: simple text changes and similar manipulation can be done without dropping to a JavaScript function node, they can be done with a JavaScript-based query and transformation language called JSONata.

JSONata appears to be an independent project not directly related to Node-RED, but it fits in very well with how Node-RED works and thus widely supported by many property fields of nodes. Any JavaScript string or data manipulation that could fit within a line or two of code can probably be expressed in JSOSNata, and thus accomplished directly in a standard Node-RED field without requiring dragging in a fully fledged JavaScript function node.

JSONata is yet another novelty in my exploration of Node-RED. I can vaguely sense this can be tremendously powerful, and I look forward to experimenting with this capability for future projects. But there’s another technically-not-core Node-RED feature that I will definitely be using, and that is the Node-RED Dashboard.

Learning a new programming language, especially one with an entirely different paradigm, is confusing enough without having to worry about best practices. But after climbing enough of the learning curve, things quickly start getting chaotic and a little structure would help. I found this to be even more true for flow-based programming in Node-RED because a growing collection of nodes and wires connecting them can quickly grow into spaghetti code in a more literal sense than what I’ve been used to. A blank and pristine Node-RED flow doesn’t stay neat and pristine for long.

Fortunately, Node-RED documentation has a section called Developing Flows to help poor lost souls like me. It collects some basic recommendations for keeping flows manageable. And just like the Cookbook, it made more sense for me to read them after getting some hands-on experience building a bird’s nest of crossed wires and scattered nodes.

I felt sheepish to learn that I can have multiple tabs in the editor workspace. I should have noticed up top with a shape surrounding the name “Flow 1” and the plus sign to its right, but I had missed it completely. Each tab is a flow and when the project is deployed, all tabs (flows) execute simultaneously in parallel in response to their respective messages. This inherent parallelism does indeed remind me of LabVIEW.

Obviously multiple tabs make it easy to have unrelated features running in parallel, but what if they need to communicate with each other? That’s where I can use the link-in and link-out nodes. The set of link-in and link-out nodes with matching names act as wires connecting those nodes together.

They can also be used to declutter wires within a single flow. They still act the same way, but when one of the nodes is clicked, a dotted line representing the wire is visible on screen to make it easy to trace flow. Once unselected, the dotted line disappears.

A set of nodes can be combined together into a single “subflow“. In addition to decluttering, a subflow also aids in code reusability because a single subflow can be used multiple times in other flows and they all execute independently.

And finally, multiple adjacent nodes within a flow can be associated together as a group. The most obvious result is visually identifying the group as related. The editor also allows moving all the nodes in the group as a single unit. Beyond that, I don’t know if there are functional effects to a group, but if so I’m sure I’ll find them soon.

As an ignorant beginner, my first thought to flow organization most closely resembled groups. Which is why I was a little surprised to read it was added only very recently in 1.1.0. But once I read through the best practices recommendation in this Developing Flows section, I learned of all the other aspects of keeping flows organized, and I can see why groups hadn’t been as critical as I originally thought.

On the other side of the coin, as I explored Node-RED I found several other software modules that are deeply ingrained in many Node-RED projects, but aren’t technically a part of Node-RED. JSONata is one of these modules.

The Node-RED User’s Guide helped me get started as a beginner on a few experimental flows of my own, slowly venturing beyond the comfort of JavaScript functions. But it was a constant process of going back and forth between my flow (which is not working) and the user’s guide to understand what I was doing wrong. I had fully expected this and, as far as beginner learning curves go, Node-RED is not bad.

On the Node-RED Documentation page, a peer of the User’s Guide is the Cookbook. I thought its subtitle “Recipes to help you get things done with Node-RED” was promising, but as a beginner I could not make use of it. It listed some common tasks and how to perform those tasks, but they were described in Node-RED terminology (‘message’ ‘flow’) which I as a beginner had yet to grasp. I couldn’t use the recipes when I didn’t even understand the description of the result.

Continuing the food preparation analogy: If I didn’t understand what “Beef Wellington” was, I wouldn’t know if I wanted to cook it, or be able to find the recipe in the book.

So to make use of the Node-RED cookbook, I had to first understand what the terms mean. Not just the formal definition, but actually seeing them in practice and trying to use them a few times on my own. After a few hours of Node-RED exploration I reached that point, and the Node-RED cookbook became a powerful resource.

I don’t know how the Node-RED Cookbook could make this any easier. It’s the kind of thing that was opaque to me as a beginner, but once I understood, everything looks easily obvious in hindsight. I stare at the cookbook descriptions now, and I don’t understand how I couldn’t comprehend the same words just a few days ago. I wish I could articulate something useful and contribute to help the next wave of beginners, because that would be amazing. But for now I can only be the beginner, consuming existing content like a Best Practices guide.

Node-RED beginners like myself are given some hand-holding through two tutorials, creatively titled Creating Your First Flow and Creating Your Second Flow. After that, we are dropped into the User’s Guide for more information. The Using Node-RED section of that page covers fundamentals to get up to speed on how to work in a Node-RED project. Within that section, the page I found most instructive and informative is Using the Function Node.

Part of this might just be familiarity. A function node is a node that encapsulates a JavaScript function for doing whatever the author can write JavaScript to do. Because I’m familiar with languages like C and Python, I’m comfortable with the mentality of writing functions in source code to do what I have in mind. So seeing the function node and all I can do within it is comforting, like seeing a familiar face in a new crowd.

And just as in real life, there will be some level of temptation to stay in the comfort zone. It is probably possible to write any Node-RED program with just three nodes: an input node, a single Function node with a lot of JavaScript code, and an output node.

But writing all my logic in a single JavaScript function node would be ignoring the power of the platform. Flows allows me to lay out my program not in terms of functions calling one another, but in terms of messages flowing from one node to the next. Each node is an encapsulated representation of a feature, and each message is a piece of information that was generated from one node to inform another node on what to do next.

This is a different mentality, and it’ll probably take a bit of practice for me to rearrange my thinking to take advantage of the power of the platform. But while that transition is taking place, I expect to get occasionally stuck. But I know I can unblock myself by resorting to little pieces of JavaScript programming inside a big data flow program, and that’s a good confidence builder for me to proceed building some hands-on experience with Node-RED. I needed that experience before I could understand additional Node-RED resources like the Cookbook.

While researching LabVIEW earlier, I came across several forum threads from people asking if there’s a cheaper alternative. I haven’t come across any answers for a direct free open source competitor, but a few people did mention that LabVIEW’s data flow style of programming had some superficial similarities to Node-RED. With the caveat they are very different software packages targeting different audiences.

Still, it sounded interesting to look into. This was reinforced when I saw Node-RED in a different context. An enthusiastic overview on Hackaday, with a focus on home automation processing data distributed via MQTT. My current project is focused on a single machine and not distributed across many network nodes, so I’m not going to worry about MQTT for the time being, but the promise of an easy way to consume, process, and visualize data is quite alluring. I’ll use my newly assembled load cell as a data source and learn how to integrate it with Node-RED.

But before that can happen, I need to install Node-RED and run through the beginner tutorials. There are many options but the easiest way for me is to install Node-RED is a community-contributed plugin for FreeNAS. This gives me an one-click procedure to install Node-RED into a FreeBSD Jail on my FreeNAS home server. And if I decide I didn’t like it, it is also a one-click cleanup.

The simplicity of setup, unfortunately, also means a lack of choice in basic configuration. For example, I have no idea how to properly secure a Node-RED instance installed in this manner.

But that’s not important right now, because the one-click plugin install has fulfilled the purpose of having Node-RED up and running for me to try beginner tutorials elaborately named “Create your first flow” and “Create your second flow“. Though partway through tutorials I got distracted by the National Weather Service web API.