One was a replacement for an esp8266 that where unstable.
The other one a new module/sensor.
(And both seem to be stable)
I’ve noticed a different behavior with the esphomelib/esphomeyaml “status sensor” on the esp32 compared to the esp8266.
When I do an OTA update on a esp8266 all the sensors are unavailable when duing OTA as one would expect, but not on the esp32 where all sensors are still availiable even when the esp32 is rebooting (takes about 5 seconds to reconnect).
It’s not a problem, but odd. Is there a difference in how the 2 types of modules handle OTA updates or why is this? A difference in the libaries being used maybe?
I think it might be due to the reboot process of the boards. AFAIK the ESP8266 performs a full reset of the chip on a successful OTA update and closes all network sockets. I think the ESP32 does something different where it doesn’t close any sockets and just lets them time out. Ultimately, there are probably several things at play here and I don’t know enough about the underlying architecture to say something definitive.
My primary issue was/is actually a bug in my wifi setup (Ubiquiti Unifi).
I’ve enabled fast roaming on 1 of my 3 networks.
Eventhough my esp modules is not connected to this network it made the connection unstable and i’ve disabled the option.
I haven’t had any major instability issues after this.
@OttoWinter I’ve recently hooked up an ESP8266 and am also experiencing frequent disconnects repeatably every 5 minutes. My esphome yaml config is v1.10.1, any ideas?
In my case the 5 minute recurring disconnects were the NodeMCU restarting every 5 minutes due to not detecting a connection to the Native API. So I ended up ditching MQTT and used the Native API.
if it can help I see that situation improved lowering DTIM parameter on 2.4ghz wifi network on my router.
A lower DTIM make such that the router “awakes” from sleep mode client more frequently: with very low DTIM it actually makes such that clients do not go in sleep mode.
I believe all is due to ESP8266 being designed for low power consumption hence trying to go in sleep mode as much as it can: even with WiFi.setSleepMode(WIFI_NONE_SLEEP) I suspect it is sometimes going to sleep.
That is why constant ping keep them alive as, basically, is what DTIM does (too keep them alive, not to ping )
I have 2 Unifi Access Points and I am having lots of brief disconnects. I checked and I do not have Fast Roaming enabled. Do you have any other ideas on features I should disable?
I found the DTIM settings under “802.11 RATE AND BEACON CONTROLS” in UniFi controller. Use Default Values is checked, and when I uncheck them the settings start out at 1 (and cannot go any lower).
Could you give me an idea of what DTIM values you have setup on your 2.4ghz and 5ghz networks?
@BrianHanifin
I still have some disconnects, but not nearly as many.
DTIM is set to default (and default is 1 according to Ubiquiti).
Maybe you can find some usefull tips here?:
I use a synology rt2600AC: default DTIM setting is 4 and setting to 2 I have no disconnection issues.
This on 2,4ghz network, while on 5ghz (not used by esp8266), I kept 4
Anyway DTIM set how often a beacon “wake up” is sent but this also depends on the number of devices you have on your network.
Ideally more devices should lead to a lower DTIM you need to set.
1 is the lowest value which had a meaning though
For those still struggling with this: I had very regular disconnects on my D1 mini, while WiFi strength was actually quite OK. Adding power_save_mode: none to the WiFi config block seems to have solved (or at least greatly reduced) the issue. Am now at 2 hours uninterrupted connection, that used to be max 10-15 minutes!
I have the same issue, i have a bunch of switches etc connected to ESPHOME and the devices are constantly disconnecting even when reported WIFI signal is good.
I have tried the following:
Fixed IP address.
Reboot my entire Wifi system (google wifi)
Added the power save mode field to none
Still getting disconnects which is very annoying, not sure what my options are, perhaps move my devices to Tasmota and use MQTT.
I’ve noticed as well that the devices will show as Offline in ESPHOME but when clicking on show logs i get connection straight away, when i stop it still shows Offline, this happens for all the devices. Checking other switches like TPLINK and WEMO and they show connected constantly, it just seems to be any device using ESPHOME having this issue.
a feedback on the topic on my side which could be helpful for one having wifi connection issue with ESP8266/32.
I have no idea whether my statement are correct but the whole thing works for me after I made a lot of debugging together with synology remote support.
To make a long story short:
I own a synology RT2600AC + MR2200AC (in mesh config) as router
I experienced a lot of disconnection issue from (mainly) esphome devices which i couldn’t understand
It turned out issue were too many mDNS packets over the network sent by:
Fingbox (mainly)
EspHome (by a smaller extent)
this together with the fact apparently Synology router do not like such situation made connection very unstable which I could primary notice on EspHome device.
It looks like these (esp8266/esp32), in fact, are much more susceptible to network traffic (maybe because of their low bandwidth?) with respect to other devices.
Solution:
Turn off fingbox
stop EspHome from Hass.IO (and run it only when needed)
currently my setup is super stable since a couple of months (70-ish network devices, 30 of them are ESPs)
Hello, I am a newbe on this subject, but I have a really weird connection issue. When I have the ESP8266 connected to my laptop via USB, I can see through the log that it is connected to the WiFi network. No issues there. Also in Hassio, the ESP is detected. And now comes the weird part. Hassio is not able to connect to the ESP. Error message is that I should add “api” to the yaml config. But it is already in. My other ESP works just fine. The problem ESP used to work fine. I have added serveral sensors to it, tried some other networks, all went went. Until a certain moment, that the ESP was not reachable anymore through the API. I even tried to erase the flash with the ESSpriff ESP8266 secure flasher tool 3.6.0 to rule out some "left over"bits and pieces.
Does anyone have an idea?
ESPhome 1.14.3. Joy-it NodeMCU ESP8266
Log through USB port after flashing:
[18:13:27][I][wifi:193]: WiFi Connecting to ‘Lest-Best’…
[18:13:28][I][wifi:423]: WiFi Connected!
[18:13:28][C][wifi:283]: SSID: ‘Lest-Best’
[18:13:28][C][wifi:284]: IP Address: 192.168.1.205
[18:13:28][C][wifi:286]: BSSID: 98:9B:CB:B6:47:83
[18:13:28][C][wifi:287]: Hostname: ‘tack_room’
[18:13:28][C][wifi:291]: Signal strength: -62 dB ▂▄▆█
[18:13:28][C][wifi:295]: Channel: 6
[18:13:28][C][wifi:296]: Subnet: 255.255.255.0
[18:13:28][C][wifi:297]: Gateway: 192.168.1.1
[18:13:28][C][wifi:298]: DNS1: (IP unset)
[18:13:28][C][wifi:299]: DNS2: (IP unset)
[18:13:28][D][wifi:432]: Disabling AP…
[18:13:28][C][ota:029]: Over-The-Air Updates:
[18:13:28][C][ota:030]: Address: 192.168.1.205:8266
[18:13:28][C][api:022]: Setting up Home Assistant API server…
[18:13:28][I][app:058]: setup() finished successfully!
[18:13:28][I][app:100]: ESPHome version 1.14.3 compiled on Jan 10 2020, 18:08:49
[18:13:28][C][wifi:415]: WiFi:
[18:13:28][C][wifi:283]: SSID: ‘Lest-Best’
[18:13:28][C][wifi:284]: IP Address: 192.168.1.205
[18:13:28][C][wifi:286]: BSSID: 98:9B:CB:B6:47:83
[18:13:28][C][wifi:287]: Hostname: ‘tack_room’
[18:13:28][C][wifi:291]: Signal strength: -62 dB ▂▄▆█
[18:13:28][C][wifi:295]: Channel: 6
[18:13:28][C][wifi:296]: Subnet: 255.255.255.0
[18:13:28][C][wifi:297]: Gateway: 192.168.1.1
[18:13:28][C][wifi:298]: DNS1: (IP unset)
[18:13:28][C][wifi:299]: DNS2: (IP unset)
[18:13:28][C][logger:175]: Logger:
[18:13:28][C][logger:176]: Level: DEBUG
[18:13:28][C][logger:177]: Log Baud Rate: 115200
[18:13:28][C][logger:178]: Hardware UART: UART0
[18:13:28][C][captive_portal:169]: Captive Portal:
[18:13:28][C][ota:029]: Over-The-Air Updates:
[18:13:28][C][ota:030]: Address: 192.168.1.205:8266
[18:13:28][C][api:095]: API Server:
[18:13:28][C][api:096]: Address: 192.168.1.205:6053
[18:15:21][I][ota:046]: Boot seems successful, resetting boot loop counter.
I found what the problem was: My AVM Fritz router registered the MAC address to the initial name of the ESP8266. When I changed the name from “Test” to the “Tack_room” somehow the old name kept on appearing and somehow it prevented the API to connect to the ESP8266.
Solution: I have deleted all the ESp8266 entries in my Fritz router (7350 FritzIOS 7.12), deleted all configuration settings from the config files of ESPhome in Hassio and restarted the server. Than added the ESP8266 with the correct names.
I have a Asus GT-AX11000 router. Seperate 2,4Ghz and 2 seperate 5Ghz wifi ssid’s
I have 8 ESP wall switches, 3 of them disconnect/reconnect many many time.
I checked everything
Router config, 20mhz, fixed channel, WP2-Personal / AES, beam settings off etc.
ESP Forced use of B/G, eco mode off
Lots of time the ESP’s disconnect. Strange enough other ESP wall swiches that are more away from the router does not have those problems at all.
All have same ESP firmware 20200108
Replace 1 ESP PCB for a new one, didn’t work
DTIM set to 3
Smart Connect: disabled
802.11ax-modus: disabled
Wifi Eco mode router side: disabled
QoS: disabled
Thank you @Wagoneermaster007. Your note has enabled me to narrow down my issue. Its the Home Assistant integration that causes my issue
I have 4 x Sonoff 4ch Pro R2’s each flashed with esphome. The first 4ChPro was added and it has been running with no issue ever since no issue and no disconnect…i have never changed the initial code or device name and it is the exact same hardware as the others. The next three I added later but after the initial install I re-purposed them which meant changing their name in ESPhome and also the .yaml name. They would all connect fine to my wifi but after a minute or so they would disconnect then reconnect both to my wifi and HomeAssistant. The strange thing was I opened 3 console windows and started Ping requests on each side by side…the Ping’s would drop on all 3 Sonoff’s at the same time. It would drop between 2 and 4 ping requests then reconnect.
So I tried the following solutions based on what I read in various forums:
added (but later removed):
logger:
baud_rate: 0
Removed the logger code all together from the .yaml
Added Logger back in and changed to VERBOSE to look at the logs but they didn’t really tell me anything other than stating the disconnection from HomeAssistant
added power_save_mode: none
used manual IP settings in the .yaml
stripped back my .yaml so that it only had the wifi details and default settings
Re-purposed another Wifi AP and sat it directly in front of the Sonoff modules (-30dB)
Tried each radio type (bgn and mixed mode)
Changed the frequency to 20mhz, fixed channel (tested each)
Checked the DTIM settings
Re-flashed the firmware in each sonoff
checked the soldering on the antennae (considered changing)
Changed to the dev branch of esphome in HomeAssistant and re-installed
Then updated the firmware again on the Sonoff’s
Downgraded the esphome version to 1.13
Then updated the firmware again on the Sonoff’s
…nothing worked
So when I came across this post I tried the following…and it worked to a point!!!:
I deleted each of the 3 Sonoff’s from esphome completely. This included the .yaml files, there associated config folders, the .json file and also the file in the esphome trash
I deleted the Sonoff integration in HomeAssistant
I removed the DHCP static MAC config from my router.
Cleared the DHCP leases in the router and DNS cache
Rebooted the router, wifi AP and HomeAssistant
Then I re-installed base esphome config into the Sonoff but changed the hardware and file name
I started continuous ping…everything ok
Added the Sonoff wifi MAC back into my router DHCP…everything ok
Added back my full code into the esphome .yaml and uploaded firmware…everything ok
left the ping going for an hour and no disconnect…everything ok
Then I went into the Integration page of HomeAssistant and added the Sonoff Integration for the hardware and it disconnected. The problem came back. Connection for about 80 ping requests then a timeout for 2-4 requests and then reconnect again.
Sorry for the long post but can anyone assist with how I should attack the HomeAssistant side of this.
)