Hi, newbie here.
Just started with node-red. followed the instructions and it seems pretty easy to get started. but I am confused with a few things, particularly the "flow".
in the editor, you can have multiple tabs at the top (workspace?). by default, they are named "Flow 1", "Flow 2", etc. as such, I am assuming each tab represents a flow.
then on each tab, you can have multiple independent "workflows" -- each can be started with its own input node.
when we talk about "flow", which one are we talking about? the "flow" tab, or the "workflow"s?
after deploying, i am assuming all "workflow"s on the same tab are running. how about all the tabs (Flows)? are they all running as well (including the ones not directly visible)?
thanks.
sm
There are a number if overused terms in Node-RED and one of those is flow.
For me a flow is a linked number of nodes to perform a task.
Personally I just think of the tabs as tabs as you’ve already found a tab can have more than one independent flows. I generally rename my tabs to describe what the flows on that tab are doing.
All flows on all tabs are generally “running” although some may require an input (eg pressing the inject button) for the flow to work.
... and as node.js (the application Node-RED runs on) - is single threaded... although they look like separate "flows" - they are all sharing the same cpu process so there is only one thing running at a time. And as we save them all in one single file... - the overall set of flows running is also called a flow :-).... But yes - it's an overloaded term.
thanks for the clarifications. so conceptually, all "workflows", continue with my own vocabulary, are running (many waiting for inputs - click) in a global space. no boundary exists between the "Flow 1", "Flow 2", flows. If that's the case, I guess the purpose of the "Flow" tabs are just for visual organization only. Could've stated right in the beginning of the intro.
thanks again.
sm
Not quite.
There is a boundary for variables and one for turning on/off tabs.
Variables can be "global" (available everywhere in your flows), "flow" (only available to the same tab) or "context" (only available to the same node instance).
Then, if you like, you can turn off a complete tab. Everything on that tab stops running.
1 Like
masn,
I am only a little less newb than you. Here is what I believe I have read.
- Flow -- a tab in the Node-RED user interface that contains a collection of sequences.
- Sequence -- a collection of nodes that are wired together to perform a task or process.
This distinction begins to make sense when context comes into play. working from the bottom up, msg.* attribute scope is limited to the sequence that is processing the message. flow.* attributes are limited in scope to only those sequences in the flow tab. global.* attribute scope spans all sequences in all flows.
Since joining, I have noticed that the Node-RED community uses flow and sequence interchangeably when they really are not.
Hope this helps.
ah. makes sense.
so "flow" really refers to a tab. thanks a lot for pointing this out.
I'd wish everybody sticks to this definition of "flow" (= tab). coming up with an official term for the individual 'workflow'/pipeline on a tab will help a lot for the community.
thanks to all.
sm
ps. just saw athome's message. perfect explanation. thanks.
masn,
yeah. the thing is, it is hard to keep a big community aligned on words and their meanings.
The official term you are looking for would be sequence in a flow. 
deceptively simple, eh! [The full monty would be a node of a sequence in a flow in a project. Ed.]
Happy Friday!
thanks, athome.
Well, something as complex as Node-RED tends to grow organically so it is hard to keep terminology straight even with only a few originators helping develop it (Nick, Dave and colleagues).
So the definition of "flow" has evolved I guess.
This is the glossary I work to ...
Glossary
-
Flows: The collection of node instances and wires defined by the flows file loaded by Node-RED at run time.
-
Flow: A tab in the Node-RED admin UI used to break Flows into more manageable chunks.
-
flow: A set of node instances and wires with in a Flow tab.
-
Package: An npm package used, amongst other things, to install Node-RED Nodes.
-
Node: The source definition for nodes that can be used in Node-RED Flows. Defined normally by an npm Package (though actually defined by 3 files: package.json, an html file for the admin UI and a JavaScript file for the server process).
-
Node Instance: An instance of a Node added to a flow. A Node (definition) may have many instances in Flows.
-
node(s): same as Node Instance(s).
-
wire(s): The logical connectors between nodes. Conceptually, messages "travel" between nodes. In reality, they don't, data is simply passed by reference (except for the edge cases where a message copy is forced).
-
message(s): Often referred to by the short name
msgwhich is the variable name generally used to reference the message. This is the data object used to communicate between nodes. Typically, it has the minimal definition:{{_msgid: uid, topic: undefined|string, payload: Object|Array|string|number}}but other than requiring_msgid(which is added by Node-RED), it may contain any valid, serialisable JavaScript. -
userDir: The server folder that contains the flows file,
settings.jsand other Node-RED configuration information. Typically residing at~/.node-red.
Interesting. Is that from a node-red doc page somewhere?
here is a snippet that i just found on the Node-RED Working With Sequences page. I think this is where I first encountered the Sequence term.
Understanding msg.parts
Each message in a sequence has a property called msg.parts. This is an object that contains information how the message fits in the sequence. It has the following properties:
msg.parts.id
a unique identifier for the sequence
msg.parts.index
the message's position within the sequence
msg.parts.count
if known, the total number of messages in the sequence
Note: the parts array may contain additional meta-data about the sequence. For example, the split node also attaches information that can be used by the join node to reassemble the sequence. See the split node’s documentation.
Working with sequences
There are a number of core nodes that can work across message sequences:
Nope, from an as-yet unpublished blog post. It is simply the terminology I've developed to attempt to not confuse myself too much when thinking about all things Node-RED.
Cool snaps for building a glossary.
Motion #1: change lower-case flow to sequence.
Motion #2: submit the glossary for inclusion in the Node-RED content.
I think that overloading 'flow' is problematic when trying to understand context. Make sense?
Just realized another simplification opportunity. I think that Flows = project. I think it is the case that a nodered project folder can only contain one flows file.
No it isn't. The docs you link to are talking about sequences of messages as created by the split node. That is a different thing to what a set of nodes wired together is called. As has been well covered, we overload the term 'flow' for this.
And yes, we need to do a better job of introducing the "proper" terminology in the docs.
Insert my usual plea that if you're putting effort into writing this sort of thing in a personal blog post, it doesn't take much more effort to contribute to the docs.
I've a bit of a thing for glossaries - I forced everyone at work to use the one that I built for our programme which is now about 800 entries long! I also have one (rather dated I fear) on my blog.
Undoubtedly. However, that is what people use I'm afraid. I've just got myself into the habit of thinking about Flow and flow in my head and it works for me.
Ah, while you are correct that I need to include "project" as an entry, I would disagree that they are equivalent. Rather the reverse if anything:
- Project: a flows file and other configuration files that allow rapid switching between Flows.
More than happy, as always to do so.
Just let me know whether the above is something close to usefull and tell me where abouts in the docs you'd like it and I will do a PR to make it so.
As with most of the things that might end up in my blog, they generally take only a few minutes to do so not much effort really. They go in the blog merely because it is so easy to do - I can't believe I stuck with Wordpress for so many years! Now that I use Hugo and Netlify, a post is a copy of an existing post, change the metadata, write the markdown and save. I can do that in VScode (or in Typora if I'm feeling in a GUI mood). Then VSCode's GIT integration lets me hit a button to push the changes and Netlify does the "hard" work of turning everything into an updated website. Ha, turns out that it takes longer to explain it than to actually do it!
TotallyInformation
Minor rant
It drives me absolutely crazy that i have to crawl the Home Assistant forum to find out about component configuration details. I don't understand why the community is happy to bury knowledge in forum threads rather than post configuration details and examples to the actual component pages. At times I feel like it is the case that community members don't realize that they are empowered to contribute.
I haven't been in the Node-RED community long enough to find out if there is a similar opportunity here. Because knolleary didn't redirect you to something that already exists, i would say make it so #1 and find a happy home for your work in the Node-RED docs pages.
Is userDir a reference in Node-RED installation content? If not, what do you think of nodeRedDir?
userDir is mentioned in lots of places in the docs starting from Redirecting…
and is the name of a property in your settings file.
1 Like
I think this is a number of issues.
Firstly, it isn't actually always that easy to contribute to documentation. Typically, you have to know your way around github, git and a decent code editor like VScode. So for non-programmers, this can be quite daunting. For programmers, there is still the difficulty of understanding where things need to go and to match writing styles such that documentation is consistent.
So yes, lots of us want to contribute to official documentation but there is always some friction to overcome.
The great thing with Node-RED is that there are lots of opportunities to contribute. Not only can people help with the main documentation, there is also the cookbook, the flows site where you can submit a "flow" which uses Gists. Then there is also this awesome forum too.
Just my 2 cents
If someone says - here's a flow - I think of a set of connected nodes with a start and a finish
but I also think they could mean a whole tab that contains many such flows.
Also, in function nodes - we have context variables and flow.context stands out as being ambiguous and confusing to beginners
I think if the all the flows within a tab could be moved towards calling them like tab or tabflow or something like that and flow.context moving towards being called tab.context then that could reduce the overloaded use of the word flow
If there were to be a change, wouldn't it be easier to overload or refactor the definition of sequence and let flow keep on being good ole flow? That way, an instance of a node would be a part of a sequence in a flow. Kinda seems natural. An added benefit: all of the flow context examples and language would remain intact.
Just had a middle-of-the-night thought: replace the current use of 'sequence' with 'series' and let 'sequence' take on a new meaning.
