Closed mainrs closed 10 months ago
As far a I am aware, the device's current connected status is not shared during discovery. If a device didn't want to have its connection replaced, it should simply not advertise itself or reject new connections when it already has one, so what you are describing may actually be a "feature" of your headphones. As the software on devices like headphones is generally outside of our control, some hijinx may be necessary. As your phone would know whether or not it was already connected, that information could somehow be shared to your computer and then used to inhibit the connection (as we scan for devices that are paired AND trusted, running bluetoothctl untrust <mac_address>
would exclude it from our scan; there is also bluetoothctl block <mac_address>
, but I am unsure of how it would work in practice). This would be a complex setup and would be outside of the scope of what we could directly support here.
A more simple solution may be to turn off the bluetooth-autoconnect daemon services and to use it manually in one-shot mode, or more simply, removing bluetooth-autoconnect entirely and using bluez directly with bluetoothctl connect <mac_address>
as desired (by script, keybind, etc.).
If you are using bluetooth-autoconnect for other devices and there is a need to exclude specific devices to control them manually, I could see value in adding inclusion/exclusion filters to our command line arguments. Perhaps something like bluetooth-autoconnect [-d] --include <other_mac>,<another_mac>
or bluetooth-autoconnect --exclude <mac_address>
. I have created a new issue for adding those arguments here: https://github.com/jrouleau/bluetooth-autoconnect/issues/18. If this would be a viable solution, please close this issue and continue the conversation there. It may be some time before I can get to that task though, so PRs are welcome.
Disclaimer: I do not claim to be an expert on Bluez, Bluetooth, or the like. There may be solutions I have not considered.
A more simple solution may be to turn off the bluetooth-autoconnect daemon services and to use it manually in one-shot mode, or more simply, removing bluetooth-autoconnect entirely and using bluez directly with bluetoothctl connect
as desired (by script, keybind, etc.).
The hotkey binding makes the most sense for my use-case I guess.
Although I am super surprised that bluetooth headphones do not propagate their connectivity status via broadcast or something.
Thank you for your help! Really appreciated!
Often I have my headphones already connected to my phone. After turning on my PC, the headphones automatically get connected to my PC and lose the phone connection.
Can I somehow configure this daemon to only try to connect if the devices aren't already connected?