Set ESP WiFi connection by POST request

Recently I was working on a project with ESP32 module and I was needing to set up wifi connection from another application, not using the usual webportal from WiFiManager library (opened in 192.168.4.1). Looking for a solution using all code already developed for this purpose, I observe a way to set up WiFi connection using WiFiManager library with a POST request.

WiFiManager

WiFiManager (https://github.com/tzapu/WiFiManager) is a library to set the connection configuration in a simple interface. Once uploaded on your board, if not configurated yet, the library create an access point that generate an html page with all WiFi options at 192.168.4.1. In this interface you can easily select your network (5G not allowed) that will be added to your microcontroller.

This library attends very well the necessity of set a WiFi connection on a microcontroller. The interface is very usual and the process works very well, so, my idea was not to remove this library, but to communicate with it without to open this portal, sending all information through back-end. Here is the WiFiManager webportal: 

How to use it

The better approach to understand is to observe the basic example at the library repository. The code starts creating a WiFiManager object that uses the autoConnect() funcion to check if the board have some connection saved and, if not, create an access point that will be normally listed on your available networks. 

After that you can connect to the WiFi (the name will be similar to the image, like ESP32_96A4E30) and automatically the webportal (image above) will open for you to set the informations. It's nice to frize that the connection will be saved at board memory, so you don't need to worry if restarted.

Ok, but how this library works? 

A webportal is created by ESP, this indicates that some server was serving this page and receiving informations to set on the board, so: the WiFiManager construct an API to receive informations and uses the ESP as a server to the interface. The resumed flow would be something like:

Start a server at 192.168.4.1 ⟶ The HTML page is served ⟶ Forms is posted ⟶ API receive and save informations

The library offers a lot of customized options that you can check at the "library library" (.h file), but the most important thing now is to understand that an API is locally available and one page already communicates with it.

Finding the Solution

Knowing that I had an API available, I needed to know what was sent and for where, this way I could just to connect and send the information in a similar way. For this, I connect my machine to ESP access point and then I used curl tool to read what was in 192.168.4.1/. I get the following result:

It's possible to see that is an html file. The important here is to look at the buttons parameters, especially the routes related to them; the green mark highlights this: a route to /wifi, a route to /info, to /exit and to /update. This buttons are pictured in the first image of this post, the route /wifi (very suggestive) is the important one now, it leads to the config page. 

Now knowing that the route that I was looking for is /wifi (192.168.4.1/wifi), I did the same process to get pages information and find the route to post the credentials and to configure the WiFi. Here is the result:

The colors represent:

• Green: input that receive the network ssid;
• Purple: input that receive the network password;
  
• Blue: method and route to send this information.

So the conclusion was that two parameters were send with the names s and p, all that I needed to do was send the same POST request while connected to the server (ESP) and block the webportal that always open when I just connect to the ESP access point. The final POST request is:

curl -X POST -d "s=MySSID&p=MyPassword" http://192.168.4.1/wifisave

Like mentioned, the WiFiManager library has a lot of parameters that are usual to: set access point name, timeout, customize settings and a lot of others options. Resuming, the library also has an option to not open automatically the webportal, that was a great solution (you can see more at WiFiManager.h). 

Unfortunately, for some cell phones, this bool option to disable this interface did not worked, especially for older Android versions, it is necessary to explore another options for those cases. For tests you can use curl or some application like Insomnia that will simulate a request. For Insomnia you can check the configuration below, changing the POST type to Multipart Form.

Conclusion

Understanding how WiFiManager works made it easier to implements a solution making small changes in the code. Yes, it is possible set WiFi connection not using this library, but it is very nice to use something already tested, functional and that is maintained. This code was used for an ESP32 microcontroller in an IoT application. After that I also utilize the /update route to do OTA updates (spoiler: without to use a server or SBCs), but is something to another post.