Home

WiFiManager vs WiFiSettings: Why I reinvented the wheel

The Arduino library WiFiManager works with the ESP8266, and in an upcoming version will also support the ESP32 (currently available in the development branch). It has become the de facto standard for configuring WiFi on ESP8266 devices in the Arduino ecosystem.

WiFiManager is very popular, and clearly meets the needs of a vast user base. But I had a wish list of things that I would like to see before using it (not just ESP32 support), and with already more than 300 open issues and over 30 open pull requests it didn't feel like the developer could devote that much attention. I also couldn't quickly find a good alternative, but was in a hurry because we had a project to finish. So I wrote my own. Originally as a hastily written part of the Decennium badge code, but that later as a reusable library, WiFiSettings.

My wish list consisted of the following features:

• A way to get around hard coding passwords. I want to share my code. If source code contains passwords, sharing it online becomes a security nightmare. Instead I wanted the configuration portal to be secured with a password that can be configured in the portal itself. For the aforementioned Decennium badge, which doesn't have USB serial hardware, nor a display to show the password, I wanted something that would start with an insecure access point, which becomes secure only after the user has enabled that. The alternative with WiFiManager would be to give everyone the same password, and explain to users how to rebuild the project and upload it as an OTA update. Configuring through insecure WiFi paradoxically seemed much more secure, especially if you can then enable the security by checking a checkbox after you've seen (or chosen) the password.
• More than just strings, e.g. booleans and integers. WiFiManager only has built-in support for strings, so no HTML checkboxes or HTML5 numeric inputs. It lets you use custom HTML, but that's a lot of work and makes your Arduino sketch a mess with HTML in it, so in practice you see everyone still using strings for things like TCP port numbers. WiFiSettings is much less flexible, but does make it really easy to do these things out of the box, with a single line of code per parameter.
• Defaults that don't promote themselves to stored values. When a newer version has a different default setting, users who have been using an older version will keep the defaults forever just because they used the configuration page once. There is something to be said for that, but I wanted to default at runtime instead. (Note that with WiFiSettings, checkboxes do promote their default values to stored values, because HTML checkboxes are limited.)
• Default values shown in the form elements. Users experiment with values and maybe want to go back to the initial setting at some point, so the portal should show what the default was. WiFiManager uses the placeholder attribute for the name of the field, but I prefer to use it for indicating the default that you get by leaving the field empty. Because of this, WiFiSettings puts the name of the field (or the label) next to the input box, which I happen to prefer too.
• Built-in storage for all settings, not just the WiFi credentials. With WiFiManager, "You are responsible for saving and loading these custom values. The library just collects and displays the data for you as a convenience", but with WiFiSettings, the convenience extends to taking care of saving and loading these values on the SPIFFS (SPI Flash FileSystem). This does have consequences: WiFiSettings litters your SPIFFS root directory with tiny files and does not provide any alternative way of storing the settings.
• Less code. Both in my sketches and in the library itself, I like a more minimalist approach to programming. WiFiSettings is approximately 10% of the size of WiFiManager's development branch.

Because I don't use ESP8266 for new projects anymore, I could simply implement something for the ESP32 without having to deal with the limitations of the older chip. WiFiSettings originally did not support ESP8266, but a port was contributed and merged as version 3.0.0.

But note that WiFiManager has several features that WifiSettings does not have, and might never get. So you can't just say that one is better than the other. They're different, and you will have to choose based on your own criteria.

Comparing memory usage

With the basic use case (no custom parameters), WiFiSettings uses approximately 20 kB less program storage space, and 5kB more RAM in the main loop() of the sketch than WiFiManager. With the same thing, but adding two string parameters in the documented way, WiFiSettings uses 55 kB less program storage space, and 0.5 kB more RAM in the main loop() of the sketch, compared to WiFiManager.