WiFi Mode() not working #1306
Comments
|
A little more digging on this issue. All is not entirely happy with the WiFi modes. This sketch void setup()
{
Serial.begin(115200);
// delete old config
WiFi.disconnect(true);
delay(1000);
WiFi.begin(ssid, password);
WiFi.mode(WIFI_MODE_NULL);
}That at no point calls any AP functions leads to this debug output so it is curious that there are any AP_START event call backs given that there are no calls to start an AP. I've also discovered that the underlying espWiFiStop() when WIFI_MODE_NULL is used. This should then call wifiLowLevelDeinit() but this function does nothing and has the comment that it is not working.It would appear that further more.. if the only line in the sketch is static bool wifiLowLevelInit(){
static bool lowLevelInitDone = false;
if(!lowLevelInitDone){
tcpipInit();
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
esp_err_t err = esp_wifi_init(&cfg);
if(err){
log_e("esp_wifi_init %d", err);
return false;
}
esp_wifi_set_storage(WIFI_STORAGE_FLASH);
esp_wifi_set_mode(WIFI_MODE_NULL);
lowLevelInitDone = true;
}
return true;
}which should set the mode to I am beginning to think there is a bug in the API! any thoughts? |
|
workaround:
The end result is that is works as expected despite the SDK reporting mode 2 (AP) even when only the low level init had been done and it was not actually in AP mode. At least this way the WiFi class reports the right mode. example sketch below. Along with 2 debug outputs. Sorry for using my Tasker lib but it simplifies scheduling of things... #include <WiFi.h>
#include <Tasker.h> //https://github.com/sticilface/Tasker
const char* ssid = "abc";
const char* password = "def";
Task tasker;
const char * mysystem_event_names[] = { "WIFI_READY", "SCAN_DONE", "STA_START", "STA_STOP", "STA_CONNECTED", "STA_DISCONNECTED", "STA_AUTHMODE_CHANGE", "STA_GOT_IP", "STA_LOST_IP", "STA_WPS_ER_SUCCESS", "STA_WPS_ER_FAILED", "STA_WPS_ER_TIMEOUT", "STA_WPS_ER_PIN", "AP_START", "AP_STOP", "AP_STACONNECTED", "AP_STADISCONNECTED", "AP_PROBEREQRECVED", "GOT_IP6", "ETH_START", "ETH_STOP", "ETH_CONNECTED", "ETH_DISCONNECTED", "ETH_GOT_IP", "MAX"};
void WiFiEvent(WiFiEvent_t event)
{
Serial.printf("[WiFi-event] event: %d :%s\n", event,mysystem_event_names[event] );
Serial.printf("WiFi Mode = %d\n", WiFi.getMode());
}
void setup()
{
Serial.begin(115200);
delay(1000);
WiFi.onEvent(WiFiEvent);
Serial.println("\n\t\t\tStarting STA , mode should be 1");
WiFi.enableSTA(true);
WiFi.begin(ssid, password);
tasker.add([](Task & t) {
Serial.println("\n\t\t\tStopping WiFi mode should be 0");
WiFi.mode(WIFI_MODE_NULL);
}).setTimeout(10000);
tasker.add([](Task & t) {
Serial.println("\n\t\t\tStarting STA_AP, mode should be 3");
WiFi.mode(WIFI_MODE_APSTA);
WiFi.reconnect();
WiFi.softAP("test_AP");
}).setTimeout(20000);
tasker.add([](Task & t) {
Serial.println("\n\t\t\tContiniue AP only, mode should be 2");
WiFi.enableSTA(false);
}).setTimeout(25000);
tasker.add([](Task & t) {
Serial.println("\n\t\t\tStop all, mode should be 0");
WiFi.enableAP(false);
}).setTimeout(30000);
}
void loop()
{
tasker.run();
}NORMAL result from git head with above mentioned changes so in conclusion, it looks like my changes work well. the mode changes as it should whereas currently it reports random modes!. I'd appreciate some other testing of this please. so far no one has identified it as an issue... |
…lows you to hook in, as the sdk does not generate this event for you. As it stands the SDK does not appear to set `WIFI_MODE_NULL` correctly. if the wifi is initialised and set to `WIFI_MODE_NULL` it actually defaults to AP mode. This fix keeps `WIFI_MODE_NULL` within the ESP class if the wifi has not been init yet, and works in my testing. albeit a one sided conversation. espressif#1306
|
I do not see this behavior at all, with either the 2 sketches provided. |
|
oh btw that garbage when calling printdiag before init is a pita #1088 |
|
Oh ok now I see the issue, wonder what changed... let me erase and see |
Actually it appears to be the persistent mode saved in flash, if you set mode and reset, and wifiinit via getmode it will be what you last had it as. for example you can setup sta and ap configs remove them from your code do and it will connect to both sta and softap saved prior. If you set mode to something else, then it will only start those. |
|
I did one time catch this |
|
In my opinion there should be no resetting at all to get it to work. as checks to see if it needs to do anything. making getMode() a passive function that does not by itself initialise the WiFi stack seems more sensible to me, than initialising it and having it in the wrong mode. I have not yet experimented with saving the wifi settings to flash. so i cannot comment on those. |
|
Yeah I was just noting the mode is not random its the esp stored mode that was last set. |
|
So it appears that WIFI_MODE_NULL is not an sdk mode , its a pseudo mode, this is what was confusing me. But wifiLowLevelInit does I also found another issue with this, see here |
|
When I revert to 3a4ec66 That is why this was working for me at first, then I pulled |
|
what i experienced is, that as @tablatronix pointed out, WIFI_MODE_NULL is not a valid mode as far as the IDF is concerned. Unfortunately IDF will silently fall back to the mode that it once stored in NVS (so I think), and there is no sane way to clear the config in NVS. IMHO, we simply should not call wifiLowLevelInit() until mode has been set by the user to something other then WIFI_MODE_NULL.
i agree.
persistent NVS config saving was the default before #1406 got merged an hour ago. so your settings ALWAYS got saved in flash. |
* Add `SYSTEM_EVENT_WIFI_READY` call back once wifi service is init. allows you to hook in, as the sdk does not generate this event for you. As it stands the SDK does not appear to set `WIFI_MODE_NULL` correctly. if the wifi is initialised and set to `WIFI_MODE_NULL` it actually defaults to AP mode. This fix keeps `WIFI_MODE_NULL` within the ESP class if the wifi has not been init yet, and works in my testing. albeit a one sided conversation. #1306 * make changes compatible with new _persistent behaviour.
) * Add `SYSTEM_EVENT_WIFI_READY` call back once wifi service is init. allows you to hook in, as the sdk does not generate this event for you. As it stands the SDK does not appear to set `WIFI_MODE_NULL` correctly. if the wifi is initialised and set to `WIFI_MODE_NULL` it actually defaults to AP mode. This fix keeps `WIFI_MODE_NULL` within the ESP class if the wifi has not been init yet, and works in my testing. albeit a one sided conversation. espressif#1306 * make changes compatible with new _persistent behaviour.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
|
This stale issue has been automatically closed. Thank you for your contributions. |
|
In my project, I successfully fixed the reconnect issue with the following hack: But I think the real issue is how getMode is implemented |
|
Not sure what version was in use when this problem was noted, but it's happening again in 1.0.4: #include<WiFi.h>
void setup() {
Serial.begin(115200);
WiFi.begin();
WiFi.disconnect(true,true);
Serial.printf("STA mode? %s AP mode? %s [%d]\n",WiFi.getMode() & WIFI_STA ? "true":"false",WiFi.getMode() & WIFI_AP ? "true":"false",WiFi.getMode());
WiFi.printDiag(Serial);
WiFi.mode(WIFI_OFF);
Serial.printf("STA mode? %s AP mode? %s [%d]\n",WiFi.getMode() & WIFI_STA ? "true":"false",WiFi.getMode() & WIFI_AP ? "true":"false",WiFi.getMode());
WiFi.printDiag(Serial);
}
void loop() {
}[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 0 - WIFI_READY
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 2 - STA_START
[E][WiFiSTA.cpp:219] begin(): connect failed!
STA mode? false AP mode? false [0]
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 3 - STA_STOP
Mode: STA
Channel: 1
SSID (0):
Passphrase (0):
BSSID set: 0
STA mode? false AP mode? false [0]
Mode: STA
Channel: 1
SSID (0):
Passphrase (0):
BSSID set: 0getMode() returns 0, yet printDiag reports STA - this is just plain WRONG! Do getMode and printDiag retrieve the REAL value of mode from different places? What is going on here and why has it not been fixed? |
|
WiFi.getMode() and WiFi.printDiag() both are working as designed and expected on 1.0.4. Your code is incorrectly testing for bit mask rather than equality as it should be. |
* Add `SYSTEM_EVENT_WIFI_READY` call back once wifi service is init. allows you to hook in, as the sdk does not generate this event for you. As it stands the SDK does not appear to set `WIFI_MODE_NULL` correctly. if the wifi is initialised and set to `WIFI_MODE_NULL` it actually defaults to AP mode. This fix keeps `WIFI_MODE_NULL` within the ESP class if the wifi has not been init yet, and works in my testing. albeit a one sided conversation. espressif/arduino-esp32#1306 * make changes compatible with new _persistent behaviour.
* Add `SYSTEM_EVENT_WIFI_READY` call back once wifi service is init. allows you to hook in, as the sdk does not generate this event for you. As it stands the SDK does not appear to set `WIFI_MODE_NULL` correctly. if the wifi is initialised and set to `WIFI_MODE_NULL` it actually defaults to AP mode. This fix keeps `WIFI_MODE_NULL` within the ESP class if the wifi has not been init yet, and works in my testing. albeit a one sided conversation. espressif/arduino-esp32#1306 * make changes compatible with new _persistent behaviour.
Hardware:
Board: ESP32 Dev Module?
Core Installation/update date: @ 29b3a81
IDE name: Platform.io
Flash Frequency: 40Mhz
Upload Speed: 115200
Description:
WiFi.mode() not working. Set it to 0 (WIFI_OFF) and it stays at 3.
Sketch:
Debug Messages:
so it is clear that WiFi.mode(WIFI_MODE_NULL) is not setting the mode to 0, but 3 which is AP.
Any ideas?
The text was updated successfully, but these errors were encountered: