Try to power your ESP32 through a 5v pin, instead of the USB port. It worked for me.
1 Like
In MY case it is a ESP8266-NODEMCU and it IS powered via 5V-Pin… ;-(
This worked for me. (After trying every other potential solution I found while googling)
Thanks - forgot about the channel option … I know some earlier apple devices had similar issues with certain channel’s at the end of the channel range (11 and above)
Adding of these options solved my problem with Auth expired problem. Thanks to everybody!
The board is: ESP-WROOM-32, DEVKITV1
I had a horrible time trying to get it to work… ESP32-WROOM-32
Finally had success when I:
a) Set my 2.4Ghz SSID to Channel 1.
b) Stopped sharing the same SSID on 2.4 and 5Ghz bands (should have done that a while ago… I know)
But the secret sauce for me was:
c) Set the 2.4 channel width from 20/40 to 20Mhz only
d) On my ASUS GTX11000 I switched off the 802.11ax / WiFi 6 mode. I think that was causing some incompatibility grief
I have an esp32 c3 super mini that is doing this. Im thinking it’s a HW issue or cold solder joint.
When the board is not in a socket or pin headers, it connects no problem…the moment I put the board in pin headers or into a breadboard, the wifi issue pops up. Very interesting.
1 Like
Adding these lines resolved it for me… So strange…
reboot_timeout: 15min
power_save_mode: none
enable_on_boot: True
fast_connect: On
output_power: 8.5
I just had a TON of issues getting an esp32-c3 “supermini” board installed. It would work, but intermittently. I was trying it with a mmwave LD2410 sensor, so I assumed maybe that was faulty, perhaps the wiring or something like that.
It turns out the issue was the wifi signal strength. Due to the size of the small board, the wifi “antennas” on this thing are not so good. It needs to be fairly close to the AP in order to connect and maintain stable connection. I tried all the other fixes - enabling power saving features, disabling power saving features, setting transmit power manually - nothing worked. What did work though was moving close to the AP slightly.
FWIW, I have three APs (unifi) with tens of IoT devices, none of which currnetly have any issues.
Interestingly the board could “see” the two closest to it and reported what seemed like a low, but usable signal strength (-76 dB)
[21:51:20][D][wifi:497]: Found networks:
[21:51:20][I][wifi:541]: - 'IoT-WiFi' [redacted]▂▄▆█
[21:51:20][D][wifi:542]: Channel: 6
[21:51:20][D][wifi:543]: RSSI: -76 dB
[21:51:20][I][wifi:541]: - 'IoT-WiFi' [redacted]▂▄▆█
[21:51:20][D][wifi:542]: Channel: 1
[21:51:20][D][wifi:543]: RSSI: -81 dB
[21:51:20][D][wifi:546]: - [redacted] [redacted]▂▄▆█
[21:51:20][D][wifi:546]: - [redacted] [redacted]▂▄▆█
[21:51:20][D][wifi:546]: - [redacted] [redacted]▂▄▆█
[21:51:20][I][wifi:313]: WiFi Connecting to 'IoT-WiFi'...
[21:51:21][W][wifi_esp32:569][arduino_events]: Event: Disconnected ssid='IoT-WiFi' bssid=[redacted] reason='Auth Expired'
[21:51:21][W][wifi:653]: Error while connecting to network.
[21:51:21][D][wifi:697]: Retrying with hidden networks...
[21:51:21][I][wifi:313]: WiFi Connecting to 'IoT-WiFi'...
[21:51:22][W][wifi_esp32:569][arduino_events]: Event: Disconnected ssid='IoT-WiFi' bssid=[redacted] reason='Auth Expired'
[21:51:22][W][wifi:653]: Error while connecting to network.
[21:51:22][D][wifi:697]: Retrying with hidden networks...
In the end, I moved it from my desk to directly next to an AP, just for testing and voila - it works. None of my other ESP32 boards had this issue in the past (I use mainly the larger kind).
Perhaps consider a different board if coverage is a problem for you.
reboot_timeout: 15min
power_save_mode: none
enable_on_boot: True
fast_connect: On
output_power: 8.5
Can confirm adding this to wifi section fixed this for me too
ESP32-C3 which had been working fine and then decided it wasn’t going to anymore.
Working fine now.
1 Like
Finally! I tried tons of other solutions, but this was the one that finally let me get this ESP8266 online.
I am seeing the exact same issue with my Shelly Mini Gen3. It worked fine, then I reflashed it and suddenly it won’t boot without output_power being set.
What’s weird is that nothing is logged anymore with those settings.
I too had this issue and it was fixed with “output_power: 8.5dB”
However, this note is to let others know that I had to clean the build files before the change stuck.
And in fact some other persistent issues were only resolved after blowing away the device and starting fresh.
Note that wifi power values are logarithmic, so reducing decibels by small amount will drastically reduce actual wifi power:
10dB = 10mW
11dB = 12.5mW
12dB = 16mW
13dB = 20mW
14dB = 25mW
15dB = 32mW
16dB = 40mW
17dB = 50mW
18dB = 64mW
19dB = 80mW
20dB = 100mW
so, 8.5db is very small power! Personally i would never go below some 15dB and even that is already only 1/3 of max power… and, to be honest i don’t see any practical value of reducing wifi power… (except perhaps if module is battery powered)
In these cases it’s no voluntary reduction, but to ‘fix’ the misdesigned antenna setup of these devices. I have two of those myself, if you don’t artificially restrict the tx power these won’t connect (or at least take ages and still drop out regularly) - after restricting it they do operate without problems.
And yes, even for non-broken devices restricting txpower does make sense, as it improves roaming and general noise (if your neighbours would do the same…); a megaphone doesn’t do much good on the dinner table either. But again, that’s not the issue here.
2 Likes
Just wanted to contribute to this thread that I started encountering this issue today, on 2 separate esp8266, after reflashing the firmware after upgrading esphome to 2025.10. I rolled it back to 2025.3.3 and reflashed, and the wifi connected immediately. So something’s been changed along the way
I rolled
1 Like
Adding “update_interval: 2s” worked for me as well with 3 esp8266 devices with SSD1306 OLED displays, thank you
1 Like