core: WiFi based ESPHome BT Proxies error message - "Connection error occurred: EOF received"

The problem

Hi!

Since updating to 2023.2, I have been receiving these messages in my log file for each of my BT Proxies running on ESPHome 2022.12.8

Logger: aioesphomeapi.connection
Source: runner.py:128
First occurred: February 1, 2023 at 9:00:00 PM (170 occurrences)
Last logged: 6:32:30 AM

esp32-bluetooth-proxy-4ca0c4 @ 192.168.1.169: Connection error occurred: EOF received
esp32-bluetooth-proxy-4ca434 @ 192.168.1.115: Connection error occurred: EOF received
esp32-bluetooth-proxy-5f189c @ 192.168.1.168: Connection error occurred: EOF received
esp32-bluetooth-proxy-5a63a8 @ 192.168.1.180: Connection error occurred: EOF received
esp32-bluetooth-proxy-5e9b38 @ 192.168.1.126: Connection error occurred: EOF received

there is a second message that may be related, but it is not as often as the first above:

Logger: aioesphomeapi.connection
Source: /usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py:560
First occurred: 12:18:21 AM (2 occurrences)
Last logged: 5:51:33 AM

esp32-bluetooth-proxy-5a63a8 @ 192.168.1.180: Connection error occurred:
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 520, in send_message_await_response_complex
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 519, in send_message_await_response_complex
    async with async_timeout.timeout(timeout):
  File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 129, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 212, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 303, in _keep_alive_loop
    await self._ping()
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 628, in _ping
    await self.send_message_await_response(PingRequest(), PingResponse)
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 537, in send_message_await_response
    res = await self.send_message_await_response_complex(
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 522, in send_message_await_response_complex
    raise TimeoutAPIError(
aioesphomeapi.core.TimeoutAPIError: Timeout waiting for response for <class 'api_pb2.PingRequest'> after 10.0s

What version of Home Assistant Core has the issue?

2023.2.0

What was the last working version of Home Assistant Core?

2023.1.7

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ESPHome

Link to integration documentation on our website

https://www.home-assistant.io/integrations/esphome/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 71 (28 by maintainers)

Most upvoted comments

Closing per discussion in #beta. Considered solved in 2023.7.x. Along with esphome 2023.6.x

bdraco on Jun 29, 2023

To isolate if it’s just this magic AP system being the culprit, how about trying:

check with a wifi scanner app, how many APs (MAC addresses broadcasting) do you see behind the same SSID? 1, 4, 8 or more? Maybe a rogue AP not part of this mesh but using the same SSID (and key), interfering? Your neighbour having fun, perhaps?
what’s the channel width on 2.4GHz? ESP only supports HT20 and HT40, but I feel that ESPHome defaults to HT20. Now if your AP wants to communicate at HT40 while your ESP wants to use HT20 that will lead to performance degradation on both sides.
disable band steering. It usually causes problems with other stuff too. Implementation quality differs at vendors, and there’s a reason that the “dumbed down” AP exposes this switch while other settings are hidden…
turn off all (pull the power) APs except one, to make sure there’s no magic meshing, wait 30 mins, see if ESP is still producing the error
eventually spin up the Linksys’s own WiFi on a different IoT SSID only on 2.4GHz HT20, and connect the ESP to that instead, see if ESP is still producing the error

And yes, you have a lot of WiFi devices sharing the airtime of only 4 APs, it may simply be the issue of overloading them. Strangely the manufacturer doesn’t give in the specs the max supported clients number… Wouldn’t even be surprised it’s something totally different - with all your devices in the same broadcast domain, a lot of useless chatter is being distributed to all clients (wired and wireless). At this level, some VLAN and SSID separation would be beneficial…

Given your environment, I’d be sure to only use Ethernet based ESP devices (with ext antenna) for Bluetooth proxying. It’s all maxed out…

nagyrobi on Mar 7, 2023