Skip to content

Fix BLE disconnect logging - #348

Closed
dnicolson wants to merge 1 commit into
OpenWonderLabs:latestfrom
dnicolson:patch-1
Closed

dnicolson wants to merge 1 commit into
OpenWonderLabs:latestfrom
dnicolson:patch-1

Conversation

@dnicolson

Copy link
Copy Markdown
Contributor

♻️ Current situation

After BLE operations, "Unexpected disconnect" is logged:

[10/24/2026, 4:23:14 PM] [SwitchBot] Created/updated HAP accessory F544E3493056 (curtain)
[10/24/2026, 4:23:14 PM] [SwitchBot] Registered 1 HAP accessory(ies) with Homebridge
[10/24/2026, 4:23:14 PM] [SwitchBot] SwitchBot client initialized with native resilience features
[10/24/2026, 4:23:14 PM] Homebridge v2.4.0 (HAP v2.2.2) (Homebridge EA14) is running on port 51937.
[BLEConnection] WARN: Unexpected disconnect from --:--:--:--:--:--
[BLEConnection] WARN: Unexpected disconnect from --:--:--:--:--:--
[10/24/2026, 4:24:05 PM] [Homebridge UI] [@switchbot/homebridge-switchbot] Incoming Request: /ble-status
[10/24/2026, 4:24:05 PM] [Homebridge UI] [@switchbot/homebridge-switchbot] [SwitchBot UI/Server] Found 1 SwitchBot candidate(s)
[10/24/2026, 4:24:05 PM] [Homebridge UI] [@switchbot/homebridge-switchbot] [SwitchBot UI/Server] Using SwitchBot platform: SwitchBot
[BLEConnection] WARN: Unexpected disconnect from --:--:--:--:--:--

💡 Proposed solution

Fix logging.

@dnicolson dnicolson closed this Oct 24, 2026
donavanbecker pushed a commit that referenced this pull request Oct 25, 2026
BLEConnection logged "Unexpected disconnect" for every disconnect it started
itself (the idle timer after each command, disconnectAll, a failed
connection), because nothing marked them as expected. Meanwhile a disconnect
started by the device (out of range, powered off) was never noticed: the dead
peripheral stayed in the connection map and the next command reused it.

- disconnect() is always intentional: it logs at debug level.
- A 'disconnect' listener on the peripheral drops the connection state
  (characteristics, encryption, pending reply) and warns only when the device
  dropped the link; markExpectedDisconnect() silences that warning.
- The characteristic-discovery failure path uses disconnect().

Supersedes #348.

Co-authored-by: dnicolson <dnicolson@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TYWa2RXoWsaUTWh76oNv8s
donavanbecker pushed a commit that referenced this pull request Oct 25, 2026
BLEConnection logged "Unexpected disconnect" for every disconnect it started
itself (the idle timer after each command, disconnectAll, a failed
connection), because nothing marked them as expected. Meanwhile a disconnect
started by the device (out of range, powered off) was never noticed: the dead
peripheral stayed in the connection map and the next command reused it.

- disconnect() is always intentional: it logs at debug level.
- A 'disconnect' listener on the peripheral drops the connection state
  (characteristics, encryption, pending reply) and warns only when the device
  dropped the link; markExpectedDisconnect() silences that warning.
- The characteristic-discovery failure path uses disconnect().

Supersedes #348.

Co-authored-by: dnicolson <dnicolson@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TYWa2RXoWsaUTWh76oNv8s
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant