Managing Bluetooth, or pesky Apple Preferences

BluetoothA project I am currently working on has several Mac minis driving large (50″ LCD and 61″ Plasma) displays, playing QuickTime movies and/or Keynote presentations full-screen. Essentially these are applicances – there is no interactive use of the Macs. Therefore there are no keyboards or mice connected to these Mac minis.

Since these Mac minis have Bluetooth on board, when they start up and notice no USB keyboard or mouse, they bring up the Bluetooth Setup Assistant, which is intended to help the user configure a Bluetooth keyboard and mouse for use with the system.

You can always open up the Bluetooth Preferences Pane and under “Settings,” uncheck “Open Bluetooth Setup Assistant at startup when no input device is present,” but since I have several of these machines, I want them all configured identically, and I want to easily set up additional machines the same way, I wanted to script this configuration. If it’s possible to automate a task, that’s preferable to having to remember to do it manually.

The defaults command in OS X can be used in scripts to set many system preferences. When attacking a problem like this, that’s the first place to start. You need to figure out what “domain” (or in practice, which plist file) contains the preferences you want to set.

Since it’s Bluetooth preferences we want to manage, the first place I looked was in /Library/Preferences. I looked there first, because I assumed these were system-wide preferences as opposed to per-user preferences. I was (mostly) wrong. There was no obvious file there. But in ~/Library/Preferences, I found

defaults read ~/Library/Preferences/
AuthenticationEnable = 0;
BluetoothSystemWakeEnable = 1;
BluetoothVersionNumber = 2;
ControllerPowerState = 1;
DiscoverableState = 0;
EncryptionEnable = 0;
OBEXFTPRootFolderLocation = "~/Public";
OBEXFileHandling = 1;
OBEXOtherDataDisposition = 2;
OBEXPIMDataDisposition = 2;
OBEXPIMDataSaveToLocation = "~/Documents";
PrefKeyBluetoothMenuExtraShowState = 1;
PrefPanelTabIndex = 0;
RFCOMM10BEnable = 0;

It doesn’t really look like the preference I want (something about Opening the Bluetooth Setup Assistant) is in there. I poked around a bit, looking for the key in other files (like .GlobalPreference.plist), and then remembered that the defaults command has a “find” verb:

defaults find Bluetooth
Found 4 keys in domain 'blued': {

Well, that’s interesting. What is blued? “man blued” informs us that it is the “Mac OS X bluetooth daemon,” but not much else of interest. So I looked around for a “blued.plist” file in what I thought were the logical locations:


But I failed to find them. So lets try find:

find / -name "*blued*" -print

Hey – /private/var/root/Library/Preferences/blued.plist looks promising:

defaults read /private/var/root/Library/Preferences/blued
BluetoothAutoSeekHIDDevices = 0;
BluetoothVersionNumber = 2;

The key BluetoothAutoSeekHIDDevices also looks promising. Using the Bluetooth Preference Pane and checking and unchecking “Open Bluetooth Setup Assistant at startup when no input device is present” confirms that this is the key I’m looking for.

I think this is a bit crazy. Originally, system-wide preferences were kept in /Library/Preferences, but of late, some seem to have been moved to /var/root/Library/Preferences. Another example is — pre-Tiger you could set the LoginHook and the LogoutHook in /Library/Preferences/; now you must do so in /var/root/Library/Preferences/

So, in my configuration script, I add this:

# turn off the Bluetooth KB/mouse dialog that comes up if no KB/mouse is found
`/usr/bin/defaults write /var/root/Library/Preferences/blued BluetoothAutoSeekHIDDevices -int 0`;

# restart the Bluetooth daemon
`/usr/bin/killall -HUP blued`;

I found that I had to restart blued or odd things would happen – probably because blued had already read its defaults before I changed them on disk.

In my testing, this seems to have the desired effect for subsequent restarts — if there is no input device on boot, the Bluetooth Setup Assistant does not come up.

Managing Bluetooth, or pesky Apple Preferences

4 thoughts on “Managing Bluetooth, or pesky Apple Preferences

  1. Jaharmi says:

    If you were managing the root home directory with Radmind, you might still want to take the blued.plist file out of management (put it in negative) since it seems to contain the list of Bluetooth devices that have been paired with the computer. In negative, if you had to make changes to it, you’d need a script like the one posted.

    I might also take one additional plist out of management in root’s Library, since it appears to contain info on at least a recent pairing:


  2. Dave says:

    Hey man,
    No joke! What’s up with Bluetooth? I have a MBP that I finally diagnosed. My problem: if I booted the computer out of range of my bluetooth mouse (macally), the scroll wheel wouldn’t work and the bluetooth prefs pane wouldn’t even show. Turns out blued wasn’t launched. I finally trashed the prefs for blued and started over. Just had to do it again after a UI hang last night, same problem. Property list editor couldn’t even open the blued.plist, although it seemed to be OK in a text editor.

    Bluetooth, at least on my MBP, seems quite fragile.

    Good post. I’ll have to bookmark it.

  3. Great information.

    Just as an FYI, I noticed you passed the full path the the blued plist. In my configuration script and testing, I’ve found writing to the relative domain itself works fine. e.g.

    defaults write blued BluetoothAutoSeekHIDDevices -int 0

    So long as you run this as root.

    Also, on a base installation of Mac OS X 10.4.10 8R4031, there is no BluetoothAutoSeekHIDDevices key, so the reader should not be alarmed if defaults read blued | grep HID finds nothing.

  4. Now if I can only find what files are changed with a given application. For example, I current have a installer I’m customizing and I want to be sure the this application doesn’t do a specific thing that would require an intervention from a user to fix. Clearly, once this preference is checked, it’s holding onto it SOMEWHERE, but I cannot work out where. The app is LogMeIn Client.

Comments are closed.