Musings about a slightly different approach

[tve]

I was musing about how one could make node-red-mcu-plugin a little simpler, specifically with less software to install and involve. The main idea would be to produce ready-to-go images for popular microcontrollers, e.g. esp32 & pico. This doesn't seem like a popular idea at Moddable but ... well, different debate. Anyway, suppose you had an esp32 image (pico could work the same way) that had:

• the node-red-mcu app
• networking with websocket
• an outer "manager loop" that talks to NR over websocket
• the ability to load mods

What node-red-mcu-plugin would do on deploy is:

• same parsing & mapping of deployed flow nodes as currently
• run the nodered2mcu transform to generate a mod representing the flow
• ship the mod over the websocket to the esp32's "management loop" to run
• use the web socket to forward NR messages bidirectionally

What this does is completely eliminate the need for esp-idf, and eliminate the need for most of the Moddable SDK on the system running node-red. There is still the step of running the nodered2mcu transform and generating byte code to be done. Some thoughts:

• does this use only tools written in javascript & can they be packaged as NPM and loaded into node-red?
• can a simplified install of the SDK be constructed that has just the necessary tools?
• at least esp-idf is not needed

I'm probably missing some stuff, but ideally the end result is that to get started with node-red-mcu-plugin a Node-RED user would:

• install the node-red-mcu-plugin package in NR
• install esptool.py (anyone who has an esp32 laying around already has that)
• download and flash the generic esp32 image with the above app
• configure the wifi on the esp32 (I didn't cover that, several options)
• configure the node-red-mcu-plugin config node with the address of the esp32
• create a flow and deploy

I used websockets as the communication mechanism in my description, but perhaps using serial is easier as it avoids the step to configure Wifi. Also, all this targets the esp32 'cause I'm familiar with it, I'm sure the same set-up works for pico or pico-W.

[ralphwetzel]

Thank you for this proposal.
Rephrased with my words, this means (as I understood it) to put a runtime on the MCU, that is able to interpret a flow adequately prepared & to provide communication channels to the editor. This definitely looks like a setup achieving the same / a similar result.
As you are aware, we've chosen a different path - who's main drawback is (from my perspective) the handling of the various toolkits that have to play together nicely.
Nevertheless - there's definitely a valid point in your proposal. I'll make up my mind to decide what this means for node-red-mcu-plugin...

[tve]

who's main drawback is (from my perspective) the handling of the various toolkits that have to play together nicely.

Yup. I don't know whether you've played with Espruino or Micropython. The getting-started contrast vs. Moddable is pretty stark.

The other issue is how long a "deploy" takes. If you're building a full image you're looking at at least 30 seconds before it starts. If you're sending it OTA even longer. If you were sending a small mod and eventually perhaps even only the nodes modified then it may be just a couple of seconds.

[ralphwetzel]

The Moddable team has chosen an approach to move a lot of work in the build step, that other setups perform at run time. This consumes time upfront - leading to the mentioned delays - yet improves performance when running the device; that said, the performance of a tiny ESP running w/ Moddable is impressive, being capable of much more than just reading a single sensor and pushing the result to MQTT. But this doesn't mean, things must be as they currently are. There's definitely a lot of potential still to be harvested for node-red-mcu.

[tve]

My point isn't really about the technology. The main reason I'm here is the fact that code can be optimized on the host and then something small & fast loaded into the MCU. However, the overall approach to getting started seems awfully like premature optimization to me. I would be much happier if getting started was easy, and then when I'm comfortable and have something going I can go and ask "how do I optimize this?". Judging by what people do with Espruino or Micropython as well as my own experience, the optimization ends up not being necessary in many, many cases.