Hi all,
On a Wemos D1 mini ESP8266 testing device I’m experiencing continuous disconnections, every 2-3 minutes even with a optimal wifi signal strength.
The device gets its IP from the DHCP server, a rock-solid OpenWrt.
The builtin LED flashes as it should do only when disconnected, otherwise it stays off.
ESPHome is 1.14.2 just updated.
Here is a log excerpt:
...
[13:31:21][I][mqtt:162]: Connecting to MQTT...
[13:31:21][I][mqtt:202]: MQTT Connected!
ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer
WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
INFO Successfully connected to d1mini_test1.local
[13:34:21][I][mqtt:162]: Connecting to MQTT...
[13:34:21][I][mqtt:202]: MQTT Connected!
ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer
WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
INFO Successfully connected to d1mini_test1.local
[13:36:21][I][mqtt:162]: Connecting to MQTT...
[13:36:21][I][mqtt:202]: MQTT Connected!
...
And here is the ESPHome d1mini_test1.yaml, it’s quite basic:
Thanks @tom_l , but I get the same behavior disabling mqtt: and web_server:
My native language isn’t English, but I understand that the big red box substantially says and, not or.
Reading that box I understand one can use both MQTT and API, provided api: must be disabled only if the native API isn’t used by HA (HA isn’t connected through the API), to avoid the no-API-client-connected timeout, but as you can see below, the device successfully connects to HA.
So that isn’t my case, as I currently use the API to communicate with HA, and MQTT only to communicate to the MQTT clients I write (these are crytical and should not depend on HA availability, see Someone has a plain C (not python) example of ESPhome API client?).
In addition, the wiki says the API-not-connected reboot is every 5 minutes, not a couple of minutes as in my case, so I supposed this is another issue.
[21:15:17][D][api.connection:579]: Client 'Home Assistant 0.101.3 ([redacted])' connected successfully!
[21:15:17][I][app:100]: ESPHome version 1.14.2 compiled on Nov 9 2019, 21:14:38
[21:15:17][C][status_led:019]: Status LED:
[21:15:17][C][status_led:020]: Pin: GPIO2 (Mode: OUTPUT, INVERTED)
[21:15:17][C][wifi:409]: WiFi:
[21:15:17][C][wifi:277]: SSID: [redacted]
[21:15:17][C][wifi:278]: IP Address: 172.16.2.128
[21:15:17][C][wifi:280]: BSSID: [redacted]
[21:15:17][C][wifi:281]: Hostname: 'd1mini_test1'
[21:15:17][C][wifi:285]: Signal strength: -50 dB ▂▄▆█
[21:15:17][C][wifi:289]: Channel: 7
[21:15:17][C][wifi:290]: Subnet: 255.255.0.0
[21:15:17][C][wifi:291]: Gateway: [redacted]
[21:15:17][C][wifi:292]: DNS1: [redacted]
[21:15:17][C][wifi:293]: DNS2: [redacted]
[21:15:17][C][logger:175]: Logger:
[21:15:17][C][logger:176]: Level: DEBUG
[21:15:17][C][logger:177]: Log Baud Rate: 115200
[21:15:17][C][logger:178]: Hardware UART: UART0
[21:15:17][C][ota:029]: Over-The-Air Updates:
[21:15:17][C][ota:030]: Address: d1mini_test1.local:8266
[21:15:17][C][ota:032]: Using Password.
[21:15:17][C][api:095]: API Server:
[21:15:17][C][api:096]: Address: d1mini_test1.local:6053
ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer
WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
INFO Successfully connected to d1mini_test1.local
ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer
WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
INFO Successfully connected to d1mini_test1.local
ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer
WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to d1mini_test1.local:6053 (172.16.2.128)
INFO Successfully connected to d1mini_test1.local
The device connects to Wifi and to HA via API, then the problems begin.
I am seeing similar behaviour since upgrading ESPhome to 1.14.2 and HASS.io 0.101.3.
This is only using the api and these devices were rock solid before upgrading.
Unfortunately I upgraded both at about the same time so do not know which one may be the problem. In addition, I’m also seeing some ESPHome devices in the ESPHome panel as disconnected (status red) but they are connected - they are working and the log function will connect and deliver the logs from them in real time.
Not sure what to do to correct this. - is it possible to downgrade ESPhome?
Please try adding “fast_connect: true” and “reboot_timeout: 45min” in your wifi config. To accelerate the wifi dial in process you could also give a static ip to your esp. Maybe this will stop scanning process, redialing and reconnecting?
example (adapt ip to your infra structure, play around with reboot timeout)
Trying to narrow down this problem with the community help before opening a github issue.
Using the Wifi config shown in the OP:
The wemos reply normally to ping while the API loses connection, maybe the device networking (Wifi and/or IP) “disconnects” for less than 1 second.
The problem appears less frequently with 1.13.6 (HASS on a Raspi4-4GB) than 1.14.2 (HASS on a beefy I7). So 1.13.6 isn’t totally immune here.
With 1.13.6 the status LED stays always off, while with 1.14.2 the status LED blinks slowly during all the API lost connection time.
The wemos issues a DHCP request just before the HA server reconnects to its ESPHome API server.
This shoud not be a wemos power supply problem, as this wemos d1 mini is powered via USB with 100nF+470uF capacitors to stabilize its onboard 3.3V.
The wifi LAN connectivity is optimal and there isn’t any problem with other LAN devices (except with one PiZero CAM far in the backyard). The AP is 3 meters far from this wemos (it reports -43dB), both are in the same room.
This board is a Wemos D1 Mini Pro v1.1.0, the problems doesn’t change by defining board: d1_mini_pro or board: d1_mini and, as @RGN01 pointed out, it isn’t limited to wemos boards.
fast_connect: true and reboot_timeout: 45min doesn’t solve the problem.
The manual fixed IP does the magic trick! Thanks @andilge , so this seems a DHCP client issue, I will report it on github.
There are strong hints this has to do with DHCP lease with esphome 1.14 onward (situation right now).
If you try to attribute static ip from the other side with static lease in your router, commenting out “manual_ip” in esphome wifi, will this make things better for you?
This is not the solution, but it might give further indications.
The two NodeMCUs affected are in different rooms, with different WiFi access points, all sharing a gigabit ethernet network on a managed switch showing no errors so this is unlikely to be the network.
An ongoing ping to both devices is not showing breaks when the interruptions occur.
@PieBru looking from the other side at this issue, this can be something in odhcpd of OpenWRT as well. We see DHCP client and server don’t play well together, but the cause is still unknown. Is your OpenWRT up to date, can you give some more details about the odhcpd you use?
@andilge
Other IoT MQTT clients doesn’t show problems (i.e. Espurna-dev with custom modules I developed) or frequent disconnects from the broker, which is hosted by the same OpenWRT router.
