Bummer...
Personally I don't mind. It is like two raspberries running both Node-RED on top of NodeJs. Then you also use mqtt in-out nodes in both instances, to communicate.
Having the sam technology (Node-RED) on all my devices is my ultimate goal.
Don't know if you have seen, but they also have UI nodes...
I don't mind going through MQTT, just that putting the nodes and required paths everywhere is just more work and more opportunity to fat-finger stuff. Would be nicer to just link things up and elsewhere configure how to map to MQTT paths and which MQTT nodes to use, etc.
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 subflows 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
Re: "ui_nodes", you realize these are implemented for local display on an LCD, right? If I can make friends with the moddable mcu stuff you can bet on FlexDash making an appearance...
I was already typing that, but you were faster than me on my bloody small smartphone 
If I remember correctly - at the time being - one of the future possible usages of the Node-RED message hook system was to communicate messages to sub)flows running on remote devices. Unfortunately I cannot find the link to that article anymore. Is that what you were expecting here perhaps?
That was not my intention when I mentioned it to you 
Yeah, that's what my pre-hook era 2016 running nodes on Espruino on esp8266 did... Time flies...
1 Like
In principle this should be possible. The messages objects themselves are as similar as practical when running on the MCU. That is allows, for example, the MCU plug-in to receive the output of Debug and Status node and relay it to the Node-RED editor for display.
But.... I vaguely know that Node-RED can send messages between flows running on two separate devices. I have no idea how that works. For example, how are they transported? If you could explain the mechanism used there, it will help me understand what it might take to support that on the MCU.
... one of the ideas behind adding Groups is that one day they could have their own properties... and one of those could be "lives somewhere else" - which then implies a) the group would need to be deployed "remotely" (in this case compiled etc) - and b) any wires in and out would imply some sort of connection without explicit nodes... but it's no more than an idea currently - as both of those invite loads of open questions and edge cases with no answers or design - so is still on the wish list what with other tasks and priorities etc etc.
I am planning a couple of projects using the Seeed Studio Wio Terminal. Is there a possibility to support node-red-mcu on this platform? If so, what would have to be done?
@drmibell, thanks for your interest. We don't currently support the Wio Terminal. We have investigated support for the Realtek RTL8722 MCU that powers the Wio Terminal. Unfortunately, Realtek doesn't provide much support for open source use at this time. It is certainly possible to support, but it would be a new porting effort. Perhaps in the future.
Until then, the M5Stack Core2 is a similar form factor, and is very well supported. It is a popular choice for many Moddable developers, including the (award-winning!) Stack-chan robot project. One advantage is that it is powered by a dual-core ESP32 that has a faster CPU (about 2x).
Thanks for the quick reply. I appreciate your having looked into this. The M5Stack system was the first thing we checked, but the Wio Terminal seemed to have some advantages for our application. We will probably get our feet wet with with node-red-mcu using your Moddable Two kit and move on from there. BTW, I think the Realtek chip handles wireless comms for the Wio Terminal, but the MCU is a Microchip ATSAMD51P19. (My impression is that Microchip is also not very friendly and -- like others -- having issues delivering silicon.)
@drmibell ā Moddable Two is always an excellent choice.
It looks like you may be correct that the Wio Terminal uses the Realtek MCU only for BLE & Wi-Fi, relying on the Microchip part for the main CPU. I don't personally have experience with Microchip MCUs, so I won't speculate on what might be involved there.
1 Like
Boy I sure am glad I caught this thread. I watched the talk and it gives me (yet another) thing to experiment with.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
