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.

@Lenart12
Copy link
Contributor

Lenart12 commented Feb 5, 2025

If hci jumps around, how about specifying wanted device with it's mac address, or some other unique id? And then search for it?

@Lenart12
Copy link
Contributor

Lenart12 commented Feb 5, 2025

I have proposed a new PR with my suggestion.

@pkuehnel
Copy link

pkuehnel commented Feb 5, 2025

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.

Same here, I have a few hundred BLE users, I never had this issue, some have this regularly but until now, I did not find the root cause. This PR helps to get rid of the issue, though.

@baylanger
Copy link
Author

baylanger commented Feb 7, 2025

If hci jumps around, how about specifying wanted device with it's mac address, or some other unique id? And then search for it?

@Lenart12 I didn't think of going with the BLE MAC addr , I admit I like your approach better than mine as it covers someone with 2+ BLE devices... perhaps for someone with a big house and 2 garages on apposite side that each requires their own dongle :)

I'll leave this PR open for now but I vote for your approach.

@Lenart12
Copy link
Contributor

Lenart12 commented Feb 8, 2025

My PR will not work, check my comment there :^(

@Lenart12
Copy link
Contributor

I made a PR (#373) that will switch the bluetooth backend to use BlueZ. It allows us to nicely specify which adapter to use (hciX). You can use external tooling to find the wanted hci id (first available/mac address). Hopefully that also means that a lot of wierd bluetooth issues people were experiencing will be fixed.

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
4 participants