ESP32 - TTGO T5 E-INK - Auto Connect only works every 2nd time #292
Comments
Anton2k
changed the title
|
Can you provide logs with AC_DEBUG enabled? |
I forgot to paste the link. The link path you showed is my intention.
|
|
@Hieromon here is the output after enabling debugging, not sure if it will help you much or not though. 1st attempt after flashing - (CONNECTED) Second attempt after switch the ESP32 off and on - (DISCONNECTED) Third attempt after switching the ESP32 off and on again - (CONNECTED) And you get the idea, the cycle just repeats connecting only every other time, hope it helps and thanks. |
|
Please post your specified AutoConnectConfig settings. I'll try to reproduction the test with my environement. |
|
@Hieromon I'm not sure where I find those, just using the defaults as far as I know and using the Simple example sketch. |
|
In your environment, WiFi.begin by esp-idf is failing in the first place. This is the result of reproducing your sketch in my module and environment. This is the connection status when the power is turned off and then turned on again after Config New. The cause seems to be somewhere other than AutoConnect. |
|
@Hieromon Is there a deeper level of debugging I can do on the ESP32 it's self? I have been reading some people are getting the same issue and that it could be related to the handshake. I want to try something, I want to manually disconnect from the WiFi before powering off the ESP32, how would I do this in the Simple sketch, WiFi.disconnect(True); ? |
|
@Hieromon Also here is the verbose output on a failed connection attempt |
You can use the Disconnect using AutoConnect menu navigation with the source code modification as below: AutoConnect/src/AutoConnect.cpp Line 593 in 19938b8 Change to: disconnectWiFi(true);In addition, if you want to keep the connection AP data stored by esp-idf, you also need to modify the following (AutoConnect's Disconnect menu erases the connected AP data stored in esp-idf by default): AutoConnect/src/AutoConnect.cpp Line 1504 in 19938b8 Change to: WiFi.disconnect(wifiOff, false); |
The access point refused to connect caused the password is wrong... It is a phenomenon that the password requirement does not match between your AP and esp-idf, but it is impossible if we think normally. |
|
@Hieromon I have changed the 2 lines you mentioned above, but not sure how to call Disconnect in my sketch. would it just be
Sorry still trying to figure this all out. |
|
No need to sketch. You can disconnect at any time by using |
Yes hard coded in sketch, my project will only wake for a minute or 2 every 24hrs to get some data. So I added |
That's the specification of the ESP32 arduino core. WiFiSTAClass uses it for WiFi.reconnect () and WiFi.begin with no arguments. However, I don't think it has anything to do with this phenomenon. WiFi.begin with no arguments restores that information and attempts to connect to the AP.
What is the reason for this? Is it the characteristics of a particular access point product? |
The project I am working on needs to use little to no power, the idea is the ESP32 connects to the internet, gets some data then powers off, I will use an RTC to power it back on. Meaning it will be drawing 0 power when it is not in use. I think the AP may have something to do with it, I'll need to test it out on my phone's hotspot or another router so see what results that yields. I'LL do some more testing tomorrow and get back to you on this, at the moment I think this work around should work well for my purposes. |
|
I understand, let wait for the results from you. |
|
@Hieromon So I have done some testing today both on my router, another router and my phones hot spot. All return the exact same behaviour, I can only put it down to the ESP32 at this stage and when I kill the power the WiFi connection is not killed cleanly (whatever that means), all I know is that using Here is my thinking, store a variable in the flash memory of the ESP32, it stores only 1 of 2 values at and time (lets say the values are 0 and 1).
Don't know if my idea is any good or not, but |
|
@Hieromon More findings... SW_CPU_RESET aka ESP.restart(); does not clear the issues, I some how need to figure out to call POWERON_RESET |
|
@Hieromon So another update... after a bit more digging I have discovered that putting in a delay at the very top of my setup() causes the ESP32 to auto connect each time, even if the power is killed after it has established a connection. I have managed to get the delay down to 35 seconds, any less than that at I get issues again. So couple of things, WIFI. Disconnect(); stops the issues and so does adding in a 35 second delay before connecting to any wifi, this tells me that something somewhere is holding on to something that is preventing from connecting to the network, if I disconnect cleanly what ever is being held on to is released, if I dont it gets held, the delay allows what ever is being hung on to; to be reset or released, no idea if this could be an IP or something router side or something within the ESP32 it's self, there is a guy here espressif/arduino-esp32#653 (comment) talking about the DHCP and stuff, I'm just now sure though. For the time being this delay will do! |
|
@Anton2k Thank you for the detailed survey results. I followed your guidance and traced the implementation of the arduino-esp32. What the Arduino-esp32 core does with the Even I encountered this phenomenon for the first time. I think there is something left on the AP side related to authentication. It's something other than an SSID and password. And that's something that is ignored (or adapted) if the negotiation is done from the beginning. |
Hieromon
added
Under investigation
|
@Hieromon At this point I am pretty sure it's a router side thing and it relates to DHCP. I think the ESP32 always tries to connect with the same IP to the access point. If the disconnect and reconnect happens quickly, depending on the router and manufacture, the IP will not be released in time from the router so that the ESP32 can connect. After having a look in AutoConnectDefs.h I cam across this line (132)...
So by default the timeout is set to 30 seconds, which I can confirm does not work for me, I need at least 35 seconds. I think there should be a way to set the timeout via config, this would allow us to account for different routers. There is a chance that some other routers could be 60 seconds or more before release the IP from the DHCP. |
|
@Anton2k Thank you. I also had read the topic you showed. It doesn't explain everything. And the workaround presented there is essentially the same as the method AutoConnect has already implemented as an AutoConnectConfig::autoReconnect setting. The problem we encountered this time is even deeper. So, the investigation found important discoveries on topics similar to this issue. Its conversation in this thread is very long, suggesting that many contributors have been working on this issue for over a year. And I was able to have a scenario of this phenomenon from the following: espressif/arduino-esp32#2501 (comment)
The WiFi frame capture log by Wireshark is a fact. If that is the cause, there is also a reason for Here, let's explore the logs we encountered again is the following: The router has rejected the connection request from the second turned-on ESP32 that does not send the encryption key. It happens on the 1st-WiFi.begin() and the result is On the other hand, the AP is retaining the ESP32's MAC address and its assigned IP address. It is the same as the MAC address included in the DHCP-discover sent by the second WiFi begin. The AP will not assign a new IP and will not send a DHCP-offer to respond to the sent DHCP-discover. Then the EP32 DHCP client initiation fails. Then, it will explain all the phenomena we encountered. In any case, the current solution is, as you've found, a "delay method". It suggests a similar workaround in the topic above (for now). But I'm very sorry to disappoint you, I think extending timeout having
AutoConnect is already equipped with the setting. Refer to the documentation and you can try it. It is not enough that only extending the timeout for the 1st-WiFi.begin(). The proven workaround has appeared many times in the topics mentioned above and is called a "double-hitter". Also, I think the contributors are getting closer to the heart of the matter. Here, and Here. And Thank you again for your very committed cooperation. I'm glad you used AutoConnect. |
|
@Hieromon Thanks again for trying to help me resolve this issues, I can understand some of above but not everything, I will need to read over it again and take time to digest it, but what you have said makes sense. I will be more than happen to test any solution that you come up with and will keep a close eye on those other issues on the espressif github, thanks again and I look forward to hearing from you. ありがとうございました |
|
@Anton2k Hello,
I hope this skeleton works, but it has no guarantee. Even if this workaround goes wrong, I would like to consider the next best. Thank you for your contribution. #include <Arduino.h>
#include <WiFi.h>
#include <esp32-hal-log.h>
// Change to suit your WiFi router
#define WIFI_SSID "SSID_YOU_WISH"
#define WIFI_PASSWORD "PASSWORD_YOU_WISH"
void setup() {
wl_status_t wst;
unsigned long tm;
delay(1000);
Serial.begin(115200);
Serial.println();
esp_log_level_set("wifi", ESP_LOG_VERBOSE);
esp_log_level_set("dhcpc", ESP_LOG_VERBOSE);
WiFi.mode(WIFI_STA);
Serial.print("connecting");
wst = WiFi.begin();
tm = millis();
if (wst == WL_DISCONNECTED) {
Serial.print(" - disconnected, wait for failure");
while (millis() - tm < 35000) {
wst = WiFi.status();
if (wst == WL_CONNECT_FAILED || wst == WL_CONNECTED)
break;
delay(300);
Serial.print('_');
}
}
if (wst == WL_CONNECT_FAILED) {
wst = WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
Serial.printf("\nAttempts reconnect(%d)", (int)wst);
}
while (millis() - tm < 30000) {
if ((wst = WiFi.status()) == WL_CONNECTED)
break;
delay(300);
Serial.print('.');
}
if (wst == WL_CONNECTED)
Serial.printf("conencted IP:%s\n", WiFi.localIP().toString().c_str());
else
Serial.printf("failed:%d\n", (int)WiFi.status());
Serial.println("setup processed end");
}
void loop() {
} |
|
@Hieromon This is what I get each time. |
|
@Anton2k Did you change SSID and password to suit your router? // Change to suit your WiFi router
#define WIFI_SSID "SSID_YOU_WISH"
#define WIFI_PASSWORD "PASSWORD_YOU_WISH" |
|
@Hieromon The problem was I forgot to wipe the flash, I have now wiped it and here are my results. Directly after wiping the flash and flashing the sketch. I then kill the power to the ESP32 and power it back on. I consistently get these results, so it looks like it fails the first time, then there on after always connects. A step closer! |
|
@Anton2k, Ok. As I thought, the problem seems to be on the router. AUTH_FAIL may occur with or without parameters in WiFi.begin after power off without WiFi.disconnect and then power on. #include <Arduino.h>
#include <WiFi.h>
#include <esp32-hal-log.h>
// Change to suit your WiFi router
#define WIFI_SSID "SPXAA2831416"
#define WIFI_PASSWORD "ae38546b444a55b"
void setup() {
wl_status_t wst;
unsigned long tm;
delay(3000);
Serial.begin(115200);
Serial.println();
esp_log_level_set("wifi", ESP_LOG_VERBOSE);
esp_log_level_set("dhcpc", ESP_LOG_VERBOSE);
WiFi.mode(WIFI_STA);
Serial.print("connecting");
wst = WiFi.begin();
tm = millis();
if (wst == WL_DISCONNECTED) {
Serial.print(" - disconnected, wait for failure");
while (millis() - tm < 30000) {
wst = WiFi.status();
if (wst == WL_CONNECT_FAILED || wst == WL_CONNECTED)
break;
delay(300);
Serial.print('_');
}
}
if (wst == WL_CONNECT_FAILED) {
// Disconnection and delay encourages the router to release resources.
// Please increase the delay time depending on your situation.
WiFi.disconnect(true, false);
delay(500);
wst = WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
Serial.printf("\nAttempts reconnect(%d)", (int)wst);
}
while (millis() - tm < 30000) {
if ((wst = WiFi.status()) == WL_CONNECTED)
break;
delay(300);
Serial.print('.');
}
if (wst == WL_CONNECTED)
Serial.printf("conencted IP:%s\n", WiFi.localIP().toString().c_str());
else
Serial.printf("failed:%d\n", (int)WiFi.status());
Serial.println("setup processed end");
}
void loop() {
} |
|
@Hieromon With the new code and efter flash erase, 1st boot 2nd boot after killing power 3rd boot after killing power 4th boot after killing power |
|
@Anton2k It's a pretty tough opponent. // Disconnection and delay encourages the router to release resources.
// Please increase the delay time depending on your situation.
WiFi.disconnect(true, false);
delay(500);Also, please verify how it behaves when you change the second parameter of |
|
@Hieromon Using And clearing the ESP32 flash here are the results.
|
|
@Hieromon Using 6500 is the lowest I can go, I tried 6400 and it failed first time after flashing. I was able to get it to connect first time with 6500 after flash, and every time there after. :)
|
|
@Anton2k No matter how it is into stable, 65 sec is too long. This way cannot be applied as standard specification to the AutoConnect library. According to the latest release candidate of the arduino-esp32 v1.0.5 (it's currently staged as RC4), In this case, I will release the library with How about this? For reference
wl_status_t WiFiSTAClass::begin()
{
if(!WiFi.enableSTA(true)) {
log_e("STA enable failed!");
return WL_CONNECT_FAILED;
}
wifi_config_t current_conf;
if(esp_wifi_get_config(WIFI_IF_STA, ¤t_conf) != ESP_OK || esp_wifi_set_config(WIFI_IF_STA, ¤t_conf) != ESP_OK) {
log_e("config failed");
return WL_CONNECT_FAILED;
}
if(!_useStaticIp) {
if(tcpip_adapter_dhcpc_start(TCPIP_ADAPTER_IF_STA) == ESP_ERR_TCPIP_ADAPTER_DHCPC_START_FAILED){
log_e("dhcp client start failed!");
return WL_CONNECT_FAILED;
}
} else {
tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA);
}
if(status() != WL_CONNECTED && esp_wifi_connect()){
log_e("connect failed!");
return WL_CONNECT_FAILED;
}
return status();
}
wl_status_t WiFiSTAClass::begin()
{
if(!WiFi.enableSTA(true)) {
log_e("STA enable failed!");
return WL_CONNECT_FAILED;
}
wifi_config_t current_conf;
if(esp_wifi_get_config(ESP_IF_WIFI_STA, ¤t_conf) != ESP_OK || esp_wifi_set_config(ESP_IF_WIFI_STA, ¤t_conf) != ESP_OK) {
log_e("config failed");
return WL_CONNECT_FAILED;
}
if(!_useStaticIp && set_esp_interface_ip(ESP_IF_WIFI_STA) != ESP_OK) {
log_e("set ip failed!");
return WL_CONNECT_FAILED;
}
if(status() != WL_CONNECTED){
esp_err_t err = esp_wifi_connect();
if(err){
log_e("connect failed! 0x%x", err);
return WL_CONNECT_FAILED;
}
}
return status();
} |
|
@Hieromon I thinks it's 6.5 seconds, not 65 seconds. Yes that sounds like a good compromise until the main lib fixes the core of the problem, thanks again for your help :) |
|
@Anton2k, Thank you for more frequent results reporting. I have staged a patched release around the issue. Specifications for the workaround
If you disagree with the above specifications, please suggest a correction. I hope the patch can resolve the issue. |
|
Hi @Anton2k and @Hieromon, I am here because I faced the same problem when connecting to only certain router with certain internet service provider (to be specific, only when connecting to sim card router aka portable router, no issue with connecting to home wifi or mobile hotspot). I saw someone suggested to try the method below in this link, as they suggested this workaround can perform a hardware reset to the peripheral: Not sure whether that helps, was wondering could this be one of the solutions. |
|
What is the make and model of your portable hotspot? Seems the problem is
following your hotspot. Mine works on home, portable hotspot etc. Is your
password valid, correct number of digits, standard characters, not 5gig
band etc. Look further into your equipment as thousands of people are not
having an issue. This is where I would start looking.
…On Thu, 8 Apr 2021, 6:22 pm txlim96, ***@***.***> wrote:
Hi @Anton2k <https://github.com/Anton2k> and @Hieromon
<https://github.com/Hieromon>, I am here because I faced the same problem
when connecting to only certain router with certain internet service
provider (to be specific, only when connecting to sim card router aka
portable router, no issue with connecting to home wifi or mobile hotspot).
I saw someone suggested to try the method below in this link,
<https://www.esp32.com/viewtopic.php?t=15768> as they suggested this
workaround can perform a hardware reset to the peripheral:
#include "driver/periph_ctrl.h" ...
periph_module_reset(PERIPH_WIFI_MODULE); delay(500); WiFi.begin(ssid,
passw); ...
Not sure whether that helps, was wondering could this be one of the
solutions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#292 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ7LPA5CW23TO2D4CN4EJADTHVRTVANCNFSM4VSLXJSA>
.
|
|
Hi @svdrummer, please bear with me as I am still new to this field. May I know how can I determine the make of the portable router? The model of the portable router should be: Huawei B315s-22 B315 (it is a simcard router, and I'm connecting to its 2.5GHz network). My ESP32 is able to connect to the portable hostpot, and reconnect back (just that it won't reconnect back after some time (but manage to instantly reconnect back when I power cycle it). So I'm still searching for the root cause of this problem |
|
@txlim96 I would recommend that you carry out a reproduction test you using a simple sketch. Do not include AutoConnect handling in the sketch. It would be logic like my previous comment, for example: #292 (comment) If you can reproduce the problem, then add the following code. It is following your advice. #include <driver/periph_ctrl.h>
...
esp_log_level_set("wifi", ESP_LOG_VERBOSE);
esp_log_level_set("dhcpc", ESP_LOG_VERBOSE);
// Insert the following 2 lines
periph_module_reset(PERIPH_WIFI_MODULE);
delay(500);
WiFi.mode(WIFI_STA);
Serial.print("connecting");If your sketch can reconnect to your mobile router after disconnection once, you've found gold. I look forward to your results. |
Having a weird issue where, if my ESP32 looses power, and I give it power again it wont connect to the saved network. If I turn it off and back on again it will connect. It almost as if it will only connect every second time if that makes sense? I am using the simple sketch that is included.
Thanks
The text was updated successfully, but these errors were encountered: