Do you get the GPI node from one of the plugins? If so, which one? There are a few.
It is one of the core nodes, I think.
Ah, no, it is one of the Rpi nodes.
[Edit] Which makes me wonder myself how I come to have it on my Ubuntu machine.
LOL, now you understand my confusion.
I think I found the node npm install node-red-node-pi-gpio
edit: Now I am thinking that node will not work. I am getting a "rpi-gpio : Raspberry Pi specific node set inactive"
It won't work if you put it in a normal flow, but it does work in an mcu flow, as that doesn't run on your computer, but on the device it is connected to,
As I told you:
Here's the procedure:
-
Prepare the WT32 for flash (connect IO0 to GND)
-
Choose Build Target
build, press Build button:
-
Choose Build Target
deploy, press Build button:
-
Disconnect IO0
-
Choose Build Target
xsbug, press Build button:
(Alternatively, chooseReconnect to xsbugfrom the Build button down-arrow-menu) -
Disconnect Power Pin @ WT32
-
Reconnect Power @ WT32
-
Enjoy!
There's one issue though: Build Target xsbug fails with Debug Target console (and thus in your setup!) ... most probably due to an error in the make script. This needs a bit of further investigation...
Faster than my shadow 
-
The build phase seems ok to me:
... Project build complete -
The deploy phase also seems ok to me:
Executing "ninja flash"... Done -
I got the impression that every time after 2, I get this error:
After rebooting my Raspberry it seems to be solved. Of course this is not a very scientific approach. So if anybody knows a more graceful way to handle this, don't hesitate to share it!
-
The xsbug step - after disconnecting IO0 - always seem to fail for me:
>> IDF_PYTHON_ENV_PATH: /home/pi/.espressif/python_env/idf4.4_py3.9_env >> mcconfig -d -x localhost:5004 -l -m -p esp32/wt32_eth01 -t xsbug ssid=xxx password=yyy /home/pi/esp-idf/tools/idf.py Terminated -
The same log lines occur when I choose "Reconnect to xsbug".
-
When I reconnect the power again my wt32-eth01 I see nothing happing in my Debug panel.
Is that the same issue that you are referrring to? But is that a real show stopper, or did you expect something to see in my Debug panel? Or perhaps I forgot to install something...
I think my flow is correct:
Same happened to me. Guess that's a peculiarity of the wt32 board...
It does as well for me. There's something strange happening (platform Linux, build target xsbug, debug target xsbug-log) ... and it's not related to the plugin. I propose you report an issue @ the Moddable repository.
It is. To start the debug data transmission of the MCU, a connection to (a type of) xsbug currently is still mandatory.
Your flow is perfect for an initial test...
I have created a ticket. Hopefully they can figure out what is going wrong. Have a nice weekend!
Hi @ralphwetzel,
Andy did one attempt to fix my issue, and it was immediately jackpot. Very impressive...
My first flow is now running on my wt32-eth01:
Although it is a ridiculous useless flow, this will be most probably one of my Node-RED highlights of 2023 already. This is so cool 
Now I need to find some time to test the sensors that Andy implemented for me...
2 Likes
I'm really happy to see that flow running on your board... 
1 Like
LOL, I had the exact same ridiculous flow to start with. Then I added a MQTT Send node. Not much better but it worked like a charm!!
1 Like
I have not had time to get back to this. But my interest is still peaked. It has been pretty quiet overall. Is there another communication area that has some activity that I can lurk on?
The community around Moddable is growing. You can find some very interesting discussions on their Github repository. And more specifically around their Node-RED integration (i.e. node-red-mcu), you can find the discussions here.
Keep in mind that most of us have a daily job, familly, other Node-RED contributions, and so on...
1 Like
I have this simple flow functioning in a Wemos D1 Mini. It regularly gets the current temperature from one or more DS18B20 sensors and publishes them individually to topics which include the device ID. It requires node-red-contrib-ds18b20-sensor to be installed. A nice feature is that if you want a number of them, in different rooms for example, they can all be identical as the topic includes the sensor id. They do not need to be individually programmed.
Basically it works perfectly, except that I am falling over this issue (it is a node-red-mcu issue rather than the plugin) which causes the sensor node to fail dependent on what should be trivial details of the flow.
[{"id":"ca71fe5f83dd3ed0","type":"tab","label":"mcu test","disabled":false,"info":"","env":[]},{"id":"daf71fd6976e6abe","type":"mqtt out","z":"ca71fe5f83dd3ed0","name":"","topic":"","qos":"0","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"75fb29423f8a0770","x":690,"y":260,"wires":[]},{"id":"e8104385c3f36513","type":"debug","z":"ca71fe5f83dd3ed0","name":"debug 86","active":true,"tosidebar":false,"console":true,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":510,"y":60,"wires":[]},{"id":"5da2de6f6e27f039","type":"inject","z":"ca71fe5f83dd3ed0","name":"Measure","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"10","crontab":"","once":true,"onceDelay":"3","topic":"","payload":"","payloadType":"date","x":100,"y":260,"wires":[["36501d946e21bc46","e8104385c3f36513"]]},{"id":"36501d946e21bc46","type":"rpi-ds18b20","z":"ca71fe5f83dd3ed0","topic":"","array":false,"name":"","x":270,"y":260,"wires":[["28589ba6de2421c5","e8104385c3f36513"]]},{"id":"28589ba6de2421c5","type":"function","z":"ca71fe5f83dd3ed0","name":"Extract id and temperature","func":"if (msg.payload.id && msg.payload.id.length > 0) {\n msg.topic = `tydwr/ds18b20/${msg.payload.id}`\n msg.payload = msg.payload.temp\n return msg\n}","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":480,"y":260,"wires":[["daf71fd6976e6abe"]]},{"id":"75fb29423f8a0770","type":"mqtt-broker","name":"Owl2 for mcu","broker":"192.168.49.83","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
1 Like
Hi @Colin,
I am a bit confused right now. I thought that if you would like to read data from a ds18b20 sensor, that the people from Moddable need to implement it. And that you need to use their Sensor class.
But do you mean that you do it on the mcu using that node? Thanks for clarifying it!
For a small number of contributed nodes - like rpi-ds18b20 - there're shims available, node-red-mcu targeted implementations that are used (transparently) when building the flow for the mcu.
A list of all implementations available in the node-red-mcu core is maintained in its documentation.
1 Like
In node red you have to place the sensor node in the flow, so you need to install it for node red. At run time it uses the version of the node supplied by node-red-mcu, configured by the flows file.
1 Like
I just got a Lilygo T5 4.7" e-paper display with touchscreen, can this work with the NR MCU edition ?
Fiddling around with esphome, but I find it too much work :') although it does work well.
There's native support for any ESP32, dedicated stuff for lilygo_ttgo & lilygo_t5s, capability to support touch interfaces & even an epaper Blog.
Thus I'm sure there's something you can build on. At best, you create (based on this information) a config that we can put into the toolkit - which yet might demand some fiddling around as well.
1 Like
