Regarding grouping nodes by using subflows: a had found some ideas on the node-red wiki some time ago, there was this concept of inline-subflows -- I interpreted them as singleton subflows that don't clutter the palette.
All in all, some grouping mechanism like that would really increase readability of larger projects. You could lay out the general structure of your flows with a few of these inline-subflows, and then "zoom in", if you need the details.
Just some ideas, but be careful not to end up with something like LabView.
It is used in some projects by our company (mechanical and plant engineering) for measuring and process supervision. Very impressive indeed, but very complex, too.
Ah, that explains why our LabView guys are always saying "LabView for poor people" when they see me using Node-RED in our projects.
Yes, I saw it at a local engineering company here in Sheffield that make sensors for the oil industry - my son managed to bag a work experience week with them and I couldn't resist having a nose (much to his disgust ). I was surprised to see them building IoT microprocessor logic using a visual tool. Nice.
Reasonable price for its intended audience I guess - their use case needed at least the "Full" license as they were programming FPGA's.
It is a very different beast in reality and the cost indicates the investment in development and support. So if you wanted to have something similar, you would need to start investing money in the project - perhaps funding some developers
Of course, you can also contribute yourself as well by writing code or updating documentation.
Well, I think Node-RED is an impressive platform and is only getting better and better from release to release.
I have been using it for personal projects at home since v0.10 in 2015, I think.
Two years ago I introduced it at work for use in industrial projects, doing all kinds of communication with PLCs, data handling and SCADA like stuff. Productivity has improved a lot since then.
It took me some time to get over the lack of types and compile time assistance you get from typed languages.
After just a few months, I dreaded the thought of going back to explicitly declaring types up front, no being able to add properties to an object by simply .prop = value and the simplicity of serialisation in js is excellent. Don't get me wrong, it still annoys me at times but the benefits do outweigh the struggles.
You should find a gap in the contrib nodes and crack on. Perhaps an ultra flexible number convertor for bits, bytes, hex conversion, octal, etc (I've seen tonnes of how to convert 2 bytes to integer, how to set bit 3 of a WORD, how to split 16bit into two bytes etc)
I now make extensive use of ESLint and JSDoc in my JS programming as it really helps track the meaning of variables/objects which I find more important than a fixed declaration of type - though that is certainly helpful sometimes and also helped by ESLint.
Using a decent code editor like VScode with ESLint properly configured eliminates loads of silly little errors that I make because I'm not a full-time developer. JSDoc helps me keep track of what everything means.
VSCode's built-in TypeScript help for JavaScript is also generally useful - though occasionally really annoying when you can't tell it exactly how you need it to behave. Working out how to stop it giving me an error on the RED object for coding the Editor panel for a node was especially frustrating. Also the TypeScript descriptor for Node-RED is far from complete unfortunately (and I don't know enough about TypeScript to be able to offer improvements to the authors). But it is great when it works because it offers up descriptors of objects and variables integrated into your coding. Even across required external packages and libraries.
I too am a relic of those days, so please forgive the ramblings of a grumpy old man. I've never coded for a living but have always written code as part of my job. So, I could easily have some of the history and technology wrong, but it seems that each language family reflects a slightly different view of the world. In particular JS is looking out from inside a web browser, where it has very little control of its destiny. Trying to make it feel like a procedural language with synchronous function calls, subroutines, and so on (which I sorely miss) would be self-defeating.
I've used it extensively, but with an academic/institutional license so that cost was not an issue. LabView and some other flow-based programming tools like Extend (now ExtendSim) strike me as what you get when a C programmer does flows. Node-RED can't avoid having its JS foundation show through and probably shouldn't try.
). I was surprised to see them building IoT microprocessor logic using a visual tool. Nice.
