-
Notifications
You must be signed in to change notification settings - Fork 115
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
WiFi association unstable #410
Comments
@LeoSum8 please do not cross post. I've reopened issue #412. To maximize your chances of being responded there, you need to follow the guidelines when posting an issue. If you don't, then it's wasted time for everyone in the end. You've done a good job on the current issue and this saves me a good amount of time when analyzing. |
@LeoSum8 one thing I have noticed is that you have a conflicting setup: You have defined the DAC i2c configuration correctly This config would attempt to create a new i2c driver on the same GPIO but different port. Please remove it from the nvs. Also, I have checked your logs and I suspect that your wifi issue is hardware related, or perhaps caused by something in your environment. This is revealed by the logs here
when the wifi driver flips from init -> auth back to auth -> init. If you are able to find what the description of code 8a0 mean, then you might get some answers. The typical sequence of wifi should be:
I doubt we can do anything for this issue in our code, so for now I'll go ahead and close the issue. You could also check your power supply. for example do you get the same issue if you plug the wrover in a different power supply, if you disconnect it from the Louder board, etc. |
I'll leave the issue open for a couple of days so you can find it easily. |
Hi Sébastien, However, I am a bit confused. I did not open issue #412. It was opened only after I posted here the additional comment concerning my "ESP_ERR_NVS_KEY_TOO_LONG" find in the logs as I sincerely believed that it was related. But this comment is not visible here any more. I will be able to do further test and debugging hopefully on Wednesday. |
Not worries for the missing info. I want to help as much as possible given my availability and this means I'm not always in front of a computer where I can more easily navigate. I deleted the "key too long" comment as it was not related to this issue and also because I reopened the other issue where you can add more details. I'm curious to understand how this might happen. As for the current issue #410, I doubt I'll be able to help |
Thank you for checking my logs! The But just to get this off my chest, the incomplete issue #412 was not submitted by me but by @DamnDaniel-98. |
So I just checked if the same behaviour occurs with another firmware (euphonium). It does, but somehow it is caught.
|
I do apologize for the mistake and I think you are right. I am not too close #412 anyways since I cannot reproduce. |
I will see what I can do. The system could probably try a couple of times on Thanks for the finding |
Thank you for taking the time for this edge case. A couple of retries should definitely help me. When trying to find out what (8a0) means, as you suggested, I did find a couple of mentions. Could be a problem with the combination of certain ESP32 boards, the AVM Fritz!Box routers (very common in Germany) and signal strength. The reason code 202 (AUTH_FAIL) is not very helpful: "Espressif-specific Wi-Fi reason code: the authentication fails, but not because of a timeout." |
Given how other projects have delt with this, it might not be that much of an edge case |
Hi @LeoSum8 , I had a very similar problem after changing my Fritz!Box to the 7530. My squeezelite-esp32 clients were disconnecting all the time. The 8a0 was shown in my logs too. For me disabling the Package acceleration did the trick. They are not disconnecting anymore - as far as I can see. PS: thank you for this great project btw! |
Hi all,
I found some time today to retry getting squeezelite to run on my Louder ESP32.
Most of the time, the first attempt to connect to my home wifi fails and squeezelite falls back to AP mode. A manual reboot via RST-Button usually results in a successfull connection. Is this a known problem with certain setups? Would it be possible to make squeezelite try connecting several times before failing to AP-Mode? I saw that with other firmwares (euphonium, snapclient) the first connection attempt to my wifi sometimes fails too, but sinc those other firmwares just retry, I usually don't notice.
I think this behaviour also explains, why I sometimes seem to "loose" the client. I haven't been able to record that yet, since I don't have it hooked up to serial all of the time, but I guess if wifi fails at a later point, it would fall back to AP-Mode too and not retry connecting, right?
Preliminary Information
Hardware Details
Please describe your hardware setup:
NVS Settings
Logs
Full Log
Trimmed Log
Issue Description
The text was updated successfully, but these errors were encountered: