Bluetooth Discovery Update

I’ve been testing a Bluetooth discovery process in Casa Mia Café since Sunday as part of the build-out of my Customer + Bluetooth + Last.fm system, and I’ve learned some things:

1. Over 3 days of scanning, 17 devices were detected in the café. As we’re not completely sure of the Bluetooth range in the Mac Mini doing the scanning, I don’t know whether this represents close to all of the discoverable devices or just those that were near that back of the café.
2. Of those 17 devices, there were 5 Nokias, 4 Blackberrys,  4 Samsungs, 1 LG, 1 Sony Ericsson, 1 laptop, and 1 Google Nexus One (which I was beside when it was scanner, and which we purposefully put into “discovery” mode).
3. It seems like iPhones and iPod Touches are never discoverable, which is why none of them show up, and the Nexus One (and maybe all Android devices?) are only discoverable for a limited period of time after you leave the settings screen.
4. I physically saw half a dozen laptops in the café over the 3 days, only one of which was picked up by the scanner; I suspect that most laptops either don’t have Bluetooth, or have it turned off.

If Apple is leading the way [sic] by purposefully hobbling Bluetooth, and if other vendors follow suit, this doesn’t bode well for a system built on the ability to discover Bluetooth devices.

Today I’m thinking about the possibility of adding to toolkit by looking at grabbing logs from the wireless access point in the café to detect MAC addresses of devices, Plazes-style. This would allow me to increase the variety of devices that could be detected, including laptops.

One step further and I could use something like NoCatAuth to allow customers connecting to the café wireless to register their devices if they wanted.

Otherwise I’ve been dealing with issues of the Mac Mini losing contact with the Internet; originally I thought this was because it was going to sleep, but it now seems that maybe it’s a combination of a Python script that’s not tolerant of being offline and a wireless access point that’s flaky at times.

Update: it turned out that the Mac Mini was just fine, but it was being pummeled by Bluetooth pairing requests from the Pansonic 6441 cordless phone right beside it, which was causing things to fall apart. I had no idea that cordless phones were Bluetooth-capable. I solved the problem by making the Mac Mini non-discoverable.

Another Update: It turns out that I also needed to uncheck “Prompt for all incoming audio requests” on the Mac Mini’s Bluetooth preferences. If I don’t do this then after about 12 hours the computer completely locks up with hundreds of BlueoothUIServer processes.

Another Update: Even when I uncheck the “Prompt for all incoming audio requests” box, the Panasonic 6441 phone still keeps trying to pair. How do I prevent this?

Another Update: I’ve discovered, by trying to track down the source of the Bluetooth Device Address of the offending device, that it’s not the Panasonic cordless phone, but rather the Ingenico pay-at-table card processor that’s trying to pair with the Mac Mini. Hmmm.

Another Update: I spent some time with several different agents at Moneris, the provider of the pay-at-table card processor, the final conclusion being that there’s no way to prevent their Moneris 8200 terminal from attempting to pair with surrounding Bluetooth devices. Their only suggestions were to (a) turn off Bluetooth on the Mac Mini or (b) move the Mac Mini out of range of the payment terminal; neither of these will work in our situation, so I’m going to have to see if I can control this on the Mac Mini end.

Another Update: Okay, I think I’ve been able to work around this problem by sticking the following in the Bluetooth scanning script that’s run every minute:

killall BluetoothUIServer

This kills any Bluetooth pairing request dialogs that have popped up, rendering the issue moot. I think.