-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Troubleshooting continuation from #14032 #14043
Comments
Hi, There is no need to open new issues for the same problem. You can continue it in your own previous original issue. Doing that is good because in separated issues, it got complex for other users to follow your problem when doing a search. Exception 0 sometimes is because the power source is not enough or it is a very noisy one. Just for testing and so as to discard a faulty regulator in your device, please, can you try disconnecting it from mains AC and powering directly to the 5Vcc rail or to the 3.3Vcc rail with a good power source? |
Do you have a second (spare) one? The issues you encounter looks like a defect device. |
Txs, The log provided is when it was(still is) connected Serial via PC USB bus AND the Sonoff it self is powered by a breadboard 3,3 Volt 1 Amp Power Supply. |
|
Have flashed (and erased) a Basic R3 with 10.1.0.1. Using Wifi Manager to set AP to HLinc2 (ASUS) failed. 6x power off/on to restart Wifi Manager. Set AP to HLinc (TP-Link network) and it connected easy to it in N mode.
Back to the reported problem my thought is, as I configured the 2 AP's as above (my preferred setup) It will connect to ASUS if the router is fresh (re)started. If after hours it want/has to reconnect it ends up in this retry loop without success because it keeps connecting to the strongest AP (in my case the ASUS) Wish, Is it possible to let it connect after X tries to the other AP? Please let me know what to test /setup. I have a TP-Link 3x Deco M5 mesh and a Asus Mesh (AC2900 main/Rt68U client), several Sonoffs R2, R3, POW, HT16. I would be very pleased to be of any help in this annoying Wifi /Asus issue. |
|
Txs, did check. It is in wificonfig 4 as this is default but during this test the device was only trying to connect to the strongest and did not attempt to connect to the other configured AP. |
Sorry, ASUS routers have issues with the wifi routines of Espressif SDK (that are closed source). This SDK is used by the Arduino Core and Tasmota is built on top of all that. Please, check the discussion #13623 for extensive information about this and how to workaround it. |
Mmm, pitty, I do not use any Ardino, Just a lot (20+) of Sonoffs. Is my wish (connect to other AP after x failed tries) part of Tasmota or also this SDK? |
Arduino is the name of the Core that uses Tasmota (Not the board). Arduino is the code that have several low level functions. No matter which device you use, if you use Tasmota, under Tasmota, the functions are Arduino Core for ESP8266 board. This Core uses the radio routines provided by the manufacturer of the ESP8266 chip. Those are closed source and we can't fix them. So, all the issue with ASUS comes from the SDK (between other things is that the SDK don't have WMM that ASUS enforces as a MUST for 11n mode - other routers are relaxed about WMM requirements and that is why they work without issues). |
Thanks for the explanation. |
What Tasmota does with WIFICONFIG being set to 4, is to try to connect to AP1. if AP1 is not available (meaning that it is not in the air), it will try to connect to AP2. Then, if Tasmota is connected to any AP and it disconnects, It will try to connect to the other configured AP. With ASUS, the issue is that the initial handshake (while trying to connect) is performed but then ASUS asks for WMM and the SDK don't answer anything. So, from Tasmota side, it actually connects but in reality it doesn't. So, the intended behavior for WIFICONFIG 4 is what you want, but the handshake (being managed in the SDK) is not correct. You can:
Also, you can check everything discussed in #13623 for more workarounds in this known ASUS issue. Sorry. |
Txs for this very clear explanation.
This helps to configure my setup in a way to keep it reliable. Will configure it tomorrow and if acts as described i wiil close this issue.
… Op 14 dec. 2021 om 20:34 heeft Adrian Scillato ***@***.***> het volgende geschreven:
What Tasmota does with WIFICONFIG being set to 4, is to try to connect to AP1. if AP1 is not available (meaning that it is not in the air), it will try to connect to AP2. Then, if Tasmota is connected to any AP and it disconnects, It will try to connect to the other configured AP.
With ASUS, the issue is that the initial handshake while trying to connect is performed but then ASUS asks for WMM and the SDK don't answer anything. So, from Tasmota side, it actually connects but in reality it doesn't.
So, the intended behavior for WIFICONFIG 4 is what you want, but the handshake (being managed in the SDK) is not correct.
You can:
Set your router to allow b/g/n
disable WMM
put a different SSID to 5Ghz and disable band steering
Set the command wifi 3 in Tasmota to disable mode 11n
Disable So56 and So57 and set Tasmota to connect to the router you already know has the higher strength.
Also, you can check everything discussed in #13623 for more workarounds.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
Closing since the original issue is solved -> hardware issue. |
Sorry @Jason2866. It wasn't a hardware issue. It was caused by the known Arduino SDK / ASUS router Problem. |
The PR esp8266/Arduino#8319 does not solve the Asus issues. |
PROBLEM DESCRIPTION
Approx. 14 hours after reflashing Sonoff Basic R2 with 10.1.0.1 (fix for #14032), which solved Wifi issues and connected fast and easy to Asus network in N mode, I was unable to connect to this device via Web. Serial log showed it had problems to connect to ASUS (2,4 and 5 Ghz SSID's separated) in N mode. It could connect after Wifi 3 command but it showed Execption 9 and 0. See the serial log.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:TO REPRODUCE
Restarted, now with MQTT active
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: