-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem manually handling WiFi reconnect #2735
Comments
i had that problem too !!! FIX FOR USING 2.3.0 CORE (only .begin if not connected)!!!!!!!
|
I never call WiFi.begin() while already connected. So remaining issues is the way autoreconnect(false) don't work intuitively before a first connection actually has been established. And second, that WiFi.status() return WL_CONNECTED also when the current AP connected to becomes unavailable. In this case it actually works to call WiFi.begin even if WiFi.status is WL_CONNECTED |
I didn't understand what you are trying to do but in general there is nothing you can do to make the ESP8266 more likely to connect to WiFi. If you have called WiFi.begin(SSID,password) ever and you don't want to change SSID or password you never need to call WiFi.begin again. The module will do the best it can to acquire and maintain a WiFi connection and during boot up will commence connecting to WIFi before user code starts. |
Yes, but that is exactly what I want to avoid. To clarify what I would like to do; Power up ESP The power up/down is handled by external hardware. |
Just realized that autoconnect dosen't work with static wifi configuration. |
It seems needlessly complex to
If power saving is the goal, better to let it do its best for a while then go to deep sleep while not trying to connect. See long but comprehensive discussion of time it takes to connect. However, if the desire is to disable WiFi connectivity and re-enable it later then call wifi.persistent(false) then wifi.disconnect(true) which will turn off radio but not wipe WiFi credentials from flash then wifi.begin() to try connecting to WiFi again later. To learn how to connect with a static IP also see this discussion. The @eketjall statement
seems unlikely. How could it be known calling WiFi.begin caused the WiFi connection to be established when the ESP will already be trying to reestablish the WiFi connection anyway? |
Power consumption is one thing, and what you suggest is probably what I will end upp with. ie let the ESP do it's thing and have a timeout. The ESP is not trying to do anything "by it self" if WiFi.setAutoConnect ( false ) and WiFi.setAutoReconnect ( false ); If using Wifi.onEvent() you get event WIFI_EVENT_STAMODE_DISCONNECTED when the AP becomes unavailable. If checking WiFi.status() when the event WIFI_EVENT_STAMODE_DISCONNECTED occur it reports WL_CONNECTED. |
@eketjall says
Not correct. WiFi.config(ip,gw,subnet, dns) has to be called but not WiFi.begin() . Autoconnect state is remembered across boots and as long as autoconnect was not set to false you never need WiFi.begin(). I would consider
to be a bug but are you sure it was not connected again by the time you checked the state? If you tried to use the WiFi I expect it would report failure and if it succeeded then you are connected. |
Ok, wasn't aware that WiFi.begin wasn't needed. As far as the WIFI_EVENT_STAMODE_DISCONNECTED and WL_CONNECTED I am sure. Both autoconnect and autoreconnect is set to false when it happens. |
The WiFi connection process starts long before a sketch starts. A sketch will be launched about 300ms after the clock starts which is already a while after boot. Where @eketjall says
then I'd consider that a bug. From memory wifi.begin() will set autoreconnect true but I didn't check so I'm not sure. |
I've went for the solution to let the ESP do it's thing and just have a time out instead. But in doing so I found out that there is a differens in connection times depending on how you connect and how you restart/reset/repower the ESP. If you just do a ESP.reset() the connection times for a static configuration (call WiFi.config) is low (under 700ms) even without calling WiFi.begin() (and just letting the ESP use saved configuration) ESP.restart() and a power cycle seems to give similar results in connection times. Here is the code that gives me consistent connections times under 700ms:
|
The results reported by @eketjall look unlikely. The line These lines could be left out I'd be curious to see what time you get with this sketch. If you remove this line nothing changes. Also you have to do it a few times to be definitive as connection times have a random element as well,. |
We are drifting away from the original issue about contradictory event and status codes when a network becomes unavailable. (And autoconnect/autoreconnect which need a little more documentation to be crystal clear) Connection times is a can of worms never the less. With "your" sketch (the actual sketch below), testing now with a Nexus 5x as AP, which is probably not the best, gives some "interesting" results. I have also tested 4 different boot/restart/powerup methods. The reported times is "Program Time" averaged over 20 measurement.
For boot/reset method 3 & 4 I got quit a lot of variations in the results which indicates that the way of doing it manually by a jumper have some issues with the contact not being clean. Signal strength variations and interference from other networks will also most certainly be significant in this setup I have at the moment. I will try to do the test again with a better AP, and a "automated" hardware setup where I can control power on/off, CH_PD and also hardware Reset from an Arduino. But it seems clear that WiFi.begin(ssid,pass,ch,bssid) is preferred to get the fastest connection times.
The "Start millis" is around 250ms in all cases but for restart method 3 (CH_PD) where it is ~50ms. Sketch used:
|
My wifi issues all vanished when I switched to using Static IP configs instead of DHCP. The built-in DHCP seems to have issues, particularly as the distance between the esp8266 and the AP increases, suggesting perhaps inadequate internal timeouts or problems with retransmissions perhaps. |
Closing due to lack of feedback and age. |
I'm trying to handle WiFi auto/reconnects in WIFI-STA mode but having troubles.
Setting WiFi.setAutoConnect ( true ) to auto connect on power up works just fine.
Setting WiFi.setAutoReconnect ( false ) on the other hand have issues.
This setting dosen't have any effect if an initial connection is not established.
ie if there is no auto-connect and WiFi.begin(ssid,password) is called the ESP will try to reconnect ever 1s even if WiFi.setAutoReconnect ( false ) is called beforehand.
If an initial connection is established the WiFi.setAutoReconnect ( false ) will work as expected.
Only way I have found to disable auto reconnect after a WiFi.begin is to call WiFi.disconnect() if WiFi.status() not return 3 - WL_CONNECTED
This on the other hand will disable the possibility to manually reconnect later with WiFi.reconnect();
And calling WiFi.begin a second time causes a wdt reset
If an initial connection is established but later the AP which the ESP is connected to is not available any more the WiFi.status() is still returning 3 - WL_CONNECTED.
An event 1 - WIFI_EVENT_STAMODE_DISCONNECTED is triggered though.
This is my Sketch:
The text was updated successfully, but these errors were encountered: