Disconnect/wait-disconnect issues
JoshuaIyalagha opened this issue · comments
Hello,
I am having issues when trying to --disconnect or --wait-disconnect.
The command runs but the bluetooth device doesn't disconnect. When I use --wait-disconnect, i get an error that states "Timed out waiting for "(null)" to disconnect" even though I properly inputed the right bluetooth MAC address.
Thanks for creating the tool!
Few questions:
Does this device have a name (checking through preference pane or using bluetil --connected/blueutil --paired/blueutil --recent)?
Could you try disconnecting another device same way?
Hello, thank you for your quick response.
Yes the devices do.
Yes, I have tried it with multiple devices. The first two are my google nest speakers. The third was my bluetooth headphones.
All connect but don't disconnect via terminal/blueutil. I can disconnect them via the menu bar or by using apps like ToothFairy.
If you need more info, please let me know!
I have the exact same issue, it connects but doesn't disconnect.
FYI: I have the same issue with bluetoothconnector
I'm using a TWS (One plus Buds Z)
@JoshuaIyalagha You say that you try --disconnect or --wait-disconnect, but I found out that you need to combine them.
This works for me:
blueutil --disconnect 04-fe-a1-e4-73-75 --wait-disconnect 04-fe-a1-e4-73-75
I debugged a bit because I tried to fix a bug in the bluetooth extension (Toothpick) for Raycast.
I noticed that the underlying problem is that IOBluetoothDevice.closeConnection returns successfully but does not close anything. A simple delay seems to fix the problem. I did not found an elegant solution yet to fix it. But the -wait-disconnect does already seem to fix it on this side.
See also lapfelix/BluetoothConnector#20 where people experience the same problems.
@toy Maybe this gives you some information to fix this problem on the blueutil side?
@paulmiddelkoop I'll write thoughts around the problem.
Documentation of closeConnection says This method is synchronous and will not return until the connection has been closed (or the command failed). In the future this API will be changed to allow asynchronous operation., so it doesn't behave according to documentation. I don't know if it is overall a bug somewhere in framework or has something to do with the fact that it is called from a CLI binary (some assumption on part of framework making it not work well in this case). May be clarified by creating a simple GUI app with a button to call closeConnection on a device.
Unless the reason for the problem is discovered, I imagine 2 solutions (besides relying on always combining with --wait-disconnect):
- Create new command, something like
--disconnect-and-wait, downside is creating a command only to overcome the bug, which behaves same if the bug gets fixed or if it is not affecting certain version/environment. - Change
--disconnectto additionally wait for disconnection, seems that it should not change the behaviour, but maybe I'm missing a case where it does, then it may be introducing unintended behaviour.
@toy I would go with option 2. I think most users expect that a --disconnect just does what is says. I would not expect that people rely on async disconnect now, otherwise they rely on undocumented behaviour of blueutil.
Also I think it's best that the --connect and --disconnect behave the same way. So either both being async or both being sync. Since the --connect is synchronous, it makes sense to me to do the same thing for --disconnect.
Would be great if someone having the problem can check if changes on wait-on-disconnect branch fix them
@toy I tested the branch and it fixes it 🚀 Great job!
@JoshuaIyalagha Could you please check if the issue is fixed for you?
Just adding that I was having the same issue with my magic mouse, but upgrading to v2.9.1 fixed it. Thanks, @toy!