[AloisKlingler]

Addresses #158 (adapter is not shared / stays claimed).

Two changes:

1. Release the adapter when idle. BleControl.Loop() now calls ble.CloseAdapter() in its idle branch (no pending retry) before waiting for the next command. This hands the HCI adapter back to BlueZ between command sessions so other BlueZ-based tools (e.g. a second BLE service on the same host) can use the same controller, instead of being locked out until the proxy is restarted.

2. Configurable connection hold. The post-command connection hold in operateConnection() was hard-coded to 29s. It is now driven by a new connectionTimeout environment variable (default 10s), in the same style as cacheMaxAge / scanTimeout. A shorter value releases the adapter for other tools sooner; a longer value batches follow-up commands.

For the adapter to actually become usable by BlueZ again after release, the HCI User Channel must be brought back up on close — see the companion PR wimaha/ble_BleConnectFix#1 (add HCIDEVUP in Close()). After that merges, the go-ble replace in go.mod can be bumped to include it.

Tested on a Raspberry Pi sharing one adapter between this proxy and a second BLE service: commands succeed, and btmgmt info shows the controller returning to BlueZ ~10s after each command.

[github-actions]

❌ Do not merge yet

The idle release depends on a fix in another repo (ble_BleConnectFix#1) that is not in go.mod yet. The default hold time also drops from 29s to 10s, which changes behaviour for everyone.

Impact on existing users: After the update, the BLE connection closes after 10s instead of 29s. Commands sent a bit later (evcc polling, Home Assistant automations) need a new scan and connect, so they are slower. Wake-up and session setup may happen more often.

To-do for the author

• Keep the old default of 29s for connectionTimeout. Let users opt in to a shorter time.
• Merge the companion PR first and bump the go-ble replace in go.mod. Check that ble.CloseAdapter exists in the pinned wimaha/vehicle-command v0.0.7, so the build does not fail.
• Do not call CloseAdapter() on every idle loop pass. Call it once after a session ends, and log failures at warn level.
• Reject values of 0 or below for connectionTimeout and fall back to the default.
• Document connectionTimeout in docs/environment_variables.md.

Test before merging: On a real Pi, send a command, wait 15 minutes, send another, and check that it still works. Run the same test with the car asleep and out of range.

Technical details

• config/config.go (new connectionTimeout): the default changes from 29s to 10s. 0 or a negative value makes the context expire at once, so every command fails after the first. Fix: validate > 0.
• internal/ble/control/control.go:78: CloseAdapter() runs on every idle pass, including the first pass at start-up. The error is only logged at debug level, so if the companion fix is missing the adapter is closed but never handed back, and users see no warning. Please also check that CloseAdapter is safe to call twice and that it does not race with a scan that is still running.
• internal/ble/control/control.go:406: the 29s hard-coded value is replaced by the config value. This is fine once the default is kept.
• go.mod:39: the go-ble replace is not updated. The PR says the fix only works after the companion PR is merged.
• Not verified: I could not check whether ble.CloseAdapter exists in wimaha/vehicle-command v0.0.7. The module cache was not available and network access was limited. grep finds no definition in this repo.
• Not verified: effect on arm/v6 and arm/v7, and on reconnect time after the adapter is released.

[wimaha]

Thank you! I close this, because I continue working on this solution in: #174