Saved WiFi credentials takes a excessive time to reconnect after power cycle (possible red herring) #555
Replies: 8 comments 7 replies
-
|
Below are a few debug logs for comparison. 1. First run with a blank ESP8266. Launches a portal, allows me to configure my local IP/Netmask/Gateway/DNS, connects to my local router WiFi network and saves the credentials, followed by me performing a reset by clicking on the Reset button within the portal. All looks OK: 2. Following a hard reset. For some reason the first 3. Double reset to force immediate rise of portal. In this case I didn't bother connecting to the raised AP and just pushed the ESP reset button a few moments later. On restart from this condition the |
Beta Was this translation helpful? Give feedback.
-
|
@ac1176 Thank you for the detailed log and preliminary diagnosis. As you mentioned, this behavior is unexpected. If persistent is enabled, WiFi.begin() should save the current configuration information within the SDK. But AutoConnect/src/AutoConnectCoreImpl.hpp Lines 434 to 437 in 80594fa A possible cause of this phenomenon is that the WiFi module equiped on ESP8266 is not awake when returning from DeepSleep. I think that giving WAKE_RF_DEFAULT to the second argument of Refs: Also regarding the procedure suggested in above issue topic, this looks essentially the same as calling Related: AutoConnect/src/AutoConnectCoreImpl.hpp Lines 102 to 105 in 80594fa |
Beta Was this translation helpful? Give feedback.
-
Hmmm....Are we talking about the same issue here? The situation I am seeing is that WiFi STA connection from a hard reset/cold boot is slow and WiFi STA connection after deep sleep is quick. The link/procedure you provide seems to describe the opposite - that WiFi connection on cold boot/hard reset is quick, but WiFi reconnection following a deep sleep is slow (or not working at all). The second AC log I listed, above, is only a partial extract of what was occurring. I actually left it running for several minutes and after every deep sleep the WiFi STA reconnection time was consistently <400 milliseconds. It appears the Indeed, I've had an ESP8266 next to me for the last 10 minutes or so while I've been typing this running the above code and the log seems to replicate this: Notice how the first 'Connecting to WiFi' statement (following initial power-up) takes one timeout and an autoConnect 15+ seconds to complete. Every subsequent WiFi reconnection (except the third one, which I'm willing to bet was due to weak WiFi signal from my router) is <350 milliseconds. |
Beta Was this translation helpful? Give feedback.
-
|
Let me get this straight. I have organized the following, quoting your comments.
STA configuration data that should have been saved by the ESP8266 SDK is missing. But AutoConnect rescued it by autoReconnect. My comment on this phenomenon. ESP8266 SDK is behaving unexpectedly for me. AutoConnect does not participate in the configuration restore process used for 1st-WiFi.begin(). The SDK does that on its own. However, that configuration was saved to EEPROM (It's different from AutoConnectCredentialst) by the SDK when
Because of the above-mentioned failures. The following things you mention look to me like a phenomenon caused by the absence of the "SDK configuration that should be present" required for the 1st-WiFi.begin().
No problem. This is the correct behavior of AutoConnect.
I am not sure about this. To me, it looks like the time it took My diagnosticsUsing with WiFi.disconnect(true)This reproduces the problem by intentionally doing The sketch used#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
#include <AutoConnect.h>
#include "DoubleResetDetector.h"
ESP8266WebServer server;
AutoConnect portal(server);
AutoConnectConfig config;
// Double reset recognizing criteria in ms.
#define DRD_TERM 2
DoubleResetDetector drd(DRD_TERM, 0);
// uint64_t _sleepInterval = 3600ULL * 1000ULL * 1000ULL; // 1-hour.
uint64_t _sleepInterval = 15ULL * 1000ULL * 1000ULL; // 15 sec.
bool _wakeUp;
void CONNECT_MQTT(void) {}
void MEASURE_SENSORS(void) {}
void PUBLISH_MQTT(void) {}
void DISCONNECT_MQTT(void) {}
// The exit called repeatedly while in the WiFi connection attempting.
bool onConnecting() {
drd.loop();
return true;
}
void setup() {
// Get the reset reason
_wakeUp = !drd.detectDoubleReset();
pinMode(D0, WAKEUP_PULLUP);
Serial.begin(115200);
delay(100);
Serial.println();
if (!_wakeUp) {
// Here is the double-reset phase.
// It ensures the captive portal launching immediately
// and ignores the 1st-WiFi.begin().
// This intentionally launches a captive portal, but of course, you could
// choose to have AutoConnect's normal behavior. (i.e. enable the 1-st WiFi.begin)
Serial.println("Double reset detected");
config.immediateStart = true;
}
else {
// Constant periodic operation.
Serial.println("Wake-up");
config.autoReconnect = true;
}
// Allow using the AutoConnect menu to sleep.
server.on("/sleep", [] {
server.send(200, "text/plain", "Going to sleep");
_wakeUp = true;
});
portal.append("/sleep", "Sleep");
portal.config(config);
portal.whileConnecting(onConnecting);
// To ensure double reset detection, it may be better to add a delay here.
// But battery consumption will increase.
// delay(1000);
portal.begin();
if (WiFi.status() == WL_CONNECTED) {
if (_wakeUp) {
// Here is the one-shot measurement.
// Following external functions are pseudo.
// It will be implemented according to the actual scenes.
CONNECT_MQTT();
MEASURE_SENSORS();
PUBLISH_MQTT();
DISCONNECT_MQTT();
}
}
}
void loop() {
if (_wakeUp) {
server.client().flush();
Serial.println("Going to sleep");
// Measure with one shot and goes to sleep again.
// Erase the saved config by SDK
WiFi.disconnect(true);
while (WiFi.status() == WL_CONNECTED)
delay(10);
ESP.deepSleep(_sleepInterval, WAKE_RF_DEFAULT);
delay(1000);
}
portal.handleClient();
drd.loop();
}Correct behaviorExcluded WiFi.disconnect(true) from the loop function in the above sketch. void loop() {
if (_wakeUp) {
server.client().flush();
Serial.println("Going to sleep");
// Measure with one shot and goes to sleep again.
ESP.deepSleep(_sleepInterval, WAKE_RF_DEFAULT);
delay(1000);
}
portal.handleClient();
drd.loop();
}As a result, it's normal. |
Beta Was this translation helpful? Give feedback.
-
|
I reviewed the conditions for the connection waiting of 1st-WiFi.begin. Omit to wait for connecting if no available SSID is stored. It doesn't solve the root of the problem, but it makes things a little better. |
Beta Was this translation helpful? Give feedback.
-
OK, I understand now - thankyou. Could AutoConnect perhaps take more control of the first
Only from the reported times it took to connect to WiFi on each cycle in my logs. If we discount the first power-on log, as it includes the 10 second timeout trying to find the (missing? invalid?) SDK-stored WiFi credentials then the 'rescued' time, as you put it, is only 5 seconds which is more reasonable. Maybe the slightly longer (5 Sec vs <350 mSec) is due to my WiFi router being at the other end of the house, or perhaps it's changing channels and forcing the ESP8266 to do a channel re-scan. |
Beta Was this translation helpful? Give feedback.
-
|
The more I play with the DRD, the more I think this issue is unrelated to a cold boot.
Because the DRD is occasionally being mis-triggered (I still have to try out your What is the default behaviour of AutoConnect if an AP is raised after credentials have previously been set up in the portal? Is AutoConnect perhaps expecting the user to take advantage of the portal when it's raised, and either configure a new set of credentials or manually select a previously saved set of credentials in the 'OpenSSIDs' tab? If the user does neither does AutoConnect perhaps unexpectedly erase the previously-working SDK WiFi credentials, similar to doing a As an experiment, I tried modifying my test code to remove all references to the DRD. In this new version the portal is only raised if there are no saved credentials. I can't fault it no matter how many times I reset, deep sleep or reboot the ESP8266. Reconnection to the last known WiFi STA is always fast, and it never times out or has to |
Beta Was this translation helpful? Give feedback.
-
AutoConnect::begin performs STA disconnection ( Maybe it was because when I did a detailed preliminary investigation of the behavior of the ESP8266 Arduino Core before implementing AutoConnect, I found that the WiFi mode transition from STA to AP_STA did not work without performing a disconnect from the STA....I can't remember for a moment. So, in the following logic sequence that graphed AutoConnect::begin, a red-painted step is a problem in this case.
Solution ProposalSo, I have a plan. bool AutoConnectConfig::keepSTAConfigTo tell the truth, this option is not perfect, also its name is not appropriate. If the user tries to connect to an AP other than the one memorized by SDK, the previous STA configuration will be lost from the SDK memory. The A situation where this option can be applied is the "I started a captive portal, but changed my mind and quit after all" case. Is this common? On the other hand, Honestly, I have no idea how useful AutoConnectConfig::keepSTAConfig is. How about you? |
Beta Was this translation helpful? Give feedback.
-
OK - I can confirm that change appears to work, thankyou :) But I agree with you, that it's kind of masking the issue of 'lost' SDK WiFi credentials. |
Beta Was this translation helpful? Give feedback.
-
Ah - yes, I can see now why I'm losing my credentials on an
Probably not that particular case. I'm thinking more of situations where the portal might be raised on demand, but not for the purpose of setting/changing WiFi STA credentials. For example, my device has MQTT settings that are made using a custom page inside the portal. The user may need to change them at some point after the device is deployed (maybe the MQTT server details need to be adjusted?), and in that situation because the WiFi credentials hadn't been modified the device should just resume connecting using the saved WiFi credentials after the portal is closed and/or the ESP rebooted.
I'm not sure. What would happen if the library simply didn't have that red-painted step at all? Is there a need to |
Beta Was this translation helpful? Give feedback.
-
|
Accessing the ESP8266 in standalone situation (SoftAP only) for user-specific application configuration is a common situation. I'm aware of this. But, it is not the same thing as having the SDK maintain the STA configuration. The ESP8266 RF module has only one entity: can it respond to connection requests to SoftAP from other client devices while a connection request to the outside AP is in progress? My understanding is that ESP8266 cannot do that. I thought the only thing that can stop If you activate SoftAP but do not release the RF module from the STA connection attempt state, SoftAP should not be able to negotiate connection requests from client devices. Therefore, a prior WiFI.disconnect is required to activate SoftAP. Am I wrong? The autoReconnect rescues this situation and restores the previous STA connection. |
Beta Was this translation helpful? Give feedback.
-
What happens if you use
No, you're probably right. As I mentioned earlier, my C++ skills and detailed understanding of the WiFi SDK are only just above 'basic', so I'm more guided by you as to the correct operation of it. I guess my only other query would be if we can't avoid using |
Beta Was this translation helpful? Give feedback.
-
Since it is the persistent mode, I think the current STA configuration memorized by SDK will probably be kept. Changing I think maybe the best solution is for AutoConnect will fallback to SDK memorized STA configuration on its own accord if WiFi.begin() fails. That is exactly what you mentioned and this is probably the best solution for your situation. I think it could be implemented by directly handling the Even in that case, however, we are still required to carefully consider the specifications. On the other hand, the current AutoConnect specification is; Once the captive portal is opened, the previously memorized SDK configuration is lost and a new configuration begins. If you want to recover past connections to the AP, AutoConnectConfig::autoReconnect will do that. It is a simple and straightforward condition. It frees the user from the hidden memorized information that the SDK does. |
Beta Was this translation helpful? Give feedback.
-
Understood. Let's not over-complicate things at this stage then. I'm currently happy that AutoConnect operates well enough in my situation that there's no pressing need for further adjustments under the hood to the library. Thank you again for providing technical support and assistance with regards to my queries for AutoConnect. Could I offer anything in return for your help? Maybe provide assistance with documentation or make a donation to the project? |
Beta Was this translation helpful? Give feedback.
-
|
Libraries gain significance by being used by more people. While AutoConnect is multifunctional, it is larger and has a little higher API complexity than frequent Arduino libraries, making it more difficult for users who are not familiar with programming. Therefore, there will be limited situations in which you can benefit from using AutoConnect. In the course of further AutoConnect enhancements, I will have limited opportunities to fully examine various use cases. There is a limit to one person's imagination. AutoConnect's utilization accuracy will increase if I can get your advice in such situations. I will have the opportunity to inform you through discussions on various topics from now on. Please lend me your insights at that time. AutoConnect v1.4.2 including the Thank you for your contribution. |
Beta Was this translation helpful? Give feedback.
-
Split off from another discussion here...
I think the issue I've been seeing is related to the Double Reset Detector and the way I'm using AutoConnect when I'm detecting the double reset.
In my setup I'm doing the following in an attempt to speed up the display of the Config Portal when the double reset occurs:
I think what is happening is that if the double reset is detected (or is falsely triggered by a power cycle), the first branch of the
ifstatement is performed and the config portal is raised through the AP 172.217.28.1 waiting for me to connect to it. Obviously in this situation if I wasn't expecting this it looks like ESP8266 has not connected to the STA and everything halts inportal.begin(). If I reset it again and get it to not detect a double reset theelsecomponent of the setup is performed and WiFi connects to STA as expected, but takes much longer to re-connect (15 sec instead of 300 millisec).For what it's worth, my stripped-down code for the above phenomena is below. The idea is that if a blank ESP is run it checks if any credentials are already saved. If none are found it immediately raises an AP so the user can configure it. I then enter my WiFi details in the portal (including assigning a static IP/Netmask/Gateway/DNS instead of using DHCP) and it connects OK. The code then keeps the WiFi connection active for 60 seconds before going to deep sleep for 60 seconds. On wake-up it immediately connects using the last active credentials, stays awake for 60 seconds and sleeps for 60 seconds, and so on. If the user double-resets the ESP I had hoped it would simply re-display the AP to allow the settings to be changed, but doing so must be upsetting the last saved WiFi credentials and the ESP takes much longer to reconnect again on the subsequent reboot/reset, particularly if the DRD mis-triggers and raises the AP without me knowing:
Beta Was this translation helpful? Give feedback.
All reactions