Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scan and pick first available hci device #369

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

baylanger
Copy link

@baylanger baylanger commented Feb 1, 2025

Description

This PR enables tesla-control to automatically select, at least under Linux, the first available hci device. Currently, tesla-control only tries to use hci0 and lacks the ability to dynamically choose the first available Bluetooth device.

In our project, an add-on for Home Assistant, tesla-control is used to fetch data and control Tesla vehicles.

We’ve received multiple reports from different people seeing always the same issue. This happens on Raspberry Pi (recent and old models), Synology NAS, and similar systems. After a fresh reboot, the Bluetooth device initially appears as hci0, but after a short time, it jumps to hci1. After this, tesla-control becomes useless.

I am not a pro Go programmer but the tests I ran seem to be a solution for #261

Fixes #261

Type of change

Please select all options that apply to this change:

  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Bug fix (non-breaking change which fixes an issue)
  • Documentation update

Checklist:

Confirm you have completed the following steps:

  • My code follows the style of this project.
  • I have performed a self-review of my code.
  • I have made corresponding updates to the documentation.
  • I have added/updated unit tests to cover my changes.

@baylanger
Copy link
Author

baylanger commented Feb 1, 2025

Per more tests I just ran, when the device jumps from hci0 to hci1, when the kernel encounter an issue with the later, the device goes back to hci0. [edit] it even jumped once to hci2 and reverted later to hci0.

Perhaps a better solution would be to allow via command line to specific which device to use but most people only have a single BLE device.

return nil, fmt.Errorf("failed to find available Bluetooth adapter: %w", err)
}

log.Printf("Using Bluetooth adapter: %s", hciName)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably use log.Debug

@sethterashima
Copy link
Collaborator

Is there a reliable way to reproduce this on a raspberry Pi? I do most of my Linux-based testing on one and haven't encountered this issue.

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.

Scan hci0 and hci1
2 participants