Feature: support connecting to external WebSocket server as client

[RPdenBoer]

Machine Context

I would like to stream basic G0 commands from a custom webapp via an existing external WebSocket server. This has benefits such as WSS security, and not needing to expose ports (which would be required if using FluidNC as server rather than client). I have limited experience with WebSockets so may be approaching this the wrong way?

Feature Description

Perhaps in config file details can be added for address of server to connect to. SSL cert will also need to be included. I've used previously for projects: https://github.com/gilmaimon/ArduinoWebsockets/blob/master/examples/Secured-Esp32-Client/Secured-Esp32-Client.ino

Other Approaches

The alternative I suppose would be having another ESP32 or similar connect as a WebSocket client, which then streams on to FluidNC via serial?

How I Can Help

I can help test and debug.

[mac7988]

Wouldn't this take away from the communication modularity? I see where you are going with this but I feel like FluidNC already has many ways to communicate with it. Try offloading to fluidterm or integrate fluidterm into your app.

[RPdenBoer]

I'm not sure how Fluidterm helps? To clarify, I'm specifically targeting scenarios where users can go to a publicly available website (using cellular network etc.) and control device in near-real-time, without needing to connect to local AP. Obviously there will be layers of security so not just anyone can have control, and the actual G-code will be hidden entirely behind UI, but that's the basic idea.

[mac7988]

I now understand what you are saying. Thank you for an example.

[MitchBradley]

At this time, I think it would be better to have an external proxy like your Other Approaches suggestion. We have a lot of other stuff to do and it is unlikely your original suggestion will make it to the top of the list anytime soon. The proxy device could handle other network types like cellular. The FluidNC ESP32 will not be able to talk cellular without extra hardware anyway. FluidNC will need to connect to an AP in any scenario, since that is the only way to get out to the internet.

[RPdenBoer]

No problem, I understand it's probably not a common use case. Yes, the idea would be FluidNC connects to local WiFi AP like normal, but is also listening to streaming from publicly available website. This means users could connect using any form of internet access, even be on the other side of the world theoretically.

Any quick pointers on where I should start to implement another input stream myself? Or documentation for how to use I2S0 pinouts so I can make a fully homebrew solution? Appreciate your time.

[MitchBradley]

FluidNC already listens for incoming raw TCP connections on port 23 and for websocket connections on port 81. So any agent that can route to an address on the local subnet can control FluidNC. The problem, of course, is that most local networks do not expose services to the outside. You can get around that with a proxy agent running on the local subnet, talking out to the external server. Maybe you already understand that; if so, you should be able implement such an agent or find one that already exists. Some people do it with VPNs or SSH tunnels.

If you insist on implementing something inside FluidNC, the bar will be very high for us to accept your code into the upstream version. You will have to prove to us that you really understand all the implications, otherwise it will turn into a maintenance problem for us. The fact that you have asked for "quick pointers" is not a good sign. Typically, doing something like this effectively in a complex codebase requires deep understanding of the code, so there is nothing at all quick about it. The people that succeed are the ones that dive deep into the code on their own.

I don't understand how "I2SO pinouts" has anything at all to do with this task. I2SO is a trick to add more stepping outputs to an ESP32, unrelated to network protocols. If you want to do a homebrew controller for other purposes, the I2SO "documentation" is in the form of open source schematics for controllers like the 6 pack, MKS DLC32, and others. It is a straightforward shift register setup whose hardware operating principles should be obvious to anyone who understands how shift registers works, just by looking at the schematics.

[MitchBradley]

Search for "localtunnel"

[RPdenBoer]

Yep, I understand most of that. I wanted to avoid exposing ports publicly. I'll do some more reading. Thanks again!