For a long time I searched a solution to communicate between subflows, and I adopted a solution that works and I use it lot. It's have for example save subflow, that then broadcasts that changes to another subflow, that I use in different zones of the code.
My solution is a internal MQTT server in localhost, I publish a message and the message arrives at the other subflow. This works well, but I can't wonder if this is the best approach... Sometimes I notice some lag.
IMHO - If you are communicating from the internals of one subflow to another, you have an undesirable design. subflows should not have side-effects (i.e. should be pure) - I wont get into the principles behind that but will say its a bit like there is nothing to stop you using globals all over C++ or goto in VB - its just not a good design and catches you out when it comes to re-use.
A good example of pure is when you copy a subflow to another machine & it just works (i.e. there is no external dependency)
Sorry if this sounds like an attack or condescending (I really dont mean to be) but it really isnt (again IMO) a good way to use sublows.
Sublows shouldnt really be used for hiding bunches of nodes (they can and do get used in this way) but really, a subflow is like a class that you create instances of. You would should* never have a class member function operate on a global - it would break when you try to use it other projects.
It's very useful to have a subflow that allows to do a broadcast, we have a lot of nodes that do similar things, a subflow is just a way for us to design our own "nodes" and reuse them. I know that MQTT is now the best solution, it's not very fast (compared to TCP for example). I understand what you say regarding bad design, but how would you approach a broadcast scenario that you can reuse?
Stay pure.
Input all necessary variables required to do computation inside the sublow.
Output the final (communication) values then on the main flow, push them to MQTT broker (or into 2nd subflow etc)
It ends up almost the same but the choice of where to send is made in the main (or if you like - global) part of the flows.
EDIT...
TBH, this ^ statement should be a clue as to why its not a great idea (its not provided out of the box).
At the end of the day, there is no right or wrong way.
If it works for you, thats great really. node-red is super flexible and accomodating.
I just know from experience that sometimes, following a few rules like DRY and PURE really help when it comes to re-use and portability.
I followed your advice and killed the MQTT solution, replaced it with some wire connections and some link connections. To ensure that all was working and to make some tests, I monitor the time between the link in and the link out, and stored the min time and the max time, and to my surprise I have max times of 2054 ms, 2 seconds, that seems to high to take a message from one link input to a link output!
The delay you are measuring is not the time taken for it to flow down the wire but the time between sending the message out and the receiving node getting given the processor.
Node red is single threaded so if you have anything in your flow that can hog the processor for a time then that can cause a pause in everything else that is going on. Also the memory garbage collection will occasionally lock things out, but I would not expect that to take 2 seconds unless you are on a Pi Zero or similar, and even then it would be very unusual I suspect.
So probably you have a node somewhere in your process that can lock up node-red for 2 seconds occasionally.
That can be the case! Who can I find it? What should I be looking for? What kind of nodes can hold a system like this? This is really strange and I would like to clean it up!
Another question, is the order of the flow tabs important? Should I put the more time depended first? And the order of the nodes inside the flow tab?
