Octoprint through WiFi (with no Raspberry Pi)

Guys, this is my first post so please give me some head start :slight_smile:


You can damage your printer by doing any modifications. This is only for educational purposes. Anything you do is your responsibility and I'm not responsible for results of any unsuccessful modifications. You have been warned.


The thing is to have the Octoprint working without a dedicated PC (Raspberry or other) that is connected to your 3D printer just for dealing with Octoprint. For some of us it can be waste of such good piece of hardware. So this can help you or you can treat it as a fun fact.

In this approach we will use serial connection (UART) over the WiFi (the same way applies for the Ethernet). We will use cheap and small ESP8266 board that will be connected directly to our 3D printer. Also, you need some kind of PC that will anyway run the Octoprint on it, but maybe you already have some PC (Raspberry Pi?) working all the time and you want to make use of it. On host side we will run Octoprint in a docker container.

This guide has been succesfully tested on following setup:

  • Ender 3 S1 3D printer,
  • ESP8266 nodeMCU board,
  • Raspberry Pi 3 (host PC) with docker.

For the ESP's side it works on every device that can be flashed with EasyESP and has UART pins accessible.


  • no more wasting the Raspberry Pi only for Octoprint,
  • your 3D printer can be accessed remotely through WiFi,
  • optionally, you can use with camera with ESP32 (with camera module).


  • TCP packets can be lost during connection,
  • you need to solder cables directly to the Rx and Tx of your printer (not USB),
  • you need to have host PC for Octoprint,
  • installation is a bit tricky.

Software description

EasyESP firmware is beautiful piece of software that has a serial2net capability which helps us to achieve our goal. It can send the whole UART through the Ethernet (in our case WiFi) and it can be used bi-directionally - sounds great, isn't it? Also, you can always connect to your printer via telnet and you will speak to each other like with normal serial connection! With our approach neither printer nor octoprint will have no idea that the conversation is going through WiFi.

Electrical description

You need to connect your ESP board directly to your 3D printer's motherboard. If you have possibility to connect your printer to the PC it's highly possible that there is some UART-to-USB converter on printer's motherboard. In my case it was CH340G that is widely used in many various devices. Just connect both Rx and Tx, 3V3 and GND to your ESP board and you're ready to go. Take a look at the basic schematic below:

How to connect ESP8266

You can solder cables directly to the pins of the CH340G, or (in nicer way IMHO) to these test-points on the printer's motherboard:

Don't forget to glue the cables with some hot-glue gun - this will avoid cables and test-points to be ripped off!

What you need

  • nodeMCU (ESP8266) with EasyESP installed,
  • another PC (host) that can handle Octoprint instance, connected to the same LAN network togheter with ESP8266 board,
  • docker installed on host PC and, of course octoprint container running,
  • some Linux experience.



on EasyESP side

  1. Go to Devices > Communication - Serial Server.
  2. Disable Serial port in Tools > Advanced.
  3. Set TCP port to 23 (usually telnet) or whatever port you like.

on host side

  1. Connect to your octoprint container's console.
  2. Install socat with apt install socat command.


  1. On host, go to the console and execute
    sudo socat pty,link=/dev/ESP0,raw tcp:
parameter description
/dev/ESP0 virtual port handle, use whatever you like your EasyESP board IP address
23 virtual port you have set before at EasyESP installation

The virtual serial port will be created with /dev/ESP0/ handle, that you can use in your Octoprint.

  1. Open Octoprint, go to Settings > Serial Connection > Connection and add /dev/ESP0 into Additional serial ports window.
  2. Save and click Connect - it should connect now with your printer!

1 Like

Nice guide. Another option is using GitHub - hellerbarde/OctoPrint-Network-Printing with esp3D flashed to an esp8266.

I didn't know that - thanks! I will look on that and compare two ways.

Anyway my guide will be helpful when you want to have more control over what's going on or when you're just curious like me and want to learn to something new :slight_smile:

Hi, this is exactly what I was looking for. Unfortunately, I don't have access to the test pins of my mother, but it has a USB (type B) connection. Are there any ways to convert the USB port to the serial server without accessing the "rx" and "tx" pins? I have tried connecting the ESP micro USB with an cable, but it doesn't work.
My printer uses a BTT SKR v1.4.

Hi there!
I'm not sure it is a case for your motherboard. Looking on picture of the motherboard I cannot see any UART RX or TX pins that you could use. You need these pins accessible to use this solution.

Is this board even works with Octoprint with normal USB connection?

Yes, I can install OctoPrint on my PC and connect the printer to the PC with a cable and it works.

Looking at the board you listed.. the UART connection is just behind the Wifi connection.
See the full image here

And this is just he area you are looking for. Should be able to do it just use some Dupont style plugs.

The pins labeled TX0 and RX0 are what you are looking for.. Most boards will expose these on posts like this.

Thanks for the answer, but I have also tested those and they don't seem to work. I have also tested the ESP module separately and its connection is good. The only part that doesn't work is the connection between the ESP and printer! I have also tested other RX and TX pins. Could this be a firmware issue?

