mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #705] Auto connect after boot using already saved credentials #590
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#590
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @laercionit on GitHub (Aug 22, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/705
Hello
First congratulations for LIB.
I recently upgraded to the latest version and realized a change that had a big impact.
If I have a power outage, NodeMCU usually starts faster than the router.
This means that the nodemcu will enter AP mode to enter the captive portal until it has the timeout.
In the old days the nodemcu continued to try to connect to the wifi network with the last settings saved.
For some reason I have not been able to track this, it does not happen anymore. When it enters the AP mode by initiating the captive portal, the Wifi settings are lost even if the save does not occur.
@laercionit commented on GitHub (Aug 22, 2018):
Analyzing the LIB that generated this loss of functionality to continue trying to connect to the wifi using the credentials saved after the timeout of the captive portal was the code below.
I commented the change and the code behavior returned to normal.
It keeps trying to connect to the wifi after the timeout of the captive portal
// if(!WiFi.isConnected()){
// WiFi.persistent(false);
// // disconnect sta, start ap
// WiFi.disconnect(); // this alone is not enough to stop the autoconnecter
// WiFi.mode(WIFI_AP);
// WiFi.persistent(true);
// }
// else {
//setup AP
WiFi.mode(WIFI_AP_STA);
DEBUG_WM(F("SET AP STA"));
// }
@tablatronix commented on GitHub (Aug 22, 2018):
Hmm the settings should not be erased, not even sure how they would be.
@tablatronix commented on GitHub (Aug 22, 2018):
The settings are not lost, sta mode is disabled, ill add abilty to turn that off, but it was changed because ap mode will not work when sta is disconnected.
Your best option for this is to not enter straight into autoconnect, but wait for wifi, or increase wm connect timeout
@laercionit commented on GitHub (Aug 22, 2018):
But in my code I have to enter STA.
It still does not connect again without commenting on the code in LIB.
Any suggestion?
wifiManager.setTimeout(NetworkConfigTimeOut);
wifiManager.setAPCallback(NetworkConfigMode);
if (!wifiManager.autoConnect(NetworkDefaultSSID, NetworkDefaultPassword)) {
if (DebugCheck(Error)) DebugSerial.println F("NetworkInit: Failed to connect WiFi or Timeout");
LedWifiStop();
return;
} else {
if (DebugCheck(Info)) DebugSerial.println F("NetworkInit: WiFi Connected!");
LedWifiStop();
}
WiFi.persistent(true);
WiFi.mode(WIFI_STA);
WiFi.setAutoConnect(true);
WiFi.setAutoReconnect(true);
WiFi.hostname(System.Hostname);
@laercionit commented on GitHub (Aug 22, 2018):
The problem was the return, but I think this change would be appropriate:
As timeout occurs, it continues as AP mode indefinitely, I believe we should take some action at the timeout.
//Ajuste Lib
// check if timeout
if(configPortalHasTimeout()){
WiFi.mode(WIFI_STA);
break;
}
//my code:
void NetworkInit() {
WiFiManager wifiManager;
WiFi.persistent(true);
WiFi.setAutoConnect(true);
WiFi.setAutoReconnect(true);
WiFi.hostname(System.Hostname);
if (DebugCheck(Debug)) DebugSerial.println F("NetworkInit: Network inicialization");
wifiManager.setTimeout(NetworkConfigTimeOut);
wifiManager.setAPCallback(NetworkConfigMode);
if (!wifiManager.autoConnect(NetworkDefaultSSID, NetworkDefaultPassword)) {
if (DebugCheck(Error)) DebugSerial.println F("NetworkInit: Failed to connect WiFi or Timeout");
LedWifiStop();
return;
} else {
if (DebugCheck(Info)) DebugSerial.println F("NetworkInit: WiFi Connected!");
LedWifiStop();
}
Waiting();
NetworkShowHostname();
NetworkShowIP();
NetworkShowIPAP();
NetworkShowMAC();
NetworkShowGTW();
NetworkShowDNS();
NetworkMonitor(true);//CheckWifi
NetworkMonitor(true);//CheckInternet
}
@laercionit commented on GitHub (Aug 22, 2018):
One question, if the Wifi is in AP_STA mode should it keep trying to connect to the wifi with the saved credentials or does it just work with STA mode?
@tablatronix commented on GitHub (Aug 22, 2018):
It should
@tablatronix commented on GitHub (Aug 22, 2018):
I am looking into forcing startap on same channel as sta, so that it remains stable and leaving sta on.
Still testing to see if it fixes the stability issues.
The best option for now is to wait for router to come up based on reset reason , use configportal timeout and fall back to sketch to reconnect, or reboot.
(development branch only)
@laercionit commented on GitHub (Aug 22, 2018):
Unfortunately for AP_STA it is not reconnecting and my timeout setting did not work, either. I'll keep the LIB code commented until we have another solution.
For me it is important to ensure that the equipment maintains the connection attempt after the timeout. This ensures that regardless of the power outage or any problem with the Wifi, as soon as the router is resolved the nodemcu will connect.
@tablatronix commented on GitHub (Aug 22, 2018):
How long does it take your router to come up?
@laercionit commented on GitHub (Aug 22, 2018):
Hello my friend....
The question is not the time of the router.
Basically if there is an electrical network failure, or even a router
fault, I wish the nodemcu to continue trying to connect to the network
using the last credentials it has. As soon as the wifi router comes back
on, the nodemcu will connect. I do not want to limit time for this, it's
basically a failover logic.
Em qua, 22 de ago de 2018 às 09:00, Shawn A notifications@github.com
escreveu:
@tablatronix commented on GitHub (Aug 22, 2018):
In your testing how long does it take the router to come back up?
@laercionit commented on GitHub (Aug 22, 2018):
Usually 40 seconds, but as I mentioned, I do not believe the best way is to
put a greater timeout for autoconnect.
I think the nodemcu should always keep trying to connect with the
credentials it has.
Laercio Junior
Cel./Pessoal: (21) 99162-7440
Email Pessoal: laercionit@gmail.com
Skype: laercionit
Em qua, 22 de ago de 2018 às 11:26, Shawn A notifications@github.com
escreveu:
@tablatronix commented on GitHub (Aug 23, 2018):
#706