Bluetooth Issues after Sleep in OS X Yosemite (10.10)

Question

I seem to be having persistent issues with Bluetooth connectivity, especially after waking up my Macbook Pro from a long sleep.

I have a speaker that automatically turns off after a certain period of inactivity, and my use case typically is open the laptop, turn the speaker on, and when the Bluetooth driver is acting normal, they will automatically reconnect.

However, the problem seem to be that the my Bluetooth peripherals do not reconnect if my Macbook has just been woken up from a long sleep.

After searching around, I found this script to relaunch the bluetooth kernel extensions, but it didn't seem to work on Yosemite.

Here's what sudo tail -f /var/log/system.log gave me after doing a kextload and kextunload (hostname and username redacted):

Nov 17 07:50:11 {redacted} sudo[8118]: username: TTY=ttys000 ; PWD=/Users/username; USER=root ; COMMAND=/sbin/kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:11 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800 
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][initHardwareWL] -- failed -- calling DoDeviceReset (kBluetoothControllerResetHub) -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][DoDeviceReset] -- thread_call_enter1 (mReEnumerateOrResetThread) -- reEnumerateOrReset (0xffffff8213ac3ae0) = 2 --  returned FALSE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Error!! -- Something went wrong in the setup process. Could not communicate with Bluetooth Transport successfully -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- entering -- param0 = 0xffffff806a870800, param1 = 0x2 -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- entering -- reEnumerateOrResetIn = 2 -- this = 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- in our workloop -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- parameter is valid -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- reEnumerateOrReset = 2 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- calling myHub->ReEnumerateDevice() -- gEnumerateCounter = 1 
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- exit; error = 0x0000 (kIOReturnSuccess)
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- exiting -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800 
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController::setConfigState] calling registerService
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Connected to the transport successfully -- 0xe300 -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.595 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.617 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.637 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.657 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.659 : BTLE scanner Powered Off
Nov 17 07:50:12 --- last message repeated 2 times ---
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663673 AM [AirPlay] BTLE client stopping to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} blued[62]: hciControllerOnline; HID devices? 0
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663868 AM [AirPlay] BTLE client starting to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Starting Handoff scanning
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664336 AM [AirPlay] BTLE client stopped to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664753 AM [AirPlay] BTLE client started to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Stopping Handoff advertising
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.665 : BTLE scanner Powered On
Nov 17 07:50:12 {redacted} blued[62]: hostControllerOnline - Number of Paired devices = 2, List of Paired devices = (
      "00-0c-8a-dd-fd-88",
      "84-38-35-ec-1c-ea"
  )
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::message - kIOUSBMessagePortHasBeenReset.
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was reinitialized
Nov 17 07:50:13 {redacted} hidd[74]: MultitouchHID: device bootloaded
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::_deviceGetReport - DeviceRequest for reportID 0xc8 returned with result 0xe000404f - retrying

uname -a output (hostname redacted):

$ uname -a
Darwin {redacted} 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

Has any of you seen this problem before? Any help would be appreciated.

Answer 1

I've had issues reconnecting my bluetooth keyboard & trackpad since upgrading to Yosimite.

First try this: Open Terminal & run 2 commands:

sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport

sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport

I only had to run above once. If later bluetooth breaks again 2 options, simply run above again or you can create a 1-click solution with a simple app using Automator:

1. Search for (Spotlight search) and run Automator
2. Click "New Document" at bottom
3. Choose "Application" for new file type
4. Click on "Utilities" from list
5. Double-Click "Run AppleScript"

6. Replace (* Your script goes here *) with:

   do shell script "kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport; 
   kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport" with administrator privileges
   

7. Press play to test (will prompt for password)
8. File->Save to desktop or wherever

Run the automator app whenever bluetooth devices won't connect

Answer 2

Mikaey's solution on the apple support forum:

1. Turn your WiFi off
2. Try re-connecting to your bluetooth devices (should work)
3. Turn WiFi back on

This has solved the issue for me.

Answer 3

After trying to run the scripts suggested by other answers, unloading and reloading both the kext and the bluetooth daemon, my bluetooth still wasn't responding.

However, I have discovered that if Yosemite sleeps with VMWare running and bluetooth doesn't work when the OS is woken up, closing VMWare rectifies the issue.

It seems that the drivers in VMWare don't always handle the sleep / wake process correctly.

Answer 4

-- UPDATE: This problem is NOT fixed in OSX 10.11 El Capitan --

