fix

esphome/components/esp32_ble/__init__.py

@@ -486,6 +486,8 @@ async def to_code(config):
     # This enables low-latency (~12μs) BLE event processing instead of waiting for
     # select() timeout (0-16ms). The socket is created in ble_setup_() and used to
     # wake lwip_select() when BLE events arrive from the BLE thread.
+    # Note: Called during config generation, socket is created at runtime. In practice,
+    # always used since esp32_ble only runs on ESP32 which always has USE_SOCKET_SELECT_SUPPORT.
     socket.consume_sockets(1, "esp32_ble")(config)
 
     # Define max connections for use in C++ code (e.g., ble_server.h)

esphome/components/esp32_ble/ble.cpp

@@ -732,8 +732,10 @@ void ESP32BLE::drain_event_notifications_() {
     char buffer[BLE_EVENT_NOTIFY_DRAIN_BUFFER_SIZE];
     // Drain all pending notifications with non-blocking reads
     // Multiple BLE events may have triggered multiple writes, so drain until EWOULDBLOCK
+    // We control both ends of this loopback socket (always write 1 byte per event),
+    // so no error checking needed - any errors indicate catastrophic system failure
     while (lwip_recvfrom(this->notify_fd_, buffer, sizeof(buffer), 0, nullptr, nullptr) > 0) {
-      // Just draining, no action needed
+      // Just draining, no action needed - actual BLE events are already queued
     }
   }
 }

esphome/components/esp32_ble/ble.h

@@ -239,6 +239,8 @@ inline void ESP32BLE::notify_main_loop_() {
   if (this->notify_fd_ >= 0) {
     const char dummy = 1;
     // Non-blocking send - if it fails (unlikely), select() will wake on timeout anyway
+    // No error checking needed: we control both ends of this loopback socket, and the
+    // BLE event is already queued. Notification is best-effort to reduce latency.
     // This is safe to call from BLE thread - send() is thread-safe in lwip
     // Socket is already connected to loopback address, so send() is faster than sendto()
     lwip_send(this->notify_fd_, &dummy, 1, 0);