[GH-ISSUE #528] Connection result feedback in STA #442

Closed
opened 2026-02-28 01:25:19 +03:00 by kerem · 28 comments
Owner

Originally created by @gepd on GitHub (Feb 18, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/528

From #513

Requesting an option to display the reason why the connection wasn't able to be performed in the last try (STA mode). You will no always have access to read the debug output.

What could be the best way to implement this?
EEPROM, SPIFFS?

@tablatronix

Do you need to store it, or can it be a lifetime variable with a getter?

Can be a lifetime variable
I was thinking in storing it because how will you know the connection result after a possible reset?

Originally created by @gepd on GitHub (Feb 18, 2018). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/528 From #513 Requesting an option to display the reason why the connection wasn't able to be performed in the last try (STA mode). You will no always have access to read the debug output. What could be the best way to implement this? EEPROM, SPIFFS? @tablatronix > Do you need to store it, or can it be a lifetime variable with a getter? Can be a lifetime variable I was thinking in storing it because how will you know the connection result after a possible reset?
kerem 2026-02-28 01:25:19 +03:00
Author
Owner

@tablatronix commented on GitHub (Feb 18, 2018):

True but I dont have the library doing resets anymore. That typically is not needed after 2.1.0 i think. Unless you mean uexpected resets?

<!-- gh-comment-id:366486733 --> @tablatronix commented on GitHub (Feb 18, 2018): True but I dont have the library doing resets anymore. That typically is not needed after 2.1.0 i think. Unless you mean uexpected resets?
Author
Owner

@gepd commented on GitHub (Feb 18, 2018):

Yes, I mean assuming that it happens.
I don't know if it will ever happen or if storing it will be really useful. Today I just needed to know the reason why it wasn't connecting

<!-- gh-comment-id:366487670 --> @gepd commented on GitHub (Feb 18, 2018): Yes, I mean assuming that it happens. I don't know if it will ever happen or if storing it will be really useful. Today I just needed to know the reason why it wasn't connecting
Author
Owner

@tablatronix commented on GitHub (Feb 18, 2018):

ok I added this easiest as possible, so let me know if its not specific enough.

caveats

  • I am saving all connection results, not just failures, it was easier
  • I am saving conx result for autoconnect AND wifisave
  • no wifi saved uses WL_NO_SSID_AVAIL as a flag, maybe disconnected would be better, or 255, not sure

If this is not satisfactory, I can change to getLastConxFailure, and add if(!WL_CONNECTED) conditions and only log failures, I wasn't sure if that was needed.

I made getWLStatusString() public also

also I am just using uint8_t instead of wl_status_t, just cause all the internals would have to be changed, and it probably doesn't matter

<!-- gh-comment-id:366525196 --> @tablatronix commented on GitHub (Feb 18, 2018): ok I added this easiest as possible, so let me know if its not specific enough. caveats * I am saving all connection results, not just failures, it was easier * I am saving conx result for autoconnect AND wifisave * no wifi saved uses WL_NO_SSID_AVAIL as a flag, maybe disconnected would be better, or 255, not sure If this is not satisfactory, I can change to getLastConxFailure, and add if(!WL_CONNECTED) conditions and only log failures, I wasn't sure if that was needed. I made `getWLStatusString()` public also also I am just using uint8_t instead of wl_status_t, just cause all the internals would have to be changed, and it probably doesn't matter
Author
Owner

@gepd commented on GitHub (Feb 18, 2018):

I was doing something similar, and I can say now there is no need to store the result value.

I'll check your implementation, in my tests I was getting the value from waitForConnectResult and then I shown it when I was in AP mode again.

I guess, know if the problem was the ssid or password will be enough in most of the cases.

<!-- gh-comment-id:366527072 --> @gepd commented on GitHub (Feb 18, 2018): I was doing something similar, and I can say now there is no need to store the result value. I'll check your implementation, in my tests I was getting the value from `waitForConnectResult` and then I shown it when I was in AP mode again. I guess, know if the problem was the ssid or password will be enough in most of the cases.
Author
Owner

@tablatronix commented on GitHub (Feb 18, 2018):

also note
afaik STATION_WRONG_PASSWORD is not implemented in SDK last time I checked.
that is why
WL_CONNECT_FAILED is used for both STATION_CONNECT_FAIL and STATION_WRONG_PASSWORD

<!-- gh-comment-id:366528759 --> @tablatronix commented on GitHub (Feb 18, 2018): also note afaik STATION_WRONG_PASSWORD is not implemented in SDK last time I checked. that is why `WL_CONNECT_FAILED` is used for both ` STATION_CONNECT_FAIL` and `STATION_WRONG_PASSWORD`
Author
Owner

@gepd commented on GitHub (Feb 19, 2018):

What do you think to add this value in HTTP_STATUS_OFF? But only when SSID or password is wrong

<!-- gh-comment-id:366581111 --> @gepd commented on GitHub (Feb 19, 2018): What do you think to add this value in `HTTP_STATUS_OFF`? But only when SSID or password is wrong
Author
Owner

@tablatronix commented on GitHub (Feb 19, 2018):

Not sure I understand

<!-- gh-comment-id:366695962 --> @tablatronix commented on GitHub (Feb 19, 2018): Not sure I understand
Author
Owner

@gepd commented on GitHub (Feb 19, 2018):

I mean, at this moment you have a message info showing the state of the network.

When it's not connected (HTTP_STATUS_OFF), it only shows **Not Connected** to networkname.
It would be more useful to display

Not Connected to networkname
SSID not valid / Wrong Password

But only if WL_NO_SSID_AVAIL or WL_CONNECT_FAILED

<!-- gh-comment-id:366762155 --> @gepd commented on GitHub (Feb 19, 2018): I mean, at this moment you have a message info showing the state of the network. When it's not connected ([HTTP_STATUS_OFF](https://github.com/tzapu/WiFiManager/blob/development/strings_en.h#L46)), it only shows `**Not Connected** to networkname`. It would be more useful to display ``` Not Connected to networkname SSID not valid / Wrong Password ``` But only if `WL_NO_SSID_AVAIL` or `WL_CONNECT_FAILED`
Author
Owner

@tablatronix commented on GitHub (Feb 19, 2018):

hmm, good idea

<!-- gh-comment-id:366769114 --> @tablatronix commented on GitHub (Feb 19, 2018): hmm, good idea
Author
Owner

@tablatronix commented on GitHub (Feb 19, 2018):

It looks like esp32 doesnt give much info on failure, just disconnected, ill keep looking but i didnt even see any useful events in the event system

<!-- gh-comment-id:366791532 --> @tablatronix commented on GitHub (Feb 19, 2018): It looks like esp32 doesnt give much info on failure, just disconnected, ill keep looking but i didnt even see any useful events in the event system
Author
Owner

@gepd commented on GitHub (Feb 20, 2018):

I've tested your last changes and WL_NO_SSID_AVAIL works as expected, with a wrong password I only get WL_CONNECT_FAILED

Is the WL_STATION_WRONG_PASSWORD flag recently introduced by espressif?

<!-- gh-comment-id:366834554 --> @gepd commented on GitHub (Feb 20, 2018): I've tested your last changes and `WL_NO_SSID_AVAIL` works as expected, with a wrong password I only get `WL_CONNECT_FAILED` Is the `WL_STATION_WRONG_PASSWORD` flag recently introduced by espressif?
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

In esp8266 it has always been there but not working. There is no equiv in esp32, there is an auth fail, but i only see it triggered when ap doesnt exist not on password falure, in fact i see no events for wrong password, just the default which is disconnected.

<!-- gh-comment-id:366836252 --> @tablatronix commented on GitHub (Feb 20, 2018): In esp8266 it has always been there but not working. There is no equiv in esp32, there is an auth fail, but i only see it triggered when ap doesnt exist not on password falure, in fact i see no events for wrong password, just the default which is disconnected.
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

In step 4.2, the Wi-Fi connection may fail because, for example, the password is wrong, the AP is not found, etc. In a case like this, <SYSTEM_EVENT_STA_DISCONNECTED> will arise and the reason for such a failure will be provided. For handling events that disrupt Wi-Fi connection, please refer to phase 6.

I tried debugging the reasoncodes and got nothing

<!-- gh-comment-id:366836976 --> @tablatronix commented on GitHub (Feb 20, 2018): > In step 4.2, the Wi-Fi connection may fail because, for example, the password is wrong, the AP is not found, etc. In a case like this, <SYSTEM_EVENT_STA_DISCONNECTED> will arise and the reason for such a failure will be provided. For handling events that disrupt Wi-Fi connection, please refer to phase 6. I tried debugging the reasoncodes and got nothing
Author
Owner

@gepd commented on GitHub (Feb 20, 2018):

I got it, the event needs an extra argument to get the reason:

#include <WiFi.h>

void WiFiEventHandler(WiFiEvent_t event, system_event_info_t info)
{
  Serial.printf("Got Event: %d\n", event);

  switch(event) {
    case SYSTEM_EVENT_STA_DISCONNECTED:
        Serial.printf("Reason: %d\n", info.disconnected.reason);
        break;
    }
}

void setup()
{
  Serial.begin(115200);
  
  WiFi.begin();
  WiFi.onEvent(WiFiEventHandler);
  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(500);
  }
  Serial.println();
}

void loop()
{
}
<!-- gh-comment-id:366856803 --> @gepd commented on GitHub (Feb 20, 2018): I got it, the event needs an extra argument to get the reason: ```cpp #include <WiFi.h> void WiFiEventHandler(WiFiEvent_t event, system_event_info_t info) { Serial.printf("Got Event: %d\n", event); switch(event) { case SYSTEM_EVENT_STA_DISCONNECTED: Serial.printf("Reason: %d\n", info.disconnected.reason); break; } } void setup() { Serial.begin(115200); WiFi.begin(); WiFi.onEvent(WiFiEventHandler); while (WiFi.status() != WL_CONNECTED) { Serial.print("."); delay(500); } Serial.println(); } void loop() { } ```
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

I just commited that, lol

The question now is how the fuck do you use this to do anything since its a static member function pointer..

I also spent most of my time debugging this damn thing, since nothing was making sense in debug logs
https://github.com/espressif/arduino-esp32/issues/1128

Earlier today , I got no meaning ful codes, today on another dev machine and network I was able to test all of this, and got logical reason codes.

<!-- gh-comment-id:366857717 --> @tablatronix commented on GitHub (Feb 20, 2018): I just commited that, lol The question now is how the fuck do you use this to do anything since its a static member function pointer.. I also spent most of my time debugging this damn thing, since nothing was making sense in debug logs https://github.com/espressif/arduino-esp32/issues/1128 Earlier today , I got no meaning ful codes, today on another dev machine and network I was able to test all of this, and got logical reason codes.
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

oddly sometimes I get no events at all, which seems odd, even if the router was not compatible or adhoc, I would think it would fire something.

[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 2 - STA_START
2
*WM: wifi station disconnect
*WM: Connecting to saved AP
*WM: connectTimeout not set, ESP waitForConnectResult...
??????
*WM: Connection result: WL_DISCONNECTED
*WM: lastconxresult: WL_DISCONNECTED
*WM: AccessPoint set password is VALID
*WM: 12345678
*WM: wifi station disconnect
*WM: Disabling STA
*WM: Enabling AP
*WM: StartAP with SSID:  ESP32_94678576
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 3 - STA_STOP
<!-- gh-comment-id:366996247 --> @tablatronix commented on GitHub (Feb 20, 2018): oddly sometimes I get no events at all, which seems odd, even if the router was not compatible or adhoc, I would think it would fire something. ``` [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 2 - STA_START 2 *WM: wifi station disconnect *WM: Connecting to saved AP *WM: connectTimeout not set, ESP waitForConnectResult... ?????? *WM: Connection result: WL_DISCONNECTED *WM: lastconxresult: WL_DISCONNECTED *WM: AccessPoint set password is VALID *WM: 12345678 *WM: wifi station disconnect *WM: Disabling STA *WM: Enabling AP *WM: StartAP with SSID: ESP32_94678576 [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 3 - STA_STOP ```
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

ok I just hacked it in using a static uint8_t _lastconxresulttmp; and copying it into _lastconxresulttmp as needed. Should work for now.

<!-- gh-comment-id:367001502 --> @tablatronix commented on GitHub (Feb 20, 2018): ok I just hacked it in using a ` static uint8_t _lastconxresulttmp;` and copying it into `_lastconxresulttmp` as needed. Should work for now.
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

sometimes I get this instead

          // [D][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE
          // *WM: Connection result: WL_DISCONNECTED          

not sure if this counts as wrong_password or not, probably not

<!-- gh-comment-id:367006060 --> @tablatronix commented on GitHub (Feb 20, 2018): sometimes I get this instead ``` // [D][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE // *WM: Connection result: WL_DISCONNECTED ``` not sure if this counts as wrong_password or not, probably not
Author
Owner

@gepd commented on GitHub (Feb 20, 2018):

I think it does. When I set a wrong pass I always get:

*WM: connectTimeout not set, ESP waitForConnectResult...
*WM: EVENT: WIFI_REASON: AUTH_EXPIRE
*WM: EVENT: WIFI_REASON: AUTH_FAIL
*WM: Connection result: WL_CONNECT_FAILED
<!-- gh-comment-id:367006842 --> @gepd commented on GitHub (Feb 20, 2018): I think it does. When I set a wrong pass I always get: ``` *WM: connectTimeout not set, ESP waitForConnectResult... *WM: EVENT: WIFI_REASON: AUTH_EXPIRE *WM: EVENT: WIFI_REASON: AUTH_FAIL *WM: Connection result: WL_CONNECT_FAILED ```
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

But this is WL_DISCONNECTED not WL_CONNECT_FAILED

hmm

It seem to be a uncaught event, if i set the password correct it connects, so it is a auth failure, not sure why the wl status is wrong

<!-- gh-comment-id:367007037 --> @tablatronix commented on GitHub (Feb 20, 2018): But this is WL_DISCONNECTED not WL_CONNECT_FAILED hmm It seem to be a uncaught event, if i set the password correct it connects, so it is a auth failure, not sure why the wl status is wrong
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

oh ok i see now

        } else if(reason == WIFI_REASON_AUTH_EXPIRE) {
            if(WiFi.getAutoReconnect()){
                WiFi.begin();
            }

This is changing the event status to disconnect, because it is auto reconnecting and losing the event somehow

<!-- gh-comment-id:367008004 --> @tablatronix commented on GitHub (Feb 20, 2018): oh ok i see now ``` } else if(reason == WIFI_REASON_AUTH_EXPIRE) { if(WiFi.getAutoReconnect()){ WiFi.begin(); } ``` This is changing the event status to disconnect, because it is auto reconnecting and losing the event somehow
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

I am trying to propose a fix for this, but I cannot figure out why this only runs 3 times, and not in a loop.
if WIFI_REASON_AUTH_EXPIRE status never gets updated, and there is no other event to stop the loop, so why does it only run 3 times ?

[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE
WM: EVENT: WIFI_REASON: 2
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE
WM: EVENT: WIFI_REASON: 2
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE
WM: EVENT: WIFI_REASON: 2
*WM: Connection result: WL_DISCONNECTED
<!-- gh-comment-id:367016803 --> @tablatronix commented on GitHub (Feb 20, 2018): I am trying to propose a fix for this, but I cannot figure out why this only runs 3 times, and not in a loop. if WIFI_REASON_AUTH_EXPIRE status never gets updated, and there is no other event to stop the loop, so why does it only run 3 times ? ``` [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED [W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE WM: EVENT: WIFI_REASON: 2 [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED [W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE WM: EVENT: WIFI_REASON: 2 [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED [W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE WM: EVENT: WIFI_REASON: 2 *WM: Connection result: WL_DISCONNECTED ```
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

ohhh duh, i never actually looked at this code

waitforconnectresult is the only thing preventing infinite loops in the event handler.. ugh
while((!status() || status() >= WL_DISCONNECTED) && i++ < 100) {

<!-- gh-comment-id:367017502 --> @tablatronix commented on GitHub (Feb 20, 2018): ohhh duh, i never actually looked at this code waitforconnectresult is the only thing preventing infinite loops in the event handler.. ugh while((!status() || status() >= WL_DISCONNECTED) && i++ < 100) {
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

Yeah so this actually runs forever, unless you change the mode which we do. hmm

<!-- gh-comment-id:367031254 --> @tablatronix commented on GitHub (Feb 20, 2018): Yeah so this actually runs forever, unless you change the mode which we do. hmm
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

well anyways, auto_expire could be auth took too long and other reasons, so it is probably not a good idea to tell users wrong password unless we know it for certain

<!-- gh-comment-id:367041971 --> @tablatronix commented on GitHub (Feb 20, 2018): well anyways, auto_expire could be auth took too long and other reasons, so it is probably not a good idea to tell users wrong password unless we know it for certain
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

https://github.com/espressif/arduino-esp32/issues/234

<!-- gh-comment-id:367043659 --> @tablatronix commented on GitHub (Feb 20, 2018): https://github.com/espressif/arduino-esp32/issues/234
Author
Owner

@tablatronix commented on GitHub (Feb 20, 2018):

I suppose we could change wrong password to "Auth Failure" to cover more bases

<!-- gh-comment-id:367052950 --> @tablatronix commented on GitHub (Feb 20, 2018): I suppose we could change wrong password to "Auth Failure" to cover more bases
Author
Owner

@gepd commented on GitHub (Feb 20, 2018):

Yes, It may be better.
I tried the latest changes and all seems to be working well

<!-- gh-comment-id:367066994 --> @gepd commented on GitHub (Feb 20, 2018): Yes, It may be better. I tried the latest changes and all seems to be working well
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#442
No description provided.