mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #706] background sta connect, reconnect to saved ap on power failure #589
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#589
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 @tablatronix on GitHub (Aug 22, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/706
There is an issue with short lapses in connectivity and especially power failures that need a special handling to deal with either by the user or the library.
Ideally we would fire up the softap and leave sta on to connect, if status is connected we can abort the configportal automatically or after a timeout.
The problem with this is having a non connected sta makes softap unstable if not completely unusable. The theory is that the channel scanning autoconnect does makes the softap drop clients.
With this in mind there are a few options to resolve this.
Library
User
It depends on user case, but If there is a saved credential, the odds of a power failure is higher than reconfigure of credentials. So waiting a minute for the router before starting configportal is a practical solution, also using an ondemand configportal removes this issue entirely.
Another options is to use some state tracking, if the last reboot was pwr, and last status was connected and time since last reboot is x, odds are router is rebooting...
A good option might be to fire a callout if saved ap found while cp is running.. and let user do whatever, stopconfigportal or restart esp.
@tablatronix commented on GitHub (Aug 23, 2018):
added several private options for testing this
@aburst42 commented on GitHub (Jan 18, 2019):
I am encountering the same issue.
The current code seems to do something very close to the desired functionality, except it leaves the STA up while also serving the soft AP, which seems to interfere with the next attempt to run the chip in STA mode. Would love to see a solution to this that follows the description above:
"[when attempting manual resolution] stop sta, start ap, do background scans for ap, if default ap is found in scan, restart sta snd try to connect, abort softap on result."
In a nutshell, the desire is for an ReconnectWiFi function on the WifiManager, which attempts three steps, in sequence:
0. If (WiFi.status()==WL_CONNECTED), all is good - return true. Otherwise, proceed to 1
The user could then write this in their loop() function:
void loop() {
if (wifiManager.ReconnectWiFi(AP_SSID, AP_PWD)) {
// WiFi connection is ready for use.
}
}
This would allow very robust self-healing (by repeating step 1) as well as manual healing (by repeating step 2) any time an interruption occurs, be it transient (power outage, AP reboot, etc.), or permanent (SSID change, password change, security mode change, etc.)
Happy to help test a solution through:
Thanks!
Cheers,
~alex
@tablatronix commented on GitHub (Jan 18, 2019):
that is literally what I posted above...
all those features can be done now by user code, or autoconnect without cp
Except the background scan for home ap, this might be in the next version, but there are ways to do it now already
@aburst42 commented on GitHub (Jan 18, 2019):
Thank you for the quick reply, Shawn!
I feel like I'm missing something... I wrote the trivially simple sketch below... I let the board connect to WiFi (with saved credentials), then I turned off the wireless network. Predictably, after a few seconds, the board lost connectivity and started serving the captive portal. I then turned the wireless network back on and, although the board continued to cycle between trying to connect to WiFi and serving the captive portal, it was never able to reconnect to WiFi. When I physically reset the board, it connected to WiFi in a couple of seconds.
What is your recommendation for changing the sketch below without: 1. Losing most of the benefits of using the WiFiManager class and 2. Repeatedly powercycling the board (can't be good for it over the long term...)
#include <ESP8266WiFi.h>
//needed for library
#include <DNSServer.h>
#include <ESP8266WebServer.h>
#include <WiFiManager.h>
#include <ArduinoOTA.h>
void setup() {
}
const unsigned long CONNECT_TIMEOUT = 180; // Wait 3 minutes to connect to the real AP before trying to boot the local AP
const unsigned long AP_TIMEOUT = 180; // Wait 3 minutes in the config portal before trying again the original WiFi creds
const char* AP_SSID = "ARDUINO"; // Create an access point with this SSID
const char* AP_PWD = "CONFIGURE"; // Protected the access point with this password
bool EnsureWiFi() {
if (WiFi.status() != WL_CONNECTED) {
WiFiManager wifiManager;
}
return (WiFi.status() == WL_CONNECTED);
}
void loop() {
if (EnsureWiFi()) {
// WiFi connection is ready
}
}
@tablatronix commented on GitHub (Jan 18, 2019):
what branch are you using ?
@aburst42 commented on GitHub (Jan 18, 2019):
The one that the Arduino Studio library manager installs automatically (version appears to be 0.14.0) (see attached screenshot). Should I be using a different, manually installed one?
@aburst42 commented on GitHub (Jan 18, 2019):
Also... If scanning for APs is what's causing the issues, I would gladly trade that (i.e. type the ssid/password in a text box, rather than selecting it) in order to have rock solid auto-recovery when possible.
@tablatronix commented on GitHub (Jan 18, 2019):
Yeah no support or development is being done on anything but development branch
@aburst42 commented on GitHub (Jan 18, 2019):
Got it. I'll clone from https://github.com/tzapu/WiFiManager/tree/development and report back with the results. Thanks!
@tablatronix commented on GitHub (Jan 18, 2019):
hopefully this is a known issue and already fixed, but let me know
@aburst42 commented on GitHub (Jan 20, 2019):
I am very happy to report that it worked exactly as intended. Also, I noticed that the behavior that enables this library to work as expected is much more sophisticated than it was on the master branch - thank you for improving the code and making it work for my scenario!
@tablatronix commented on GitHub (Jan 20, 2019):
yeah it still needs to be documented and examples cleaned up, that is mostly why it is not beta yet
@alvaroaguero55 commented on GitHub (Aug 11, 2019):
Still same issue with latest versión?
@tablatronix commented on GitHub (Aug 11, 2019):
yes there has not been a release since this, use development branch
@alvaroaguero55 commented on GitHub (Aug 11, 2019):
Which is the link of the working development branch?
@Bolukan commented on GitHub (Oct 7, 2019):
Suggestion to the opening post: If the server gets a client request via the AP, disconnect STA for some time (so AP-only mode). Maybe like a watchdog counter (each server-request reset time counter). Maybe even a client connection (before the page-request) may activate this behaviour.
@tablatronix commented on GitHub (Oct 7, 2019):
@Bolukan it is worth testing, But the main problem is the ap can be entirely unstable when sta is trying to connect, but it would be nice to find a stable solution to background connecting, ideally users can just use non blocking and make their own logic, this can probably be POC in user code atm using events or
WiFi_softap_num_stations,I am not even sure you can enablesta when in ap atm without it breaking something..
@Bolukan commented on GitHub (Nov 16, 2019):
I am aware of the lack of progress. It was quiet timeconsuming (wiping, downloading and analysuing flashes) but bottom-line too difficult for me to create reproducable testcases.
@tablatronix commented on GitHub (Nov 16, 2019):
This is not something I will look into until next version
@Jhonathaned commented on GitHub (Jan 22, 2020):
Any progress on this? I have the very same issue reported here #738.
I want to use "AutoConnect" on setup, so It will run once on boot, so lets suppose that It failed to connect to the saved credentials, and that the ConfigPortalTimeout was hit: Now I need It trying to reconnect to saved credentials forever, but It doesn't do that, 'cause when I start up my router/AP, it simply doesn't connect.
When disconnected, I cannot call the "AutoConnect" function again in the loop because it will enter on AP mode, and the really problem of it is that it stucks the code, as it is using an "while(1)" inside library. The code being stuck is a real problem for me, as I am using the NRF24Mesh library, which needs to have its "mesh.update()" function cycled in loop, otherwise it will not keep my mesh network up.
I'm using the latest library version provided by the Arduino IDE's library manager.
I would really appreciate any kind of help.
@ftaibi commented on GitHub (Sep 8, 2020):
Hi @aburst42
I have tried your solution and does not work for me. Any idea why?
After losing the wifi connection switch to AP but I turn the wifi on again and does not reconnect.
Cheers
@alexburs commented on GitHub (Sep 11, 2020):
Hi @ftaibi,
Unfortunately, I don't know why the solution wouldn't work for you. I included below the full code of my garage controller. Beyond staying connected to WiFi through power outages and such, it doesn't do much - it just sets a pin to activate the garage door. Maybe give it a go on your Arduino with a copy of WifiManager from the development branch?