How does this work?

[tve]

I'm a Node-RED contributor and have previously run nodes on espruino. I'm not entirely understanding how this plugin is supposed to work or what it's supposed to do. Probably due to my preconceptions...
Is the idea that I'm running a node-red instance per MCU?
Or can I run a "server" Node-RED instance where some of the flows run on some MCU instead of running on the server itself?
And can I then have link nodes that go from, say, a server-side flow to an MCU-side flow and some communication mechanism I set-up sends the messages across? (That's what I had with Espruino)
If this is not how it's supposed to work, can you explain? :-)

[ralphwetzel]

If this is not how it's supposed to work, can you explain? :-)

I will try to:

The idea is that you create a flow (like always) in the Node-RED editor. This flow, that usually runs in the Node-RED runtime, is then compiled (we call it build) and pushed to a connected MCU. The MCU resets and launches the flow. As long as the MCU is connected to your development system & running the flow, you'll receive the feedback you are familiar with from your standard Node-RED operations, like status updates or debug messages, created by the MCU - in the Node-RED editor.

You will - currently - be able to use nearly all of the standard nodes & some more, as described in the node-red-mcu repository. The MCU yet acts as an autonomous system, supporting many communication protocols. Talking e.g. to an MQTT broker is as simple as dropping and configuring an MQTT out node in your flow.

To manage expectation: The Link-across-Systems feature you described is currently not available.

Dis this short explanation answer your question(s)?

[tve]

I think I understood as much. Quoted from https://discourse.nodered.org/t/anybody-experimenting-with-node-red-mcu/71836/23 :

All this brings up more fun thoughts:

• You now have that flow for your whizzbang controller
• But of course, you really have three whizzbang controllers in your hand...
• Now what???
• Would be nice to have that MCU flow in a subflow, no? (I know it's not yet supported but on their roadmap [and I know how much fun it is to hack around the subflows...])
• Now what? You'd still have to create 3 flows just to plop down 3 copies of the subflow...
• WHAT IF the whole MCU flow thing wasn't attached to flows but to subflows, i.e., all flows run on the server, but you can have subflow (instances) that run on MCU?
• Now you could have your overall flow, which includes inputs from a dashboard or other devices (all std server-side NR stuff), wires into the three MCU subflow instances for your three controllers, and then wires coming out of the subflow instances going to (server-side) visualization nodes.
• This seems like it would be very compelling to me, and more scalable too

NB: the fact that the wires need to involve communication doesn't have to be magic, the machinery could be configured to use one of many comm protocols, it could even make use of something the user puts together in another "meta" flow.

All this isn't really dreaming. I implemented a proof-of-concept like that (minus the subflows) in 2016 running node-red nodes in Espruino on esp8266's: https://groups.google.com/g/node-red/c/pJXwdl2UMQ8
At the time I gave up 'cause the esp8266 is really to constrained for doing much useful with Espruino and then life took over...
But in a way it was a very complementary project to yours in that the "running nodes on Espruino" aspect was very hacky, but the integration into Node-RED flows was quite nice.

[ralphwetzel]

• This seems like it would be very compelling to me, and more scalable too

I'll put this on the list of future features we're heading for - taking your earlier project as reference!

[tve]

Note that my project is pretty much obsolete at this point. It predates the whole modularization of the Node-RED runtime. There are now hooks to do stuff like I did back then. So it's just inspiration-ware 😆