The following is an alternative to the Automator solution posted by webaholic, for those who, like me, find inconvenient having to entering your password again (most likely you'll have just entered it to logon after waking your Mac up).

First, in Terminal, create a script that reloads the bluetooth subsystem:

cat > bt_restart <<END
#!/bin/sh
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport && \
kextload   -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
END
chmod +x bt_restart

Second, make root its owner and move it to /sbin:

sudo chown root:wheel bt_restart
sudo mv bt_restart /usr/local/sbin

Third, add the command to the list of NOPASSWD commands in sudoers:

echo -e "\n\n# Restart bluetooth without password\n$USER ALL=(ALL) NOPASSWD: /usr/local/sbin/bt_restart" | EDITOR='tee -a' sudo visudo

Finally, create a script on your desktop that calls bt_restart:

echo '#!/usr/bin/sudo /usr/local/sbin/bt_restart' > ~/Desktop/"Restart Bluetooth"
chmod +x ~/Desktop/"Restart Bluetooth"

Done! Just double-click with your notebook's trackpad (or USB mouse) on the Restart Bluetooth on your Desktop.

Answer 5

I had the same problem and I think I spotted a possible cause of the problem. My mouse was called "My Name's mouse" with the apostrophe, maybe that was causing the errors.

I have changed the name to avoid using spaces and special characters, now is called just "mymouse" and I don't seem to have the problem anymore.

Answer 6

To summarize, here's a list of things mentioned here, in links from here, in similar threads at other sites, or even made up by me reasoning from those others. I've tried all of these, singly and in many combinations. All of them have seemed to work at least once; all have failed at least once.

• new mouse batteries
• remove and re-pair mouse
• turn off WiFi and mouse; connect Bluetooth mouse; restore WiFi
• turn off WiFi, mouse, and VPN; connect; restore
• delete Bluetooth PAN; connect
• kextunload/load USBTransport; connect
• wire kextunload to sleepwatcher; sleep; awake; connect
• disconnect all USB connectors (heck, all connectors); connect
• log out; log in; connect
• restart; log in; connect
• reset SMC (which involves "shut down"); restart; log in connect
• shut down VM hosting (such as VMWare, Parallels, or VirtualBox)

I choose to keep this list handy, and use "all of the above."

I think the only thing that's certain, here, is that there's a large dose of "random" involved somewhere, perhaps a race among all these drivers for networks, pseudo networks, layered networks, virtual networks, and proxy networks. In which case, it's probably not merely Apple's fault, because those drivers come from a variety of sources.

Of course, Apple's once-famous "just works" reputation was largely built on forbidding exactly this kind of colliding diversity.

Answer 7

I still have this issue in macOS Sierra. @Tyilo's link above to his gist gave me a starting point. But I also wanted to use homebrew to install sleepwatcher, and the plist files weren't set up properly out of the box. So I played around for a long time and came up with this script that got things working reliably for me.

brew install sleepwatcher
sudo touch /etc/rc.sleep
sudo tee -a /etc/rc.wakeup <<EOF
#!/bin/sh
# Sleepwatcher script to get bluetooth working after the mac wakes up
# Got this approach from https://gist.github.com/Tyilo/c92684d277acb62272b5
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
EOF
sudo chmod +x /etc/rc.wakeup
brew services start sleepwatcher
sudo tee -a /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>de.bernhard-baehr.sleepwatcher</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/sbin/sleepwatcher</string>
        <string>-V</string>
        <string>-s /etc/rc.sleep</string>
        <string>-w /etc/rc.wakeup</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>
EOF
sudo launchctl load /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist

Answer 8

Thanks to Tyilo from the comments on the accepted answer, I have modified his script to install sleepwatcher and append to the script some code that will not only unload the Bluetooth driver (com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport), but also restart blued, Apple's Bluetooth daemon.

The script can be found here: https://gist.github.com/timgws/fc63aeca6a248bbb25ff

Running this has resolved all the issues for me.

Answer 9

Aware that this is quite an old post now but was being driven nuts by the delay I was getting after sleep wake-up before the Magic Trackpad was usable.... could easily be a good 30 secs. Tried most / all of the hints and tips I could find to very little effect.

However, I just tried moving the Bluetooth icon on the Menu bar (CMD ALT Drag) from its normal position (about 7th in ) to 2nd in (as counted from the Right), i.e. next to the Spotlight menu.

So far?... problem gone !

Not 100% sure why this would be, but suspect it might be something to do with the order in which tasks from those items on the RHS Menu Bar are addressed after wake-up, i.e. those nearer RHS have higher priority?

Only takes a couple of secs to do, so if you also have this problem - might be worth a try?

(iMac 27" i7 / OS X 10.10.5)

JH

Answer 10

Most of the suggestion I've read seemed a bit complex for something as simple as this. Decided to take a noob approach:

1. Went to System Preferences/Mouse/Set Up Bluetooth Mouse
2. Screen displayed "No Mouse found" and started searching.
3. Turned my mouse off then turned it on again (Windows solution to a myriad of problems).
4. It found my mouse.

Answer 11

Looks like the kextunload commands don't actually work anymore on High Sierra. However, there's a 3rd party command line tool for doing the same thing and it works: https://github.com/toy/blueutil – you can tweak the scripts mentioned here to use blueutil instead, or there's even a full-blown solution (very similar to what we have seen on this page already): https://gist.github.com/ralph-hm/a65840c4f5e439b90170d735a89a863f

Answer 12

This article by Michael Kummer reports a fairly exhaustive list of failed attempts to fix bluetooth problems on mac, and finally suggests a compromised solution by disabling handsoff that seems working: https://michaelkummer.com/technology/mac-bluetooth-issues-affect-keyboard-trackpad/

Also seen in https://www.forbes.com/sites/bradmoon/2017/07/13/this-trick-may-solve-your-mac-bluetooth-connectivity-issues/#6fefb3f45196

Answer 13

Reinstall MacOS.

This is not really a solution solution but I just want to share my experience to give some hope to those who are facing the same problem as mine -- that this might still not be a hardware problem or wifi interference problem, which may be more costly or troublesome to solve that reinstalling MacOS.

What I experienced: After my 2015 Macbook Pro woke up from sleep, it could not connect to bluetooth devices. The problem had worsen overtime, from initially just little inconvenience (e.g., disabling and re-enabling bluetooth module or wifi could fix it) to later a huge pain (e.g., requires a restart with SMC/PRAM reset).

A symptom or side effect which might be related was that the computer sometimes took too long (10s of seconds) to wake up.

Reinstalling (clean) MacOS was my last resort but it seems to simply work. After reinstalling I did not observe any problem or hiccup with bluetooth, wifi, or sleeping.

Disclaimer: There is probably some proper fix that can achieve the same effect, which may or may not have been discovered yet. Also, reinstalling OS always comes with risks of losing data and productivity that one should evaluate.

New update: It was problem-free for a week. But then the bluetooth problem seems to come back sometimes. I did not do much tinkering with the system in the week other than installing some very common software and packages mainly through Homebrew.

Answer 14

Based on other people suggestions I created simple shell script to reset bluetooth. See gist for details.

Simplified version (depends on blueutil brew):

blueutil -p 0
networksetup -setairportpower en0 off
sleep 3
networksetup -setairportpower en0 on
sleep 3
blueutil -p 1

It turns off bluetooth, turns off wi-fi, turns wi-fi back on, and finally turns bluetooth back on.

Answer 15

UPDATE2: The last solution only worked for about a week. I have updated to macOS Mojave (10.14.6) and this issue appears to be fixed. Will monitor and report back if anything changes.

UPDATE: I have been able to solve this 100% after observing for months by going to System Preferences -> General -> unchecking Allow Handoff between this Mac and your iCloud devices

So I've been dealing with this on my Macbook Pro (Early 2015) for about as long as I've had it. Tried pretty much everything, kextunload/kextload, SMC reset, etc... to no avail. To be specific, my symptom is that after waking up sometime the bluetooth icon would have a squiggle through it like this: And would refuse to connect to any devices. This behavior was present on Yosemite as well as High Sierra (version I'm currently on).

The ONLY workaround that has worked with > 80% consistency for me (other than rebooting) is this:

System Preferences -> Bluetooth -> Uncheck Show Bluetooth in menu bar -> Check Show Bluetooth in menu bar then wait 10 seconds (at this point your bluetooth should be available and not have the squiggle through the icon)-> retry connecting device.

This has worked 80% of the time for me although sometimes I still need a reboot. Hope this helps.

UPDATE: This has prevented bluetooth unavailable but it appears bluetooth would just sometimes not connect / work even though the icon shows it's fine... Not really sure what to do any more. This seems like a problem Apple should investigate.

Answer 16

Try clicking the mouse after your Mac wakes from sleep.

This seemed to connect my Magic Mouse 2 faster with a Mac Mini running macOS Sierra (10.12.2).