-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
ESP node can't reconnect to WiFi AP with weak signal after warm boot #2757
Comments
i can confirm. one of my esp has about -87 to -90 RSSI and can´t connect after warm reboot. |
@Sasch600xt What core version do you use? |
ESP_Easy_mega-20191119_normal_core_260_sdk222_alpha_ESP8266_4M1M |
I did change the platformio.ini file structure, so things may have a slightly different name. Maybe you can also test core 2.6.1 with both SDK versions for this issue? |
sure.....so next release then ? tonight ? |
I started a test build. |
i will be out of hous until tonight. |
Here is the test build: ESPEasy_mega-20191119-22-g17fbb474.zip |
i have to leave now but i had time for 2 quick tests. ESP_Easy_mega-20191119-22-g17fbb474_test_beta_ESP8266_4M1M where not working. |
OK, good to know. |
i did OTA Update to ESP_Easy_mega-20191119_test_core_260_sdk3_alpha_ESP8266_4M1M again and it came up after update, so all is fine with this firmware |
Yes it looks core 2.6.0 with sdk3 is a working combination while sdk2.2.2 together with both core 2.6.0 and core 2.6.1 has the WiFi issue. I am just building the customized firmware using Vagrant so perhaps I could share a fresh quick experience with core 2.6.1 & sdk3 soon... |
OK, so the first impressions with this custom build:
In general it somehow works, WiFi connection is made even after a warm reboot with a remote AP (RSSI about -84dB) but not so quickly, even after cold boot. It could be due to AP model type, to be tested with another AP in different location. |
I believe I have this problem too. Using ESP_Easy_mega-20191108-36-PR_2728_test_core_260_sdk222_alpha_ESP on a NodeMCU. Cold boots experience fast WiFi connection. Just speculation, but perhaps signal quality temporarily gets worse in my operating environment (walk near device, RF interference, bad mojo, etc). Then the "reboot issue" occurs and that starts this warm boot failure mode. BTW, despite the warm reboots, I didn't experience WiFi re-connection problems with a late August build using 260_sdk3_alpha core. So at this point I think that that the recent test_core_260_sdk222_alpha is involved.
|
wich bin from today can i use ? i miss a SDK3 for 4M1M. |
Today's build has changed the SDK version back to July version. See discussion here: esp8266/Arduino#5784 (comment) |
i see |
Thanks for the info. Hopefully the bad WiFi sensitivity after a warm boot will be fixed somehow in future (if it's the same for SDK from July). |
I have 4 nodes running that core version with uptimes over 55 days and 2 with over 20 days. |
I'm not sure which core / sdk combination do you mean. I think if the signal from AP is strong and stable, it (almost) does not matter which core / sdk is used for ESP Easy mega build and it works quite good and stable. Nevertheless, the different WiFi sensitivity after a cold versus warm boot is a really bad issue IMHO... Just uploaded one my node with the fresh official build: FirmwareBuild:⋄ | 20104 - Mega The WiFi issue is there again, node can't reconnect to AP after a warm reboot (RSSI -89). |
That's not the core 2.6.1 |
That's OK. ;-) I think beta versions should be tested as well. So far every tested core with sdk 2.2.2 had the same WiFi "warm boot" issue. Perhaps I should find a solution how to automatically perform a cold boot right after a warm one... :-) |
Let me share the test results on 2 nodes with the firmware mentioned above (ESP82xx Core 2.7.0-dev stage, NONOS SDK 2.2.2-dev(bb83b9b), LWIP: 2.1.2 PUYA support). The ESP Easy mega node with only BMX280 plugin and Home Assistant (openHAB) MQTT Controller, RSSI about -82: The ESP Easy mega node with more plugins but most of time only listen to MQTT import, RSSI about -91: |
The WiFi.disconnect() ensures that the WiFi is working correctly. If this is not done before receiving WiFi connections, those WiFi connections will take a long time to make or sometimes will not work at all.
In another repo, I came across some comment next to the Maybe it can be tested to see if it does fix this issue? |
I've installed ESP_Easy_mega-20191130-2-PR_2789_test_ESP8266_4M_VCC.bin on a NodeMCU and will report back on the test results.
|
As already mentioned in another thread, I tested quickly the ESP_Easy_mega-20191130-3-PR_2792_test_beta_ESP8266_4M1M.bin and have to confirm that the issue with a limited WiFi connectivity after a warm boot is still there (looks to be related with SDK 2.2.2). |
The WiFi.disconnect() ensures that the WiFi is working correctly. If this is not done before receiving WiFi connections, those WiFi connections will take a long time to make or sometimes will not work at all.
The WiFi.disconnect() ensures that the WiFi is working correctly. If this is not done before receiving WiFi connections, those WiFi connections will take a long time to make or sometimes will not work at all.
[WiFi] Call WiFi disconnect in setup() (#2757)
Test update: After ~3.5 days my ESP_Easy_mega-20191130-2-PR_2789_test_ESP8266_4M_VCC.bin (on a NodeMCU) has experienced a warm / soft reboot. The device appears to have rebooted with partial WiFi connectivity because I received an email from it that announced the reboot. But web access is broken. Initially I saw partial ESPEasy information from the browser. But after a couple refreshes all web access stopped (browser access times out). A cold power reset has restored operation.
|
I just got an idea about what may be different between a cold and a warm boot for wifi reconnects. When running the most recent builds (test build, not even nightly's, for example this one: ESPEasy_mega-20191130-17-PR_2798.zip) If you do this too frequently (within 5 minutes), the "next" configured AP will be selected, even though it is not the strongest signal. So in short:
OK, now the idea I have. Now what I am curious about: What I can change:
What may affect the tests:
So a lot to consider and I hope my braindump here is not too chaotic to follow ;) |
Well, thanks for the hints to test, I'll try to find some time to read your message carefully and test at least part of the suggested things. |
I tried several times over a two hour period, Eco Mode temporarily enabled. My WiFi router always appears in the list (only one router is configured on my devices).
|
Well, I have not been digging deep in the differences between SDK2.x and SDK3.
The main reason I added it (apart from the possibility to save energy on battery powered nodes) is to try and fix this issue we're dealing with here.
OK, so at least for your setup it may not be a factor to change the scan mode from active to passive. |
Let me share an update with some recent FW builds: BAD = bad WiFi sensitivity after a warm (re)boot BAD BAD OK OK OK So it looks SDK 2.2.2-dev(a58da79) fixed the WiFi issue reported above. So far I had to use SDK 3.0.0 (which was not recommended for use) for a custom firmware builds to avoid the bad WiFi sensitivity after a warm (re)boot which happens to me a bit often due to Exceptions. |
Another striking correlation is that a high plugin count correlates with bad WiFi stability. Not sure that it has something to do with it, just that it is a surprising correlation seen in your tests. |
It's interesting to me that the latest custom build also reconnects OK even after warm (re)boot with the same SDK release... OK
|
Let's hope so. |
Release mega-20191208 Changes in mega-20191208 (since mega-20191130): Gijs Noorlander (17): [WiFi] Use last known BSSID & channel from RTC + MQTT fixes [PIO] Update to core 2.6.2 [WiFi] Improve ESP32 WiFi connect + fix mDNS updates [PIO] Fix build failure due to incorrect flags. [PIO] Don't use Python 3 specific since Travis still uses Python 2.7 [WiFi] Call WiFi disconnect in setup() (letscontrolit#2757) [Rules] Parse template for all command calls [Rules] Execute some events asynchronous [Commands] Proper error logs when processing commands. [Commands] Add flag to be a bit more tolerant in last argument parsing [Events] Run events from rules immediately + add AsyncEvent command [FEATURE_SD] Add build in Platformio.ini with SD enabled (letscontrolit#2700 ) [Rules] Add some checks for rules consistency before saving [Rules] Add check for correct received POST data when saving rules [JSON] Fix issues with generated JSON [JSON] Fix non valid timing stats json when no plugins defined (letscontrolit#2767) [JSON] Extend timing stats JSON end point with controller and misc stats TD-er (1): automatically updated release notes for mega-20191208 stefan (1): Fix Arduino IDE include path
As already discussed in some other issue topics, it looks there's an issue in several latest firmware releases which prevents ESP node to reconnect a WiFi AP with weak signal (RSSI about -90 dB) after warm boot. After cold boot (turn power off / on) the node is connected quickly to the same AP without issue.
Tested various WiFi settings on ESP but it looks still the same.
The issue is Reproducible in environment where a lot of WiFi APs is visible at different distances (with a different signal level). WIFISCAN command invoked from serial console does show many APs after cold boot. After warm (re)boot due to node crash or REBOOT command only reduced AP list is returned by WIFISCAN command. So it looks node WiFi sensitivity is significantly reduced after a warm (re)boot and it makes the reconnect to AP with weak signal impossible.
Latest test performed with official build:
Firmware
Build:⋄ | 20104 - Mega
System Libraries:⋄ | ESP82xx Core 2_6_0, NONOS SDK 2.2.2-dev(bb83b9b), LWIP: 2.1.2 PUYA support
Git Build:⋄ | mega-20191119
Plugins:⋄ | 79 [Normal] [Testing]
Build Md5: | 2a40b605d5a65d4f9cee7fc88ad790
Md5 check: | passed.
Build Time:⋄ | Nov 19 2019 22:04:11
Binary Filename:⋄ | ESP_Easy_mega-20191119_test_core_260_sdk222_alpha_ESP8266_4M1M.b
The text was updated successfully, but these errors were encountered: