same device, but after a while it re-start to have troubles.
I am not saying reflashing makes the trick, just saying there is something strange between HA and ESP32 connection status.
It also happens with ESP8266 to be honest
I just reflashed my original ESP32 and it still has the problem. Putting back the alternate, same binary, problem gone.
do you have same power supply in your tests between the two ESP?
I had this issue (ESP32 only) and found that it was due to GPIO I was using that were also used by the WiFi chipā¦ changed GPIO and no more issues.
ADC2 (and WiFi in ESP32) uses GPIOs 0, 2, 4, 12 13 14 15 and 25 26 27
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/adc.html
The table on this page lists the best ESP32 GPIO to use:
And for the ESP8266
3 Likes
Hi everyone,
I had the same problem with ESPHome as wel on Tasmota with all my Shelliesā¦ But not anymore 
In your acces point (this fixed my tasmota, but not yet the ESPHomes):
- Set your wifi to 20mhz only, so no auto 20/40mhz
- Set an fixed channel, again not autoā¦
In Esphome:
esphome:
name: "${ippostfix}_${devicename}"
platform: ESP8266
board: esp8285
arduino_version: 2.4.2
# WIFI settings
wifi:
fast_connect: true
reboot_timeout: !secret wifi_reboot_timeout #= 45min
power_save_mode: none
networks:
- ssid: !secret wifi_ssid
password: !secret wifi_password
ESPHome add-on: is only running when i want to do changes (read it in this thread, donāt know if it helps or not)
The ESPHome yaml part is probably not all necassary, but hey it worksā¦
Iām interested if any one here which had this kind of connection losses with 1.14.x does expierence this ones too on the most recent beta 1.15.0b3. It has quite some fundamental changes bumping for example the arduino core to a very recent version (which introduced a new bug to quash actually 
)
Would be nice if you could test and report back. If you still have troubles best would be to directly catch some logs and open a new issue mentioning you are using 1.15.
I have no troubles so far with the 1.15 beta (can be easily installed in parallel to stable and dev with the hassio addon 
)
1 Like
Hi, I solved my problem by buying a new router, I connected all ESPhome devices to a separate SSID. For 2 days I have never lost the connection. Previously, there were 20-200 connection losses per day.
How is HA connecting to the EspHome nodes if they are in two separate subnets?
You can do this - you need an AVAHI reflector on both subnets so that the mDNS requests can be seen
Craig
1 Like
I had a major issue with esp8266 and esp32 devices dropping significant number of packets. My laptop as well but not nearly as bad. If I took the esp devices to a different part of my house, the problem stopped. Took me quite a bit of troubleshooting but I after loading a wifi analyzer on my phone, I noticed this device broadcasting low power then higher power and higher and higher every 30 seconds or so. When it got closer to the higher power the esp devices started dropping off the network and my laptop showed low WiFi signal.
I narrowed the signal down to my bedroom. The only wireless device in there is my Roku 3. I started doing some research and found that certain roku devices will broadcast higher and higher signals while attempting to contact the AP. Then it dawned on meā¦even though that Roku was hard wired now, it was connected to an old SSID that I retired a month or so prior. It was trying to find that old SSID for some reason and was drowning out the ESP devices as well as my laptop. I connected it to the new SSID then back to Ethernet and the problem was instantly resolved.
Yesterday I set up a brand new Gosund SP-1 plug with the latest ESPHome 1.14.x (using the API, not MQTT), and I also experienced disconnections to both Home Assistant and the ESPHome log viewer constantly, with each connection lasting no more than 3 minutes in general.
I tried several things, including changing the WiFi SSID (I have 2 access points, but this happened with both), WiFi power mode, etc.
Today I saw @orange-assistantās answer, and tried flashing ESPHome 1.15.0b3 to see if that would work. As of now, I havenāt had any disconnection and the plug works wonderfully!
Image: The disconnections can be seen throughout the status bar. After flashing the beta release, you can see the switch status stays in the āonā position without being disconnected.
So, at least for me, it seems like some recent change has fixed these issues.
Iāll post another update here after some time has passed, so I can tell you how everything went, and whether the problem came back.
1 Like
Sorry, but it looks like I jumped to conclusions, the problem remains, but it appears much less often.
Iām on the some boatā¦ a lot of disconnets in the api when using ping to the device everything is ok
This is affecting me too. Driving me absolutely up the wall, tried everything from changing WiFi channels, widths, APs, different versions of HA, different versions of ESPHomeā¦ Yet still I get this:
The crazy thing is I can watch the ESPHome logs over WiFi while home assistant for some reason just keeps disconnecting and connecting.
FWIW Iām on RPi4, Docker (raspberrypi4-64-homeassistant).
Hi guys,
i ran into this too and can share my experience.
EspHome (or sonoffā¦not sure what is the root cause) are very sensitive to broadcast traffic which causes disconnections you see above.
Few suggestions:
-
Turn Off EspHome while not using it, it creates a lot of mDNS traffic
-
Use āpingā instead of mDNS in EspHome add-on configuration to check online status of esphome devices
-
if you use MacOS device this is creating troubles: I have a MacMini I use as a desktop PC, when on I have disconnections, when Off I donāt (not sure if this is releated to mDNS/bonjour)
-
check with wireshark (TShark is perfect option if you have an RPI) if you have any unwanted mDNS/broadcast traffic source (I had a FingBoxā¦and this was hampering connection stability A LOT)
-
Check if you have any device with poor WiFi signal (even if the device is completely not releated to your IoT enviroment): if it on the same SSID of your esphome devices it could reduce their available airtime and lead to disconnections (try to turn it of, wire it to ethernet or improve wifi signal)
Thanks for the response mspinolo!
Iāve turned off every other SSID on 2.4ghz, and now only ESPHome devices are running on this SSID.
They have now been assigned static IPs in their configuration files.
With static IPs, there shouldnāt be any mDNS issues, right?
Not using the ESPHome add-on, just run docker on my laptop for creating and uploading the firmware so ESPHome is never running apart from during uploads.
I would say itās related to WiFi performance, but a Sonoff Basic right next to the router is also experiencing this.
With static IPs, there shouldnāt be any mDNS issues, right?
what is governing mDNS traffic is if the list of devices on the same LAN segments.
So actually even wired devices can send mDNS traffic to Esphome device.
Also EspHome is designed to be a server per every single device so also every device is sending mDNS packets (but not much, there is a pull request to revert this behavior if I am right)
I would say itās related to WiFi performance, but a Sonoff Basic right next to the router is also experiencing this.
consider that even if you have a device with -30dB RSSI @ 1m in free air from the AP its connection performance can be affected by another device with poor signal sittina far from the AP which is consuming airtime
I see, a lot to take in and so many variables! I thought it could have been to do with the migration from my Pi 3b+ to a Pi 4 but I doubt this is the case as itās connected over ethernetā¦
I did run a tcpdump on my router for the 2.4ghz interface and this entry (13:34:10.570627) stuck out among all the others. It was at exactly 13:34:10 that the device flicked between Unavailable and Offā¦ Really not sure what that could meanā¦ Any ideas?
13:34:09.081227 IP 192.168.42.1.41238 > 192.168.42.84.6053: Flags [P.], seq 36:39, ack 37, win 64056, length 3
13:34:09.095478 IP 192.168.42.84.6053 > 192.168.42.1.41238: Flags [P.], seq 37:40, ack 39, win 1871, length 3
13:34:09.095725 IP 192.168.42.1.41238 > 192.168.42.84.6053: Flags [.], ack 40, win 64056, length 0
13:34:09.101703 IP 192.168.42.1.58138 > 192.168.42.81.6053: Flags [P.], seq 36:39, ack 37, win 64068, length 3
13:34:09.115007 IP 192.168.42.81.6053 > 192.168.42.1.58138: Flags [P.], seq 37:40, ack 39, win 1871, length 3
13:34:09.115235 IP 192.168.42.1.58138 > 192.168.42.81.6053: Flags [.], ack 40, win 64068, length 0
13:34:10.541290 IP 192.168.42.1.60512 > 192.168.42.86.6053: Flags [F.], seq 36, ack 34, win 64055, length 0
13:34:10.542850 IP 192.168.42.86.6053 > 192.168.42.1.60512: Flags [.], ack 33, win 2045, length 0
13:34:10.570627 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [S], seq 4023924904, win 64240, options [mss 1460,sackOK,TS val 142272440 ecr 0,nop,wscale 7], length 0
13:34:10.573618 IP 192.168.42.86.6053 > 192.168.42.1.32872: Flags [S.], seq 21715, ack 4023924905, win 2144, options [mss 536], length 0
13:34:10.573883 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [.], ack 1, win 64240, length 0
13:34:10.577419 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [P.], seq 1:28, ack 1, win 64240, length 27
13:34:10.595575 IP 192.168.42.86.6053 > 192.168.42.1.32872: Flags [P.], seq 1:38, ack 28, win 2117, length 37
13:34:10.595870 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [.], ack 38, win 64203, length 0
13:34:10.597835 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [P.], seq 28:31, ack 38, win 64203, length 3
13:34:10.613394 IP 192.168.42.86.6053 > 192.168.42.1.32872: Flags [P.], seq 38:41, ack 31, win 2114, length 3
13:34:10.613599 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [.], ack 41, win 64200, length 0
13:34:10.615797 IP 192.168.42.1.32872 > 192.168.42.86.6053: Flags [P.], seq 31:34, ack 41, win 64200, length 3
Where 192.168.42.1 is the ESPHome installation and 192.168.42.86 is an ESPHome device with a static IP assigned in the wifi: component.