Captive Portal for ESP32 that can connect to a saved wireless network or start an access point where you can connect to existing wifis.
v3.3.1 is a bug fix update to esp32-wifi-manager v3.3
v3.3 is a minor update to esp32-wifi-manager v3.x The main change is the addition of nvs_sync.h which provides mutex mechanism for accessing the NVS. esp32-wifi-manager accesses the NVS to load/save the current configuration but there is no guarantee that it conflicts with user code trying to access NVS at the same time. You can now call nvs_sync_lock / nvs_sync_unlock before calling nvs_open / nvs_close to make sure this concurrent access never happens.
v3.2 is a minor update to esp32-wifi-manager v3.x It is now possible to relocate the wifi manager to a different URL. So far, esp32-wifi-manager was always opening at http://xxx.xxx.xxx.xxx/, and it is now possible to move it to an imaginary folder, such as http://xxx.xxx.xxx.xxx/wifimanager/ This will help a lot if you need to have the wifi manager out of the way of your main application. The README page has been updated to reflect this new functionality.
If you are updating esp32-wifi-manager from a previous clone, please note that you should run a fullclean (i.e. run the command esp.py fullclean or delete your build folder) before compiling your project. If you don't, the linker will throw some errors related to http_server which no longer exists -- see below.
The software is now fully compatible with esp-idf 4.1+. The tradeoff is that support for esp8266 had to be dropped; and that esp32-wifi-manager will no longer compile on esp-idf 3.x due to breaking changes between these versions.
This is also the first release as an esp-idf component with cmake support, although the master tree has had these features for a while now.
This version of the wifi manager is a complete re-write of the way events are handled, hence v2.0. v1.x used event groups exclusively which lead to a very hard to maintain architecture and I could not implement all the features I wanted without breaking code elsewhere.
This version 2.0 uses a queue and processes messages and events this way. It is without a doubt incredibly more versatile. As a results, a lot of the behaviour issues of the wifi manager simply solved themselves by the change of architecture.
First version!
The first version is finally here! I spent over 8h debugging issues with the iPhone browser. Weird behaviours like caching POST requests, dropping characters in headers or simply sending some requests at all... I had to completely rebuild the authentication process to a wifi because of this pile of crap. I almost certainly lost hair in the process. But hey! It works!
Second release candidate!
The app works flawlessly with PC and Android as far as I can tell, but there's an issue with the iPhone's webkit where sometimes the "connect" button doesn't want to work. Until it is fixed, I leave this release as a RC and not the first true 1.0 version.