[SeanathanVT]

Summary

Fixes intermittent failures to connect and reconnect to the WalkingPad. They come from two older bugs in the connect path, both present since #11 (2026-08-25), that compound:

1. The connect timed out on a slow connect. controller.run() covers the OS-level connect plus discovering every service and descriptor on the pad. It shared _BLE_WRITE_TIMEOUT_SECONDS = 5, which is sized for single commands. A macOS connect that took 4.2 s ran out of time partway through service discovery and logged a blank BLE connection attempt failed:. A TimeoutError prints as an empty string.
2. A failed connect left the connection half open. Nothing disconnected the client afterwards, so the pad stayed connected to the Mac and stopped advertising. Every retry then reported Device not found until WalkingDad was restarted.

Changes

• _BLE_CONNECT_TIMEOUT_SECONDS = 10 applies only to controller.run(). Commands keep 5 s, so the lock and shutdown timeouts sized around one write are unchanged.
• If the connect or the switch to manual mode fails, including a timeout or a cancellation, _connect_to_pad() disconnects the half-open client before re-raising.
• The first-connect and auto-reconnect failure messages log the exception type (TimeoutError()) instead of a blank.
• CHANGELOG.md [Unreleased] › Fixed has an entry for each fix.

Tests

Six new tests in tests/test_ble_async.py, each watched failing first:

• a connect slower than the command timeout succeeds
• a connect past the connect timeout still times out, and disconnects the half-open client
• a failed mode switch disconnects the client
• the first-connect and auto-reconnect failure messages include the exception type

The full suite passes on Python 3.10, 3.12 and 3.13 (505 tests each).

Manual check (macOS)

• Start WalkingDad several times and confirm it connects, including when the connect is slow.
• If a connect fails, the log shows the exception type, and a later retry finds the pad without restarting the app.

🤖 Generated with Claude Code