If you’ve been following along from home, you’ll know that I’m building the pieces of a customer-presence-sensitive music system for restaurants. Part of this system is a Bluetooth device discovery system that looks for Bluetooth devices – phones, laptops, etc. – of registered customers, and uses their presence as a trigger to adjust the restaurant playlist.

The Bluetooth discovery server that I’m using for testing is a stock Mac Mini, running a modified version of haraldscan, a Python application. The server has been in place for a week for testing the “Bluetooth environment” and the script itself has been working well.

Except that every 12 hours the Mac Mini has been crashing. Or, rather, the scan process has been hanging.

At first I thought it was simply the Mac Mini going to sleep, or being turned off on a power bar, but I realized that the server itself was still alive, it just wasn’t running my process via launchd every minute as I’d set it up to do.

It was only when I logged in to the server itself and looked at the list of running processes that I learned the cause of the problem: there were hundreds of processes running like this:

.../BluetoothUIServer.app/Contents/MacOS/BluetoothUIServer \ 
-pair XX-XX-XX-XX-XX

And when I looked on the terminal screen, I saw the evidence of this: hundreds of dialog boxes from a device trying to pair:

These pairing requests were eventually bogging down the server to the point where it could no longer run new processes, effectively bringing the server to its knees.

I tried dealing with this in the usual ways: turned off the “discoverable” setting in the Mac Mini’s Bluetooth settings, and unchecking all the other settings that would allow the Mac Mini to automatically react to new devices. But to no avail.

Next I decided to try to find out what the mysterious device “6441” actually was. Originally I thought it was a Panasonic cordless phone, but then I used this helpful Bluetooth Device Address Lookup tool, which identified the device as being made by Ingenico, a name I recognized from debit and credit card terminals.

Sure enough, the mysterious “6441” was a Moneris 8200 pay-at-table terminal in the restaurant. So all I needed to do was to prevent it from making pairing requests, and the problem would be solved.

Unfortunately, after 3 calls to 3 different technical support agents at Moneris, I came to learn that this isn’t possible. There is, it seems, no way to prevent a Moneris 8200 terminal from trying to pair with any discoverable Bluetooth device within range: the only suggestions Moneris could offer were to either turn off Blueotooth on the Mac Mini or to move it out of range of the 8200, neither of which is feasible.

So I decided to approach the problem from the other end: I simply inserted this bit of code into the launchd script that runs the Bluetooth scanner on the Mac Mini:

killall BluetoothUIServer

This has the effect of killing any pairing request dialogs that have popped up in the minute since the process last run, effectively removing the constant pairing request issue an annoyance, but not a system-crippling problem.

I welcome any advice from others on alternative approaches to this.