Title says it all. ESPhome devices drop off 2.4GHz wifi and cannot/won’t reconnect.
Something about Asus AImesh and RT-AX88 routers/access points?
Router firmware version is release 388.
Maybe it’s an Arduino framework issue?
FYI: TP-Link light switches and Ecobee3 thermostats are also impacted. 
What logs of ESP say when it disconnect and don’t succeed to reconnect ? have you tried using standard configuration for Wifi if not already the case on Asus system ?
I have AiMesh with TUF-3000 V2 and AX-55.
I suggest to set fixed IPs in the router and the devices also, that’s what helped me a lot and also for fast connecting. I use hidden SSID for 2.4Ghz and AES/WPA2-Personal, works well with all my ESPhome devices. SSID with a whitespace and password with numbers, capital and small characters.
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_pass
power_save_mode: none
fast_connect: true
manual_ip:
static_ip: ${ip}
gateway: 192.168.0.1
subnet: 255.255.255.0
HTH
@vincen To obtain logs from the ESPHome devices, I’d have to take a laptop to the devices or remove the devices from their locations. Neither of these is a practical option.
@PeterCicaMolnar Thank you for the suggestion of assigning static IP addresses. I used static addresses when I first began using ESPHome some years ago, and eventually switched to all DHCP assignments. I’d hate going back to static IP addressing, but it may soon become a necessity. Also, when the WiFi connectivity is so problematic, loading new firmware over the air becomes almost impossible.
Please understand, many of these devices have worked wonderfully for months or years using wifi. Only after some recent wifi change somewhere (either in the ESPHome or Arduino platforms, or in the Asus AX routers) did things begin to go wrong.
Home Assistant without reliable sensors is NOT a good situation. 
I was in the same boots 
I’ve switched from 1 AX-55 single router to AiMesh. I had to tweak many things and I had to play for mor than a week… 
Finally fixed IPs helped a lot with connecting and reconnecting.
Also I suggest to have a look on my 2.4GHz settings:
I understand but without logs it’s going to be very difficult to find out the issue… good luck
In my experience, esp8266 is easy to drop after crossing a wall, especially those with poor power supply chips. Plus the router problem affects. Later, after replacing the esp32-c3 such chip, get a lot of relief. esp32, esp32-s2 also seem to have improved the signal
Airtime Fairness option seems to help with some relief.
I have successfully resolved the issue. Pulled the router and each AImesh access point, wiped their version 388 firmware, and reloaded the prior 386 version of Asus AImesh firmware to each device. At this point, the network and all my sensors and light switches and thermostats are back online and stable. They’ve been stable for hours now, and I hope for it to remain that way until Asus and/or Broadcom acknowledge their problem.
This issue can be characterized by these messages repeating in the router syslog:
Jan 3 20:08:54 wlceventd: wlceventd_proc_event(539): eth4: Auth 44:23:7C:4C:A6:0F, status: Successful (0), rssi:0
Jan 3 20:08:54 wlceventd: wlceventd_proc_event(568): eth4: Assoc 44:23:7C:4C:A6:0F, status: Successful (0), rssi:-52
Jan 3 20:08:54 wlceventd: wlceventd_proc_event(503): eth4: Deauth_ind 44:23:7C:4C:A6:0F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
It may be asus firmware issue as the solution implies. I have two Zen wifi XT8 and one rt-ax68u. The issue only seems to affect a few of my esp8266 nodes and not esp32 ones.
Restarting wireless on the router respolves the issue, rather than do that through the web ui which seems to be more disruptive to othe clients you can restart wireless on the router via shell command from an automation that calls ssh to do it:
shell_command:
restart_wireless:
ssh -i /config/ssh/id_rsa -o ‘StrictHostKeyChecking=no’ [email protected] /sbin/service restart_wireless
This need your ssh certificates etc or you can embed the password. This way you dont need to hard reset your router and load older firmware and stay on it for ever.
Really this needs resolving by Asus, its been an issue since f/w 388. I will collect a wireshark trace and submit a ticket
Hi - nice catch, i just checked and the same on my end. I only have 1 problematic tasmota - on a shelly 1 -, but it is painful as heating is depending on it. And thanks for the tip, i hope this will be solved very soon.
I’M also struggling with my ASUS AImesh system and 2.4ghz networking.
It is perfect on anything that is fine with 5ghz, but so unpredictable with 2.4
Im watching this thread, if you have any more successes… I haven downgraded yet, but that might be next.
I just switched my 2.4 GHz wireless back to Legacy mode and everything is back online for the first time in a long, long time.
I actually pulled an old N66U (running Merlin FW) out of a box, fired it up as a dedicated 2.4Ghz AP, and everything is perfect. So now best of both worlds
I had success adding this to the yaml for connectivity:
esphome:
name: ${device_name}
min_version: 2022.10.2
on_boot:
priority: 300
then:
lambda: |-
WiFi.setPhyMode(WIFI_PHY_MODE_11G);
THANK YOU! Works flawlessly
I’ve tried EVERY potential solution on this issue, and nothing worked.
Sets the WiFi radio phy mode. Argument is an enum of type WiFiPhyMode_t, valid values are: -
WIFI_PHY_MODE_11B: 802.11b mode -WIFI_PHY_MODE_11G: 802.11g mode -WIFI_PHY_MODE_11N: 802.11n mode
So while everybody was trying to get the right settings at the router to handle this old 802.11b mode, the ESP8266 simply supported G and N. We just had to ask, like @nschimme did 
I now even have power_save_mode: high enabled.
This is the way. Thank you very much!
I use an RT-AX88U with an RP-AX58 (AiMesh) and had problems connecting - setting phy mode fixed it.