Oh, I don’t think it means losing wifi connection, I think it’s when it loses connection to the Home Assistant API. (At least that’s the way I interpreted it)
Mine still does it intermittently, but doesn’t really affect operation, so I’ve learnt to live with it until they fix it.
Ahh okay, it was the last bullet point that must’ve made me interpret it that way. For what it’s worth it’s all stable for the last hour since I posted, before this one node was reconnecting every 2 minutes or so!
what did you do to make it more stable? (if confirmed to be more stable 
)
My setup is windows based and I have found the asyncio
https://github.com/esphome/aioesphomeapi/blob/892ee4d80650a2e822e30577336fa9812cd39f8a/aioesphomeapi/connection.py line 50, await asyncio.sleep(self._params.keepalive) settings have impact on the timeouts . Doing experiments with different time settings of the self._params.keepalive parameter by adjusting it to 300 ms is optimal, I found this affected the timeouts (higher or lower values worses timeout), I had repeatedly timeouts regarly every 2 to 4 hours before but after experimenting with this parameter the timeouts almost disapeared. This parameter has impact on asyncio parallell operation. What do you think?
Interesting!
It would be interesting to raise it to a ESPHOME developer: did you open a feature request/github issue about it?
I too have been suffering from this and so far no permanent fix.
I have found that reflashing my ESP32 (which seems to suffer most), for example, with the same ESPHome compile does solve the problem for a considerable time. Stopping and restarting does not, however. All will be fine until I have a network outage. Then I’m likely to get the problem again, though not guaranteed.
I use Home-Dashboard as a simple HA user interface (which, IMHO is excellent) and I’ve noticed that it too seems to periodically have the same problem connecting to the HA API, that I assume it uses.
I’m just throwing this out there as a possibility that the issue isn’t the ESPHome devices but the HA API.
I don’t have the skills to investigate this or suggest solutions but thought I’d add my experience into the mix as I, like others here, really need a solution.
The asyncio is complex, I am in a learning phase, there are several videos in youtube describing asyncio functions, there are also similar functions in the esp os that handle asyncronous operations. It is about how the system manages parallel tasks. I wrote to the designer Otto W about it but no response yet. I think more investigations about the functions is needed since it is a complex problem.
This is a long thread so apologies if this has been mentioned already but I fixed my BLE connection issues by compiling for an earlier version of arduino, viz;
esphome:
name: ble_lounge
platform: ESP32
board: wemos_d1_mini32
arduino_version: 1.0.3
Hopefully 1.0.5 will fix the problem.
My Esphome Nodemcu 1.0 board is somehow far to the APs, it only gets the signal about 60-70% (Unifi data). Somedays its all stable, somedays having disconnects-reconnects every 10-15 minutes apart. I was using DHCP on yaml, but assigned IP on Unifi. So i made the yaml static IP to check. Now the disconnects are (mostly) only 1 sec long.
The funny thing is, i have only 1 esphome component, but about 4 Sonoff Tasmota in my installation; whenever esphome starts having disconnection problems, all Sonoff Tasmotas start having the same behaviour too. Before using esphome, Sonoffs were very stable, not even one disconnect. Btw, the Sonoffs and esphome connects to two different unifi APs with the same SSID name and on the same network.
Now i wonder, could it be something related to mDNS? I guess Tasmota uses mDNS by default too. On ESPHome Wiki:
ESPHome uses mDNS to show online/offline state in the dashboard view. So for that feature to work you need to enable host networking mode
On Tasmota " SetOption55=Off" disables mDNS off. I think i am gonna try this on Tasmotas at least to understand if the real problem is with mDNS. Feature Request: mDNS default off. And i guess this won’t be possible with ESPHome.
UPDATE: Urrrggh. I learned about this Fingbox mDNS flooding problem and making IOT devices disconnect only recently. Now i unplugged my Fingbox and will try this way. I also had a lot of disconnection problems on Apple Airport Express Airplay; i hope lack of Fingbox will solve both problems. Fingers crossed…
Hi,
I confirm mDNS traffic leads to a lot of issues on esp32/8266 and ESPHOME.
I am not sure if it has anything to do with ESPHOME or is ESPs themselves but my shellies (esp8266 based, stock firmware) are much more solid)
On ESPHOME behavior is consistent and happening more often on devices with lower signal quality.
I am not a network expert but I suspect it has something to do with the poor wifi bandwidth ESPs have which makes them dropping connection.
Also ESPHOME devices act as servers and if you perform a wire shark log you will see they broadcast packets which by my (poor) understanding is not ideal.
Hello Everyone!
I seem to have the same issue that you are all describing here, and it seems to be affecting my whole 2.4 GHz Wifi stability. I have around 20 ESPHome devices there - mix of ESP32 (4 of them Wired), Shellys and Sonoff devices + BlitzWolf and Avatto plugs - and depending on their Wifi connection quality they can disconnect from once a day to few times an hour.
I read a few workarounds here, like turn off ESPHome in HA when you don’t use it - but I suppose HA can’t communicate with the devices then right? Is fixing the IP solving the disconnection issues as well?
No it does not fix anything having fixed IP: it is just speeding up the re-connection after disconnects as esp doesn’t need to negotiate IP address with DHCP server
You don’t need esphome running for an esphome device communicate with home assistant.
For what it’s worth, I was having issues with ESPHome devices disconnecting all the time, but since upgrading from my RPi 3B+ running HA over wifi to a bottom of the range NUC over wired LAN, I have had none of those issues at all after a week.
Just one more datapoint - blocking my mdns reflector resolved this issue for me. This issue has plagued me for months and months. My esphome sensors going unavailable every few minutes for a few seconds to a minute. I tried the proposed fix to change my wifi AP channel width from 40MHz to 20MHz. This helped initially, but the problem returned. I realised that any restart on the AP interface resolved the issue for 30 seconds up to 10 minutes.
After reading the suggestions here, I removed my IoT subnet from the domains list of my mdns reflector (avahi-daemon). This has completely resolved the issue for me. Ie, removing (or significantly reducing) mdns traffic from the wifi network (ssid) of the esphome devices.
For me reducing the log level to“INFO“ was the solution, now the WiFi connection is stable.
I have the same problem.
My devices are connected to wifi normally, however they show as offline only on HomeAssistant.
I am in the latest version of the firmware.
INFO Reading configuration /config/lab.yaml...
INFO Detected timezone 'TZ' with UTC offset -3
INFO Starting log output from lab.local using esphome API
INFO Connecting to lab.local:6053 (xxx)
INFO Successfully connected to lab.local
[12:03:25][I][app:105]: ESPHome version 1.16.2 compiled on Apr 2 2021, 15:52:20
Yaml? Full log?
INFO Connecting to switch_bedside_01.local:6053 (192.168.68.102)
INFO Successfully connected to switch_bedside_01.local
[12:24:23][I][app:105]: ESPHome version 1.16.2 compiled on Apr 14 2021, 12:22:45
[12:24:23][C][wifi:443]: WiFi:
[12:24:23][C][wifi:303]: SSID: [redacted]
[12:24:23][C][wifi:304]: IP Address: x.x.x.x
[12:24:23][C][wifi:306]: BSSID: [redacted]
[12:24:23][C][wifi:307]: Hostname: 'switch_bedside_01'
[12:24:23][C][wifi:311]: Signal strength: -63 dB ▂▄▆█
[12:24:23][C][wifi:315]: Channel: 9
[12:24:23][C][wifi:316]: Subnet: x.x.x.x
[12:24:23][C][wifi:317]: Gateway: x.x.x.x
[12:24:23][C][wifi:318]: DNS1: x.x.x.x
[12:24:23][C][wifi:319]: DNS2: x.x.x.x
[12:24:23][C][uart_esp8266:075]: UART Bus:
[12:24:23][C][uart_esp8266:080]: RX Pin: GPIO3
[12:24:23][C][uart_esp8266:081]: RX Buffer Size: 256
[12:24:23][C][uart_esp8266:083]: Baud Rate: 4800 baud
[12:24:23][C][uart_esp8266:084]: Data Bits: 8
[12:24:23][C][uart_esp8266:085]: Parity: NONE
[12:24:23][C][uart_esp8266:086]: Stop bits: 1
[12:24:23][C][uart_esp8266:088]: Using hardware serial interface.
[12:24:23][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'switch_bedside_01 touch top'
[12:24:23][C][gpio.binary_sensor:016]: Pin: GPIO0 (Mode: INPUT_PULLUP, INVERTED)
[12:24:23][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'switch_bedside_01 touch center'
[12:24:23][C][gpio.binary_sensor:016]: Pin: GPIO9 (Mode: INPUT_PULLUP, INVERTED)
[12:24:23][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'switch_bedside_01 touch bottom'
[12:24:23][C][gpio.binary_sensor:016]: Pin: GPIO10 (Mode: INPUT_PULLUP, INVERTED)
[12:24:23][C][switch.gpio:042]: GPIO Switch 'switch_bedside_01 button 1'
[12:24:23][C][switch.gpio:043]: Pin: GPIO12 (Mode: OUTPUT)
[12:24:23][C][switch.gpio:059]: Restore Mode: Restore (Defaults to OFF)
[12:24:23][C][esp8266_pwm:022]: ESP8266 PWM:
[12:24:23][C][esp8266_pwm:023]: Pin: GPIO13 (Mode: OUTPUT)
[12:24:23][C][esp8266_pwm:024]: Frequency: 1000.0 Hz
[12:24:23][C][esp8266_pwm:025]: Inverted: YES
[12:24:23][C][logger:185]: Logger:
[12:24:23][C][logger:186]: Level: DEBUG
[12:24:23][C][logger:187]: Log Baud Rate: 0
[12:24:23][C][logger:188]: Hardware UART: UART0
[12:24:23][C][light:178]: Light 'switch_bedside_01 LED'
[12:24:23][C][light:180]: Default Transition Length: 1.0s
[12:24:23][C][light:181]: Gamma Correct: 2.80
[12:24:23][C][status:034]: Status Binary Sensor 'switch_bedside_01 Status'
[12:24:23][C][status:034]: Device Class: 'connectivity'
[12:24:23][C][captive_portal:169]: Captive Portal:
[12:24:23][C][ota:029]: Over-The-Air Updates:
[12:24:23][C][ota:030]: Address: switch_bedside_01.local:8266
[12:24:23][C][ota:032]: Using Password.
[12:24:23][C][api:095]: API Server:
[12:24:23][C][api:096]: Address: switch_bedside_01.local:6053
[12:29:07][I][ota:046]: Boot seems successful, resetting boot loop counter.
substitutions:
hostname: "switch_bedside_01"
ssid_ap: "switch_bedside_01"
versao: "1.0"
esphome:
name: switch_bedside_01
platform: ESP8266
board: esp01_1m
board_flash_mode: dout
esp8266_restore_from_flash: false
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_pass
ap:
ssid: "$ssid_ap"
password: !secret AP_mode_pass
captive_portal:
logger:
baud_rate: 0
# Enable Home Assistant API//
api:
ota:
password: !secret ota_pass
uart:
rx_pin: RX
baud_rate: 4800
binary_sensor:
- platform: gpio
pin:
number: GPIO0
mode: INPUT_PULLUP
inverted: True
name: "$hostname touch top"
id: button_1
- platform: gpio
pin:
number: GPIO9
mode: INPUT_PULLUP
inverted: True
name: "$hostname touch center"
id: button_2
- platform: gpio
pin:
number: GPIO10
mode: INPUT_PULLUP
inverted: True
name: "$hostname touch bottom"
id: button_3
- platform: status
name: "$hostname Status"
switch:
- platform: gpio
name: "$hostname button 1"
pin: GPIO12
output:
# Register the blue LED as a dimmable output ....
- platform: esp8266_pwm
id: blue_led
pin: GPIO13
inverted: True
light:
# ... and then make a light out of it.
- platform: monochromatic
name: "$hostname LED"
output: blue_led
I wanted to add I am having the same issue. I don’t think it is a WiFi issue as I’m using an Olimex board that is PoE- the wifi on this is not configured and it is solely ethernet. I don’t see it drop off of my UDM. It doesnt seem like a connectivity issue in that regard