If you have bluetooth devices paired with your Mac, then they ought to automatically re-establish their connection when you restart your Mac or wake it from sleep. However, there may be times when this does not occur, and furthermore, you may find yourself unable to maintain the connection once woken from sleep. As a result, your connected devices may continually drop, or refuse to pair after sleeping.
This problem unfortunately may be a bug in how OS X is managing bluetooth connections, as opposed to some configuration oddity that is spurring it. While you can try turning bluetooth off and then back on, this does not seem to fully address the issue.
To address this problem, you can perform the same action performed at bootup that will spur OS X into using Bluetooth correctly: forcing the bluetooth kernel extension to reload from scratch. While this is still not the most practical solution, it is one that should get your devices connected again
- Open the Terminal utility
- Run the following two commands:
sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport; sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
When done, if Bluetooth is off then turn it back on and choose your devices from the Bluetooth menu. As a quick tip, you can select both of the commands above and then drag the selection to a Finder window, to create a text clipping of them in a convenient location (such as your Desktop). You can then quickly run the commands by dragging the clipping to a new Terminal window.
Although I’m using a wired keyboard and mouse, a question occurred to me. How can you follow those instructions if you only have bluetooth devices and they don’t communicate with the computer? Sounds like Catch 22.
Because the first rule of wireless is to always have a wired option as a fallback. I keep both an old wired mouse and a wired keyboard in the drawer for just such situations. Everyone should.
I don’t have any thoughts on the Bluetooth problem as I have never experienced it.
But the quick tip at the end of the article made me realize a few interesting things about text clippings:
First, that unlike other file types and folders, when you drag them to the Terminal the contained text is copied, rather than the path to the file. This is convenient but totally unexpected behavior.
Second, that text clippings are actually “empty” files! Not really: their data fork is empty, but the resource fork contains the text in four different formats (!!!!). That’s quite odd since Apple has been trying to phase out the use of resource forks since they don’t play well with other filesystems.
I suspect the clipping feature in OS X is a vestigial element that has not been touched by Apple engineers since it was first ported from OS 9. It’s good to see it can still be useful.
As for Bluetooth, it can certainly be problematic. When pairing a mouse, trackpad or keyboard with a Mac for the first time, it may or may not detect the signal from the device. If it does not, you will indeed need a wired mouse and keyboard to turn Bluetooth on and set it to searching. Even then, I recently had to restart a Mac to get it to recognize a wireless keyboard, even after turning Bluetooth on. Fortunately, it did recognize with mouse I was using so I could navigate the system.
too bad it doesn’t work..
>kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
(kernel) Can’t unload kext com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport; classes have instances:
(kernel) Kext com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport class BroadcomBluetoothHostControllerUSBTransport has 2 instances.
Failed to unload com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport – (libkern/kext) kext is in use or retained (cannot unload).
Same, and after running this my bluetooth is not available (squiqqly line through the bluetooth icon in the menu bar) until a reboot.