Input required for a cheat sheet of node-red-mcu(-plugin)

Hi folks,

I am trying to find some time to experiment a bit with node-red-mcu from @phoddie and node-red-mcu-plugin from @ralphwetzel.

Very fascinating technology! But I am having some troubles to get started. I have to admit that a main issue is my lack of knowledge about the subject. Due to free time constraints, I have never looked in detail at mcu's and all related stuff. So here we are now:

  • I had to install a series of tools, and in fact I didn't know what I was installing.
  • The sidebar offers a number of (technical) options, and I didn't know what I needed to select.
  • Some errors occur in the xterm terminal inside the sidebar, and I had no clue what it was all about.
  • And so on...

As a result I am not making much progress. But the whole team is VERYsupportive (Ralph, Peter, Andy, ...). A real school example of an open-source project. However the amount of noob questions I had to ask them is getting embarrassing...

So in order to get a bit more understanding about all this stuff, I am trying to create a cheat sheet diagram to visualize the entire setup:

  • To visualize the entire architecture
  • To explain where which installed tools are being used
  • To show the entire flow that messages will have to travel to go to the mcu and back to Node-RED.
  • To (hopefully) understand the logs/commands better, to allow me to do troubleshooting on my own.
  • ...

Here is my first draft version:

This version will certainly contain incorrect stuff, and important info will be missing. So I would really appreciate if the community can give feedback to turn this draft version into a usefull diagram. It always helps if you just draw some extra stuff on top of my diagram, and share the updated version. Doesn't matter if it is drawn quick and sloppy!!!

Hopefully afterwards this cheat sheet support other users, that want to get started with this magnificent piece of software.

Thanks!!!
Bart

10 Likes

That is brilliant Bart. I can't comment much on the accuracy, but what I understand so far looks good. I think that will be very useful.

This is really great, Bart. I have a few suggestions and corrections. But before posting those, I wanted to check to see if you have an updated version. I recall from our debugging session last week that you were still making updates. Thanks.

@phoddie,

Ah indeed I had done some updates immediately after our Zoom session. Here it is:

It would be nice if you could review it again. And there is some important stuff missing. For example the folder with build files that you had cleared during our session. Not sure where it is located in this diagram, although it is a very important folder. Would be nice to have some stuff like that on this drawing, because that allows us troubleshooting in depth. This is no diagram for softies :wink:

Feel free to draw on top of it with some ordinary paint tool. I will update my drawing afterwards with your priceless feedback...

Thanks a lot !!!!
Bart

1 Like

@BartButenaers, I marked up a copy of your cheat sheet. It is quite accurate in the big picture. Most of the comments are details but perhaps they will help you and others understand this a bit better.

I hope my notes are clear. Please let me know if you have any questions.

1 Like

@phoddie,
Thanks for reviewing!!

Some questions about your feedback:

  1. The debug channel is bidirectional. It would be very useful if you could specify a bit more in detail which messages are going which ways, to provide us some insight in how the traffic flows. I mean to add a small enumuration of message types (inject node button, status messages, ...) for each red arrow:

    image

    So that people can figure out more easily why e.g. they don't get message in their Debug sidebar, or no status updates, and so on...

  2. When does the green line exists? I am not sure anymore which kind of messages are possible in both directions in case the serial connection is removed, and the MCU is only connected via wifi/ethernet. E.g. during an OTA-update, the progress percentage is showed in the node status. Would be nice if we could also (in contradiction to point 1) draw the message types that can run when no serial connection is available. And then the proxy is not used or is it?

  3. During our Zoom session we had cleaned all build files in some directory, which is not on my diagram yet. Would be nice if you could add that directory somewhere.

  1. The debug channel is bidirectional. It would be very useful if you could specify a bit more in detail which messages are going which ways, to provide us some insight in how the traffic flows.

From MCU to Computer:

  • Debug node output
  • Setting status of node
  • xsbug console output

From Computer to MCU:

  • Inject node button
  • xsbug operations: Break, Go, Step In, Step Out, Step, Kill (restart), set breakpoint
  1. When does the green line exists?

When the proxy server is not present, then there is a direct connection from the USB serial port to xsbug. When the proxy server is present, it receives all communication first and relays that to xsbug.

I am not sure anymore which kind of messages are possible in both directions in case the serial connection is removed, and the MCU is only connected via wifi/ethernet.

The serial connection is used for all debug and status messages. When it is removed, none of the messages noted above flow are transmitted.

  1. During our Zoom session we had cleaned all build files in some directory, which is not on my diagram yet. Would be nice if you could add that directory somewhere.

Tracking that down isn't much fun because of the random name assigned to the directory by the MCU plugin. Instead, I suggest using the MCU plugin to clean the build results. Set the "Build Target" to "clean" and then choose "Build" as usual.

image

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.