@doubledutch Can you try this update_interval
from this
display:
- platform: lcd_pcf8574
id: my_display
dimensions: 20x4
address: 0x27
to this
display:
- platform: lcd_pcf8574
id: my_display
dimensions: 20x4
address: 0x27
update_interval: 2s
Hi @Blacky - done and in the one re-start that I did, it worked perfectly. Wifi connected straight away with no Auth Expired.
Could you explain why that may be?
I will monitor and provide more feedback if I receive it and thank you so much for your help!
Default is 1s so we just gave it time so it can make wi-fi connection.
you should be good to go now 
after you monitor it and find this has resolved it make sure you mark it solve so others and jump directly to the solution. 
Will absolutely do so. Thanks again!
@Blacky tried resetting the unit a few times and it worked every time so “Solution” is updated in this post and thanks again for your help.
I just read here: SSD1306 breaks wi-fi - #3 by jsuanet that someone had similar problem with SSD1306. One of reccomended solutions there was also to increase I2C frequency - you can try that, too.
Wow thanks for this hint 
I have the same problem with my Wemos D1 mini v3.0.0 and I can confirm that the I2C frequency hack works.
It doesnt matter if you use I2C or not but adding these lines made wifi work again:
i2c:
sda: GPIO3
scl: GPIO1
frequency: 800kHz
This problem also accoured only for the v3.0.0. I generally use the v2 wemos boards and none of them had this issue.
Thanks for this! It’s solved my wifi connection issue but now does mean once connected the display refresh is a bit slow. This is normally fine but my screen is reacting to a rotary encoder (with possible gif) so I could do with it being speedy. Is there a way to say “once connected drop this back to 1s” at all?
Edit… For anyone looking for the answer to my post. This is what works for me and allows me to have a display refresh rate of 0.1s. For some reason I still needed the frequency bit, even with the wait on boot.
esphome:
name: "blah"
on_boot:
priority: 200
then:
- wait_until:
condition:
wifi.connected:
timeout: 5s
# Display
i2c:
sda: D7
scl: D6
frequency: 200kHz
I had this, and fixed it, by connecting the ESP to a 2.4 GHz network and selecting “Legacy” wireless mode on my router (which is an Asus ZenWiFi AX). My hypothesis is that the WiFi driver is incompatible with one of the 802.11 a/b/g/n/ac protocols.
WOW !!!
It´s works for me too.
I´m having trouble with I2C SH1106. With display plugged, wifi can´t connect.
With your code, works !!!
Thaks
Hi, do not understand the solution flagged?
does this solve the wifi auth expired?
I assume not.
having also same error but no no i2c device, not even any
I recently encountered this sort of issue when making some network changes. All of a sudden 3 esphome devices and 3 tasmota plugs started having connectivity issues. Each esphome device would spew out various “auth expired”, “4-way handshake timeout”, “authentication failed”, “probe request unsuccessful” and other wifi errors.
After trying a bunch of recommended fixes and getting nothing working, I realized that my router had automatically changed to channel 11, near the end of the range. Seeing as some people mentioned noise/interference causing these issues, I tried changing this to channel 5, closer to the middle of the road, and suddenly all of the devices stopped having issues. So, I’m pretty sure that’s part of the problem.
Did anyone get a solution for this? Got another pack of ESP32-S2 (S2 Mini) and could not get them to connect to Wifi because of “Auth expired” errors…
I had this issue and determined mine to be caused by band steering on my wifi/router. That is when the 2.4 Ghz wifi delays its response to your esp32 so that the 5ghz can respond first and try to get you to associate there instead. Unfortunately I could not turn this off on my wifi router but was able to work around it by specifying the BSSID to connect to in the esphome wifi config. And used the BSSID specific to the 2.4 Ghz radio along with fast connect setting.
Ended up ditching that router/wifi though after a while and getting something else.
Could you share this code?
I’ve read this thread and I am having the same problem but I have an ESP32 dev board so the solution isn’t applicable to me.
any suggestions?
substitutions:
device_name: multisensor-tvroom-01
friendly_name: multisensor-tvroom-01
esphome:
name: ${device_name}
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "key"
ota:
password: "password"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: ${device_name}
password: "password"
captive_portal:
# Motion Sensor Configuration #
sensor:
- platform: adc
name: motion_one ${friendly_name}
pin: 36
update_interval: 250ms
- platform: adc
name: motion_two ${friendly_name}
pin: 35
update_interval: 250ms
# LED Configuration
output:
- platform: ledc
id: output_component1
pin: 25
- platform: ledc
id: output_component2
pin: 33
- platform: ledc
id: output_component3
pin: 32
- platform: ledc
id: output_component4
pin: 18
- platform: ledc
id: output_component5
pin: 19
- platform: ledc
id: output_component6
pin: 21
# RGB Configuration
light:
- platform: rgb
name: led_one ${friendly_name}
blue: output_component1
green: output_component2
red: output_component3
id: led_one
effects:
- strobe:
- strobe:
name: strobe1
colors:
- state: true
brightness: 80%
red: 0%
green: 0%
blue: 100%
duration: 750ms
- state: false
duration: 250ms
- state: true
brightness: 50%
red: 100%
green: 100%
blue: 100%
duration: 750ms
- platform: rgb
name: led_two ${friendly_name}
blue: output_component4
green: output_component5
red: output_component6
id: led_two
effects:
- strobe:
- strobe:
name: strobe2
colors:
- state: true
brightness: 80%
red: 0%
green: 0%
blue: 100%
duration: 750ms
- state: false
duration: 250ms
- state: true
brightness: 50%
red: 100%
green: 100%
blue: 100%
duration: 750ms
# Turn off board status LED #
- platform: status_led
name: Switch state ${friendly_name}
pin: GPIO2
bluetooth_proxy:
active: true
I cured it on one of my devices by giving it a fixed IP address. Not had a problem with it since although it does not show on my DHCP list.
I have had the same problem with a Wemos D1 ESP32 board very useful to reuse the shields of the Wemos D1 Mini.
But when connecting I always got the same error
Auth Expired or Authentication Failed
After several tests I have realized that so that it does not disconnect, the logger line must be commented out
This has worked for me so far. In case it helps someone.
Not relevant to Mini discussed above, but may help someone with Auth Expired problem on a bigger board that is suposed to be powered via DC barrel jack.
I had the same errors on WeMos D1 R32 (ArduinoUno-ish board with ESP33 and barrel connector for 5-12V power source)
Found this thread and tried to play with fixed IP, channel, etc. But nothing helped.
No matter what I was doing to the yaml - I was getting Auth Expired errors when it reboots after flashing.
Turned out that when this board is powered via Micro-USB port - it gets enough power to flash ESP32, but not enough power for it to work in the normal mode. Basically it was browning out after flashing and rebooting, while still connected to my laptop’s USB.
As soon as I disconnected it from usb and plugged it with 12v power adapter - it happily connected to WiFi. It has been working stable for multiple weeks since then.
Hello! I just dealt with a similar problem with ESP32 and Dallas sensors. Thanks my friend for the advice.
When used with an ESP32, Dallas sensors must be powered strictly at 3.3V, not 5V. If you use 5V, the chip is overloaded and gives 'Auth Expired' error.
