My experience is exactly the opposite.
I also reported several times this issue, but nothing is performed to solve or mitigate the problem. Usually my device are off for some seconds, but I never had any issues triggering any action. For me the simplest solution would be having a configurable timeout parameter to give the node as unavailable. My history is a mess due to this bug. Regarding tasmota is rock solid, never had any issues and I have nodes deployed for years… I only use esphome because is easier to setup, but then I have this downside. This bug was introduced long time ago, because when I started esphome was really rock solid in terms of WiFi stability.
Well, it may be the something in the ESPhome stack, but it could also be something in the ESP-WIFI (Expressif) stack. Or maybe the WIFI network itself is (routers and AP’s) cannot handle the amount of devices or traffic.
But I would like to have tools to rule some of these options out.
1 Like
Since I’m using ubiquiti routers, and no issues happen on tasmota devices, is something on esphome stack.
I have a similar problem with xiaomi bedside lamp 2 with esphome (GitHub - mmakaay/esphome-xiaomi_bslamp2: ESPHome integration for the Xiaomi Mijia Bedside Lamp v2.). This only happens when lamp’s controller is highly loaded with algorithm for picking random colors and transitions. On older build it was disconnecting exactly every hour, but with the newest it’s random and ranges from 25 to 45 minutes. I’m pretty certain there is a bug in ESPhome causing this.
@jmvaz Don’t assume that your issues are unrelated to Ubiquiti network hardware… They have tons of bugs and issues constantly. I have been running UDMP, a dozen of their switches, and 5 of their relatively recent APs (LR6, AC-HD, AC-PRO) and cannot count the number of issues.
I was reading this thread as I was trying to figure out why a couple of my ESP devices with mmWave motion sensors were showing unavailable for 1s at exactly the same time multiple times last night (new devices I just built so not much prior history). Since they go offline and back in 1s at exactly the same time leads me to believe the issue is with Home Assistant or the Unifi stuff. I have 15 or so ESP devices running and did not check whether they all suffered from the same disconnect yet… I only checked the ones with mmWave sensors as I am troubleshooting them for false triggers issues.
Ok, then try to explain me why all my other devices from tasmota, esp8266 (home made devices), they keep connected months without any issues. I have 60 devices in the network, only the 10 esphome devices have this behaviour.
Don’t you think is too much coincidence? When I started with esphome, this issue was not happening at all, only after one upgrade it started to behave like that.
@jmvaz I did NOT say it was not esphome’s fault… all I said is that you should NOT assume that since you use Ubiquiti equipment, that it can’t be the cause. My Unifi equipment has given me hell, and their forums are full of constant issues. Don’t get me wrong, I enjoy their hardware, but the software seems to be in a never ending beta, and sometimes they replace hardware with new versions without even having finished a feature complete non beta firmware.
I believe you mentioned you use the Ubiquiti Amplifi line configured using mesh. I would not call that line “commercial grade” as it is meant for home users however it likely shares some DNA with the higher grade solutions they offer. With that I mean that it is likely better than the typical routers but given Ubiquiti can’t get their act together on the commercial stuff, I suspect there are issues in that line too. In general, I would avoid mesh wifi networks. Try to run cables to your APs for better reliability even though it is not your issue here.
Comparing Tasmota and other devices to esphome is not as easy as you make it. They all care differently, and report differently, about their connectivity. For example, I have a couple ecobee thermostats that get kicked off the network by the Unifi APs and the only reason I know is the annoying Alexa uber long message saying she can’t reach servers otherwise the ecobees don’t seem to even report the issue (short-lived so maybe under their subjective threshold). It could be that Tasmota has a different threshold / logic to report the disconnection for example. If the esphome disconnections show up in the AmpliFi dashboards, see if any other devices also drop off.
I believe that esphome etc. depend on mDNS… up until a few months ago maybe a bit more, Unifi had broken mDNS for years… I had to hardcode the IP of all my LIFX bulbs as otherwise they would appear offline due to a bad mDNS implementation by Ubiquiti. The bulbs would keep coming and going as they pleased. Now it is rock solid. I wonder whether the shared DNA includes bugs too 
Are all the esphome devices you have home made and based on 8266 ? If not, do you have the same issues with ESP32 (which I have read has more reliable WiFi)?
Also, did you check the timestamp of when the devices go unavailable to see if they match the others? In my case multiple esp8266 and esp32 go unavailable at the same exact time… it could be a network issue or an ESPhome / Home Assistant issue. Maybe what you are seeing too.
EDIT:
The smoking gun in HA’s logs:
2022-10-15 03:31:58.930 WARNING (MainThread) [homeassistant.components.unifi] Lost connection to UniFi Network
There are lots more errors that minute and all are related to a network issue. Ugh!
I only have one esp32 with esphome and on that device the problem doesn’t exist. Only with esp8266. All my esphome have the fixed IP configured, but hasn’t a successful workaround for the issue.
All my homemade devices uses the homie library for wi-fi setup and mqtt connection, they are all esp8266 and never experienced any communication issues, and they remain connected for months.
All my mesh points are wired, there is no wi-fi communication to extend the network. I even already tried to create a specific network, on a specific access point just for the nearby nodes, but the problem remains the same.
The downtime never was a issue for me, because I never had any problems in that regard. Was really buzzes me if the logs from this devices, where I can see more unavailables than state changes. 
Another example:
The timestamps are different, so most likely it wasn’t a temporary glitch from the network.
This constant connect/disconnect cycle was happening on one of my esphome nodes. I noticed that the compiled download file got significantly bigger in the latest releases. I removed some unneeded features and updated the node and now the file size is smaller and no more re-connects.
@fantangelo Did you remove the Bluetooth proxy? It was my understanding that they were going to add it by default, but I may be wrong, and actually hope I am. What did you disable and how? I’d like to try too.
@jmvaz The time the devices go unavailable appears to be close but not identical. Are you using a high or low powered CPU for HA? In other words, is HA running on a RPI or a PC CPU? The reason I ask is I wonder whether ESPHome is taking the devices offline while it does something and the delay between devices varies potentially by how powerful the machine running RPi is. Mine is running on an old i7-8700.
@fantangelo Are your ESPs all dropping off at the same exact time? Mine are within seconds of each other.
Just found this…
It has a whole section on disconnections
I use an hp mini Intel i5 with 8gigs and SSD full dedicated to homeassistant.
Pretty familiar with that page.
I had two out of 12 esp nodes that kept rebooting. I never really measured the exact time intervals. On one of them I disabled ‘logger’ and on another one I removed a HX711 weight sensor that I didn’t need. After that both esp nodes worked reliably. My approach was to make the bin file size as small as possible. I never did enable bluetooth proxy on either one.
@fantangelo Interesting… so how “busy” the ESP device is could be a factor in it dropping off? I noticed this issue on a couple ESP 8266 Wemo D1 that I am working on. One has 4 sensors (3 are on a single chip) and the other has 7 (3 with at least 2 sensors on their chip). The 4 sensor one is deployed and I discussed it here:
The code itself is pretty basic and I too disabled the logger, or at least I think I did with this:
logger:
baud_rate: 0 #disabled
If you open the wireless logger from the ESPHome page, they output tons of logs though but I am guessing that is only active when the window is open, right?
I think that in my case it was a matter of the compiled filesize being borderline too big. The OTA updates completed successfully but I had these frequent restarts. When I made the filesize smaller by removing some sensors then everything was smooth again.
I disabled the logger by commenting it right out. ie #logger:
It means that I cannot see the online logs of the node but at least it does not reboot.