khoih-prog / ESP_WiFiManager

This is an ESP32 / ESP8266 WiFi Connection Manager with fallback web configuration portal. Use this library for configuring ESP32 (including ESP32-S2 and ESP32-C3), ESP8266 modules' WiFi, etc. Credentials at runtime. You can also specify static DNS servers, personalized HostName, fixed or random AP WiFi channel. With examples supporting ArduinoJson
MIT License
371 stars 97 forks source link

AutoConnectWithFSParameters not relaunching AP #50

Closed CptRolinho closed 3 years ago

CptRolinho commented 3 years ago

Following the AutoConnectWithFSParameters example, after moving the device from a known to an unknown WiFi, the device sees the previously stored connection but does not relaunch the AP feature

khoih-prog commented 3 years ago

Please first read the How to create a Minimal, Reproducible Example, and at least post the clearer explanation, along with the debug terminal output to demonstrate the problem.

I'll reopen the issue after being convinced there is a bug.

CptRolinho commented 3 years ago

Sorry and thank you for the heads up.

So I'm following the AutoConnectWithFSParameters example, so I won't post the full code. My only change from the example is from this

//set custom ip for portal
  ESP_wifiManager.setAPStaticIPConfig(IPAddress(192, 168, 100, 1), IPAddress(192, 168, 100, 1), IPAddress(255, 255, 255, 0));

to this

//set custom ip for portal
//ESP_wifiManager.setAPStaticIPConfig(IPAddress(192, 168, 100, 1), IPAddress(192, 168, 100, 1), IPAddress(255, 255, 255, 0));

on lines 651 and 652 of the example. I've found that this change enables the captive portal to show automatically. I've tried this issue with both cases.

I've built and uploaded the example to an ESP32 DevKitC through Platformio on VSC. It run as supposed and through the captive portal I provisioned the WiFi SSID and Password to the device. I've now powered the device away from the original network and it didn't create an Access Point to relaunch the captive portal. My understanding of the library and example is that the WiFi Manager should relaunch the configuration portal when no matching WiFi is found. Or am I wrong?

The Serial debug that follows is copied from the VSC terminal.

Starting AutoConnectWithFSParams using LittleFS on Espressif ESP32 Dev Module
ESP_WiFiManager Version v1.3.0
Mounting FS...
Mounted file system
Reading config file
Opened config file, size = 183

JSON parseObject() result : OK
[WM] RFC925 Hostname = AutoConnect-FSParams
[WM] Adding parameter blynk_server
[WM] Adding parameter blynk_port
[WM] Adding parameter blynk_token
[WM] Adding parameter mqtt_server
[WM] Adding parameter mqtt_port
[WM] setAPStaticIPConfig
[WM] setSTAStaticIPConfig for USE_CONFIGURABLE_DNS
[WM] Set CORS Header to :  Your Access-Control-Allow-Origin

Stored: SSID = ########, Pass = ########
Got stored Credentials. Timeout 120s
[WM] LoadWiFiCfgFile
[WM] OK
[WM] * Add SSID =  ######## , PW =  ########
ConnectMultiWiFi in setup
[WM] ConnectMultiWiFi with :
[WM] * Flash-stored Router_SSID =  ######## , Router_Pass =  ########
[WM] * Additional SSID =  ######## , PW =  ########
[WM] Connecting MultiWifi...
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[WM] WiFi not connected
After waiting 29.88 secs more in setup(), connection result is WL_DISCONNECTED
Local IP = ########
[WM] freeing allocated params!

WiFi lost. Call connectMultiWiFi in loop
[WM] ConnectMultiWiFi with :
[WM] * Flash-stored Router_SSID =  ######## , Router_Pass =  ########
[WM] * Additional SSID =  ######## , PW =  ########
[WM] Connecting MultiWifi...
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[E][WiFiMulti.cpp:191] run(): [WIFI] no matching wifi found!
[WM] WiFi not connected
F
WiFi lost. Call connectMultiWiFi in loop
khoih-prog commented 3 years ago

Thanks for the more detailed info that helps understand your issue.

From v1.4.2, the behaviour of the AutoConnect-related examples has been changed to accommodate the more important feature as mentioned in ESP8266 Clear SSID and Pass #33.

The FS-stored WiFi Credentials will have similar priority as the temporarily ESP Self-Stored Credentials. That's means the system will

  1. Try to connect to known and existing WiFi APs by checking ESP Self-Stored Credentials
  2. If not, Load FS-stored Credentials and try to connect, <=== this is what you're experiencing
  3. if still not OK, Launch Config Portal

This is totally controlled inside the examples, you can change the behaviour as you'd like, provided you're aware of the consequences. For example, comment out these following lines

else if (loadConfigData())
{
  configDataLoaded = true;

  ESP_wifiManager.setConfigPortalTimeout(120); //If no access point name has been previously entered disable timeout.
  Serial.println(F("Got stored Credentials. Timeout 120s for Config Portal")); 
}

It's suggested that you use the other examples to have full control of the Config Portal, such as

  1. ConfigOnDoubleReset
  2. ConfigOnStartup
  3. ConfigOnSwitchFS

and many more, so that you can force the Config Portal by DoubleResetting or pressing a Switch whenever you''d like. For example, in your situation when moving to a new location with completely new AP SSISs, etc.

Good Luck,