I've had lots of issues with GNU/Linux's Bluetooth stack, BlueZ, for awhile.  Incomplete documentation, constant API changes, and a complete lack of CLI utility support.  The whole development team seems to be very GUI-centric.  This bothers me.  Back in the 3.x version of the BlueZ stack there were a few nice CLI utilities (hcitool, sdptool, l2ping, hciconfig, hidd, rfcomm, etc.), but most of them are deprecated now.

Anyway, I've tried to embrace the GUI which is bluetooth-properties(1), but I've had some problems with my Bluetooth headphones not wanting to reconnect to the host upon powering on.  Unfortunately, the Bluetooth GUI doesn't provide a way of initiating a connection to a paired device (without repairing, of course):

I'm not sure if the developers are expecting applications that use the BlueZ stack to initiate connections themselves, but PulseAudio certainly doesn't do this, because the device doesn't even show up in pavucontrol(1) if it's not connected.

So, I ended up writing a tiny little Python script that tells BlueZ to connect to the specified audio device, if it's in range.

It's pretty simple, just run it with no arguments to show the list of Bluetooth devices:

% ./btconn.py
Codes: P - paired, C - connected, T - trusted

Name: (none)
Address: 00:02:76:0E:79:9E
Flags: P
Path: /org/bluez/26825/hci0/dev_00_02_76_0E_79_9E

Name: 9xxBackBeat
Address: 00:1C:EF:67:E7:48
Flags: PT
Path: /org/bluez/26825/hci0/dev_00_1C_EF_67_E7_48

Name: Microsoft Bluetooth Notebook Mouse 5000
Address: 00:22:48:DD:F3:BC
Flags: TC
Path: /org/bluez/26825/hci0/dev_00_22_48_DD_F3_BC

Or, run it with a partial name of a paired device, and it'll try its best to connect:

% ./btconn.py 9xx
Connection to "9xxBackBeat" was successful.

It only connects to audio devices, right now.  Maybe I'll add support for other types of devices in the future, but right now I don't see the need since I haven't seen problems with input devices upon reconnecting.  I don't have any experience with Bluetooth printers or other devices, but I'd suspect the applications actively call connect() as part of their normal operation.

Grab btconn.py from here.  It's been tested against version 4.66 of the BlueZ stack on Debian GNU/Linux.

New comments are currently disabled for this entry.