Also, aren't RX0 and TX0 for TFT only?

Not something I have done before with this board, but I it does seem to suggest that the Tx0/Rx0 might be used for a TFT. It's all in the firmware. I am pretty sure if you don't use the existing incoming TX and RX you would have to update the firmware to know you were using that set as the main command pipe.

Looking at the MCU Spec sheet it seems that the USB interfaces are built into the main chip. You can not just inject your Serial lines directly into the system like shown in the original example.

You might be able to modify the code used in the wifi Module. It communicates over Serial on TX3/RX3. You would have to get an understanding of how that interfaces to the board and firmware. But it might be a solution. It is the only interface I see that would be pure serial into the MCU. For sure not as easy as just wiring things in.

BTT SKR V1.4-SCH.pdf

Yes, I think you are right. What about the USB port itself? Can I connect the printer's USB port to ESP's USB port or it's RX TX? I have tried connecting these through a USB to TTL convertor, but the printer's USB port doesn't seem to have power.

Not without some very specific firmware. What you have to realise is that the port on your printer is not really a Serial port it is a USB device interface. It identifies it self to your PC as a serial port and the software drivers on your PC/Pi do all the conversions including registering it as a serial port device. Your PC has a Driver that takes any of the commands that would normally go directly to the hardware device and then sends the proper info over the USB interface protocol and that is converted in your Printers CPU back to a serial port in a similar way. There are device out there that can do this but they expensive. For many the cost would for sure rival the cost of the printer.

I have also seen some work that is done with the Raspberry Pi Pico that looks promising but it is not directed at 3d Printers. It is almost always directed at keyboards or other HMI interfaces. This project by sekigon-gonnoc called Pico-PIO-USB seems to have some promise in that it must be doing some similar conversion as each keyboard segment is added to in the demo. The demo video link in the readme seems to not be working for me but here is a direct link.

If you had the time and chops to workout the firmware, this could be a direction... Maybe. but, it would be a lot less expensive to find a 3d Printer motherboard that has exposed direct access to the back side of a USB to Serial conversion chip(CH340) like the board used in the example at the top of this Thread.

One other option I had thought of is to use a Pi Zero W in place of the ESP32 at the Printer side. It has the USB interface and it would be pretty easy code to receive data in the same way as stated above using an ESP32 and send it to the USB interface connected to your printer. The Pi Zero W can be gotten for less than $40 as a full kit and about half that if you just get the board. Its a bit overkill (maybe not) for the use case but it is inexpensive and does remove a good bit of the interface hurdle. If you keep the OS really light and run everything in memory, it could be really reliable and the SD card might last a very long time.

Instead of an RPi Zero W (which is marginal as an OctoPi / OctoPrint host) use an RPi Zero 2 W and just install OctoPi / OctoPrint and connect via USB.

At around $15, you have a supported, functional solution without tinkering with the hardware.

@b-morgan, you’ve made an excellent observation. While employing a local, cost-effective Raspberry Pi is the conventional approach, the essence of this discussion is to consider alternatives, as indicated by the topic “Octoprint though WiFi (with no Raspberry Pi)”. Starting from this premise, we delve into the possibilities of transmitting serial communication wirelessly using specialized, compact hardware designed solely for this function.

While I have reservations about the Pi Zero w option in my previous post, it does address several challenges right out of the box. With proper implementation and simplicity in mind, it could offer a few years of reliable service.

My consideration for this type of connection stems from the Raspberry Pi’s general lack of reliability and the significant time and financial investment required to achieve a moderately dependable state. The Pi, in essence, is better suited as a tool for proof of concept and experimentation rather than long-term deployment.

On the other hand, a well-constructed mini PC promises greater long-term reliability at about the same total cost. If you have robust hardware at your disposal(read server class), you can allocate just a fraction of resources and avoid common concerns such as overheating, SD card failures, or unique automation tasks to ensure proper backups and other preventive maintenance (PM) level tasks. These issues can be managed more efficiently at a higher level of PM , eliminating such failures that often accompany long term use of a Raspberry Pi. It’s likely that anyone who has operated a standard Pi setup for an extended period has encountered at least one of these problems. If you have a lot of systems to manage removing or simplifying the local compute device can save a lot of headaches. One could also argue that transmitting the Serial communications in this way might actually introduce other not so easy to solve issues. And for sure there are only a couple of very expensive off the shelf options to do this without using something that is more or less experimental in nature. Maybe for some it boils down to a decision about where to have the complexity.

I guess we have to agree to disagree :grinning:

I don't believe that a Raspberry Pi is unreliable or requires significant time and financial investment particularly when considering an RPi Zero 2 W. I do agree that an RPi 4 or RPi 5 is moving into the significant financial investment category.

OctoPrint has to run somewhere and delivery of gcode commands to a 3D printer needs to be as close to real-time as possible to prevent artifacts on the printed object.


There is the ability to do rfc2217 or esp3d/raw tcp socket over wifi and this plugin. I tested it with esp3d and it was pretty easy. You basically have esp32 device connected either via UART or USB to the printer and this plugin connects OctoPrint over the network to that connection.