I think it is just the same as with normal node-red. With that, when you press the inject in the browser, it sends a message to the node-red server, which does its bit, and the debug node sends it back to the browser. With the mcu edition it is basically the same, except that the node-red server (mcu version) is running in the device.
[Edit] Perhaps you meant how does the comms work between the browser and the device, in which case ignore me.
Could you please open an issue at the repository. Not much explanation necessary - just to ensure I remember it on the long run.
Yes. This is a "speciality" of Node-RED when it runs as a service. In short, it doesn't have access to the host environment. Thus despite you defined those variables, they are not available to Node-RED. The solution is straight forward ... and explained in the Readme. You have to do this for MODDABLE and for IDF_PATH.
Put an AND between your sentences. The inject node runs in the runtime - that runs on the MCU. The editor runs locally on your system. As with legacy Node-RED, the editor sends the trigger signal, which is then forwarded to the runtime ... on the MCU.
To sum it up: Node-RED MCU Edition provides the same user interaction features as legacy Node-RED.
I hope you and the guys have had a good exhibition today...
And thanks for supporting me meanwhile!
I have create an issue in your Github repo.
I had already added the moddable stuff to my settings.js file, but I have now also added the espressif stuff:
process.env.MODDABLE = "/home/pi/Projects/moddable"
process.env.IDF_PATH = "/home/pi/esp-idf"
Afterwards I got this new error:
Adding ESP-IDF tools to PATH...
ERROR: tool xtensa-esp32-elf has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
ERROR: tool xtensa-esp32s2-elf has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
ERROR: tool xtensa-esp32s3-elf has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
ERROR: tool riscv32-esp-elf has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
ERROR: tool esp32ulp-elf has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
ERROR: tool openocd-esp32 has no installed versions. Please run '/home/pi/esp-idf/install.sh' to install it.
So I runned that install.sh script, and then it was solved. I don't think it is mentioned in the documentation. Might be worth adding it...
Then my build for my wt32-eth01 seemed to have run successfully. But I don't see anything in my Debug Panel, although I have set the inject node to keep injecting messages:
Hmm now I am not sure if there is a way to determine whether the wt32-eth01 was succesfully programmed. Perhaps I am just doing something stupid wrong. Normally I use those devices wired (i.e. ethernet) but to test this quickly I left it connected to the USB/TTL converter. I just unconnected the IO0 pin to leave programming mode. I assume that should work because I have entered the wifi credentials. But not sure at the moment...
Hi @BartButenaers !
We had ... and we're expecting another one full of interesting exchange around Node-RED and the Node-RED MCU Edition. It's too bad you didn't get the clearance to stop by ... 
!
It is; step 8 in Installing. As you don't need this on the other platforms, I'm sure it easily can be overlooked...
The feedback from the MCU to the Node-RED editor is established (only) via the serial connection. Thus it's launched just after finishing the flashing process. If you have to detach the device (as I understood), this is going to cut the feedback line. For this case, there's a way to re-establish the link (after you've re-attached the device) without performing another build run: Press the down arrow of the Build button & select "Reconnect to xsbug...":
This should open xsbug and as well establish the link to the Node-RED editor...
I think that the "reconnect to xsbug" works (when the wt32-eth01 is connected via the USB-TTL converter to my Raspberry), because I see no errors:
But I don't get anything in my Debug sidebar.
Not really sure how to determine in which step I have done something wrong...
Is this perhaps something I should ask Andy on Github?
IIRC correctly, you're running your Pi headless. Are you able to ssh or to vnc into your Pi?
Good memory...
Yes indeed it is headless. And yes I can access it over ssh via Putty.
Ok then! Let's try if it works in general - and afterwards let's make it talk to Node-RED:
I assume that you installed xsbug-log from the Moddable SDK.
Please access your Pi, cd into the Working Directory (that should be logged at the beginning of the build process) & then run ( as safety measure)
source $IDF_PATH/export.sh
followed by
mcconfig -d -l -m -p esp32/wt32_eth01 -t xsbug
Doing this, we take Node-RED out of the game and just perform the basic XS build / connect process; we run the flow on the MCU and - rather than opening xsbug - reroute the debug messages to the console window.
If that works, we'll continue to verify the feedback path to Node-RED.
Hi Ralph,
Seems that xsbug-log has been installed already in:
/home/pi/Projects/moddable/tools/xsbug-log/xsbug-log.js
This was at the start of my build log:
Working directory: /home/pi/.node-red/mcu-plugin-cache/t5rg16s07b
$IDF_PATH is defined: /home/pi/esp-idf
Here you can see the result of those commands:
Not sure what I should see here, but I assume "Terminated" is not the best scenario...
That's the source path.
Please take care that you as well npm installed it as stated here in the second Note. It's called as a node script & thus installation in mandatory to use it...
If you then run (notice the missing -t flag)
mcconfig -d -l -m -p esp32/wt32_eth01
it should launch a compiler run.
With
mcconfig -d -l -m -p esp32/wt32_eth01 -t xsbug
you should at least get the # starting xsbug line as before.
All is good, if this is followed by a log message each time the inject node injects...
I have been following this thread with great interest. I just had my first success with a esp-c3-32s-2m. I had a simple inject node to a debug node. I could see my inject response on both the NR console debug window as well as the xsbug window.
Now do try and do something more fun with it. 
edit: Ok, I am trying another flow. But I am now consistently getting termios.error: (5, 'Input/output error') during the load. Do I need to do something with the ESP between loads?
Not necessarily. It could help though to unplug the ESP once and thus reset the port...
Hmm, this is getting embarrassing 
I really thought that I had executed nicely all the steps required to get this stuff up and running. And over and over again it seems that I have somehow forgotten to run stuff...
Ok, I did some extra steps:
Navigated to that folder and npm installed it:
I ran the mcconfig command without -t:
But that failed after the build, when it tried to connect to the wt32-eth01 to flash it:
Suddenly I remembered that last weekend I had detached my wire to put the wt32-eth01 in programming mode. So I added the wire again (between pins IO0 and GND), and then it started flashing:
I think the flashing was ok, because I got a prompt:
I have closed the prompt (via CTRL-C) to execute your last command with the t option this time. But then I get this:
That doesn't seem ok? I assume I should have left the prompt in step 4?
Damn my (very limited) Node-RED time is up again for today ...
I am hoping to find time to get started playing with this. Is the Wemos D1 Mini supported already? I couldn't find any direct info about using that board with Moddable.
You can build for all ESP32 (and...) boards, no matter what brand.
Those "supported" generate predefined settings, e.g. for the available infrastructure (e.g. buttons or LEDs), to make life a bit easier. It just saves you from finding this data in the documentation.
There should be nothing that stops you from being successful as well with another board...
OK, thanks.
Interesting, if I chose the wrong ESP32 I would get a mis-match failure when trying to flash.
I have tried that. At times I also get an error something about serial crosstalk. Is there a way to slow the serial speed down?
I have installed the SDK and ESP8266 support with very few issues (on Ubuntu 22.04) and tested it with the Moddable hello world example. The ESP8266/nodemcu option seems to work ok so far with the D1 Mini.
I installed the plugin in node-red. When I start node-red I get a message in the log
9 Feb 07:48:13 - [info] *** node-red-mcu-plugin:
9 Feb 07:48:13 - [info] It looks as if a new platform option has been added.
9 Feb 07:48:13 - [info] Please raise an issue @ our GitHub repository, stating the following information:
9 Feb 07:48:13 - [info] > New platform: esp32/atoms3
9 Feb 07:48:13 - [info] > New platform: esp32/wt32_eth01
Do I need to worry about that?
I added a flow with inject and debug node and selected the flow for mcu build, set the build config to
Deployed an clicked MCU Build button. In the mcu console it built it and flashed it ok, finishing with
Writing at 0x003fc000... (100 %)
Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 254.1 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
In the node red log I see
Launching mcuProxy:
- Listening for MCU @ :::5004/IPv6
With anticipation I clicked the Inject button in the flow, but sadly, after everything looking so good, nothing happened.
I don't know what to do now.
No.
At least you should see the xsbug window opening at the Ubuntu desktop...
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy