Follow-Me Phoning: Implementing Bluetooth Proximity Detection with Asterisk, Part II

This is the second in our series of articles showing how to deploy a Bluetooth Proximity Detection system with Asterisk®@Home. Part I is here. When we’re finished, your system will automatically transfer incoming calls in your home or office to your cellphone or any other phone whenever you leave home base carrying your bluetooth-enabled cellphone or your bluetooth headset. You’ll recall that we recommended the headset approach because cellphones have a nasty habit of putting themselves and their bluetooth adapter to sleep when you’re not on the phone. If bluetooth on the phone is sleeping, we lose our ability to detect your comings and goings so be reasonable and do it our way. Use a bluetooth headset. Once you remove the earpiece, the bluetooth headset fits comfortably in your pocket and isn’t much larger than a flash drive. For our purposes the bluetooth headset will be functioning primarily as an electronic key although there’s no reason you can’t also use it in conjunction with either your bluetooth cellphone, or a softphone connected to your primary Asterisk@Home PBX, or all of the above. The major difference in our approach and some of the other proximity detection systems which (still) are on the drawing boards is cost. Our bluetooth headset “key” costs roughly $30 delivered to your door. Most of the corporate dream systems require a $200 badge (to do the same thing) and then an incredibly expensive server (to do what we’re doing with an old clunker PC). So, yes, open source technology is a very good thing for all of us. And it deserves your financial support. Here’s a link if you’d like to make a contribution in any amount to the Asterisk@Home project. End of sermon.

NOTE: This article has been updated. For the current article, click here.

Installing Asterisk@Home. Today, we need to do a lot of the grunt work to get our system configured with the necessary software to support proximity detection. You’ll recall from the previous article that we’ve decided to use the Asterisk@Home 2 beta build for this project because we need Linux CentOS/4 that’s included to make everything work. So Step 1 is to download and install the Asterisk@Home 2 beta. From our previous Asterisk@Home installation tutorial, you’ll recall the drill involves downloading the .iso image, burning a CD, finding a clunker PC with a hard disk you don’t mind wiping clean (a WalMart special (inset) oughta work just fine!), booting from the install CD after connecting the new PC to your network behind the same firewall as your primary Asterisk@Home system, and then answering a few prompts. If you need a refresher course, review the original installation article or visit the new Asterisk@Home Wiki. Once you get Asterisk@Home 2 up and running, you need to secure your system as outlined in the above article. And then review the security article that will tell you how to lock down MySQL. Now run yum -y update to get CentOS/4 current, and you’re all set. Finally, a word about the beta itself. Some folks get nervous about using beta software. Don’t. Remember, we’re only using Asterisk@Home 2 for proximity detection at this juncture, and nothing in CentOS/4 is beta. By the time we get everything working, the full-blown Asterisk@Home 2 product will probably be on the street, and you can repeat this drill in your sleep to get ready for our next mega-project: Building A Redundant Asterisk@Home System.

Overview. Now that we have Asterisk@Home 2 up and running, we need to do a couple of additional Linux things. First, we need to add the Linux bluetooth software to your system. And then we need to install WebMin, the Linux answer to the Swiss Army knife. Once we get our software configured, we’ll plug in our dLink DBT-120 bluetooth adapter and take our new system for a spin. We’ll test our ability to detect other bluetooth devices such as a bluetooth-enabled cellphone or a bluetooth headset. Then we’ll be ready for Chapter 3 where we’ll actually start telling our primary Asterisk server when we’re IN and when we’re OUT.


Installing Linux Bluetooth Software. For the remainder of this article, we’re going to be working exclusively with your new Asterisk@Home 2 beta system so, when the instructions say to do something on your Asterisk box, that means on your Asterisk@Home 2 beta system not your primary Asterisk@Home PBX that is handling your phone calls. Log in to your new Asterisk box as root.

For those using Asterisk@Home 2.0 beta 6 or later, the bluetooth software comes preinstalled with CentOS 4.2 so you can skip this next download and install step. If you have an older version of the Asterisk@Home 2.0 betas, then, to download and install the bluetooth software for Linux, issue the following command:

yum install bluez-libs bluez-pin bluez-utils bluez-hcidump bluez-utils-cups

Your system will alert you that there are some dependencies and ask if you want to download them as well. Answer ‘yes’ and the download and install should proceed without incident. Once everything finishes, plug in your dLink DBT-120 USB bluetooth adapter and restart your system: shutdown -r now. When your system reboots or if you’re running beta 6 or later, log in as root and issue the following command:

/etc/init.d/bluetooth restart

You’ll probably be told that your system couldn’t stop bluetooth (because it wasn’t running) and then it’ll restart. Now let’s make sure everything is running that should be:

/etc/init.d/bluetooth status

You should see messages that look like this:

hcid (pid somenumber) is running ...
sdpd (pid somennumber) is running ...

If you’re alerted that some other application isn’t running, we don’t care. Now let’s be sure the system has found your bluetooth adapter:

hcitool dev

You’ll get a response telling you the system found device hci0 with the MAC address of the adapter. If you have a bluetooth-enabled cellphone, go get it now and be sure it’s on with bluetooth-enabled and not in sleep mode. Now issue the following command:

hcitool scan

The system will whir away for a few seconds and then will report back the bluetooth name assigned on your cell phone. It’s probably your name. Didn’t know you were advertising, did you? Note: you can’t do this with a bluetooth headset, but we’ll get to that in a minute. There are two ways to automatically start the bluetooth software when you boot CentOS. We’ll show you both, but you’ll probably want to install WebMin for future use anyway. The quick and dirty method is to run setup while logged in as root. Use the down arrow key to highlight System Services and press ENTER. Now use the down arrow to move down to bluetooth. Then press the space bar. Tab to the OK button and press ENTER. Now tab twice to the Quit button and press ENTER. Restart your server and you’re all set: shutdown -r now.

Let’s take a bluetooth break and install WebMin. We’re doing this primarily to show a simpler way of auto-enabling bluetooth at startup, but you’ll find lots of other uses for WebMin down the road.

Installing WebMin. There are lots of ways to install WebMin. We prefer the easy way which is to issue the following commands at a Linux prompt after logging in as root. Note: WebMin updates come out all the time. If you want to be sure you start with the latest and greatest version, go to their web site first and write down the number of the current version. Then substitute it below when issuing these commands:

cd /root
mkdir webmin
cd webmin
wget http://unc.dl.sourceforge.net/sourceforge/webadmin/webmin-1.240-1.noarch.rpm
rpm -Uvh webmin*


WebMin runs its own web server on port 10000. To start WebMin, issue this command: /etc/webmin/start. You access it with a web browser pointed to the IP address of your Asterisk box at that port address, e.g. http://192.168.0.108:10000. The login name is root. Then type in your root password and press enter. The main WebMin screen will display. Before we forget, we need to also make one change to the new Asterisk@Home configuration to avoid problems down the road. The default RTP listening ports for Asterisk@Home are 10000 to 20000 so there’s a conflict on port 10000. We just need to change it to 10001. Log in as root and, using an editor, call up the rtp.conf file: nano /etc/asterisk/rtp.conf. Now change the rtpstart port from 10000 to 10001 and save the change: Ctrl-W, Y, and press Enter.

Now back to WebMin. From the Main Screen of WebMin, click the System button and then the Bootup and Shutdown link. Find bluetooth in the list of applications and click on it. The Action Details screen should show that bluetooth is running. Now click the Yes button beside “Start at Boot Time?” and then click the Save button to reconfigure your server. That wasn’t hard, was it? We can stop WebMin now by issuing the following command: /etc/webmin/stop. No need to waste processing cycles for a tool we’re not using.


Configuring a Bluetooth Headset for Proximity Detection. As we mentioned in our first article, our device preference for the proximity detection project is a bluetooth-enabled headset. The two least expensive ones (about $30 including shipping) are the Plantronics M3000 if there are any left and the IOgear GBE201W7 from Buy.com. Remember, we’re going to be using the headset primarily as a “key” to tell Asterisk when we’re home and when we’re not. Cadillac charges about $400 for their electronic keys so this one’s a bargain. You obviously can use it for other stuff, too, but for now let’s get our “key” working. The hardest part of this drill is figuring out the MAC address of the headset. If yours happens to have 12 hex digits written on the box, lucky you! Otherwise, the only trick here is to put your headset in discovery mode. On the M3000, you activate discovery mode by simultaneously holding down the UP volume and Command buttons for about two seconds. When the light begins alternating between red and green, let go. With the IOgear unit, turn off the device and then hold down the multi-function button for about nine seconds. The red LED will turn on and then the blue LED will begin rapidly flashing. If only the blue LED is lit, you screwed up. Try again. Now from a Linux command prompt in close proximity to your headset, issue this command:

hcitool scan

You’ll get a response that looks something like one of the following:

Scanning ...
00:03:89:43:84:E2 M3000 by Plantronics
00:0e:a1:21:39:fc IOGEAR BT Headset


Write down the MAC address of your headset including the colons between the hex code digits. This is the notation we’ll be using to actually check whether your headset is within range. Here’s the command so try it out substituting the MAC address of your headset for mine below:

hcitool name 00:03:89:43:84:e2

Now run the command again and change the last digit of the MAC address to another hex number:

hcitool name 00:03:89:43:84:e6

There are two important points here. First, with the hcitool name syntax, the headset does not have to be in discovery mode which is just what we need for our proximity checking. And second, you’ll notice you got the device name when hcitool could find the headset and a null string when it couldn’t. So we can use a simple Linux bash script to determine whether your headset is within range by just checking whether a null string is returned to the above query. Wouldn’t you think some commercial developer could have figured this out and included it in their highly touted Proximity Checking products? Apparently not.


We’ll leave you with a simple script today to play with until we tackle Chapter 3. This script implements what we’ve just demonstrated. All you need to do is create a new file in the /tmp directory of your new Asterisk server: nano whereib. Then cut-and-paste the code below and modify the MAC address shown for deviceid= to match your headset. Then save the file: Ctrl-X, Y, and press enter. Now make the file executable: chmod 755 whereib. And then run it: ./whereib. Once it’s running, turn on your bluetooth headset and walk around your home or office. Then come back and check the display. It should report when you’re in range and when you’re not. I think you’ll be pleasantly surprised by the range of your bluetooth devices so the basement furnace room may not be a bad location for your new server after all. You can end the script by pressing CTRL-C. In our next article, we’ll wrap up the bluetooth proximity series with Chapter 3 where we’ll get everything connected up to your primary Asterisk server which will handle the actual call forwarding when you’re away from your home or office.

#!/bin/bash
# Syntax: ./whereib
# On a clunker PC it takes about 20 seconds for a test to fail
# and it takes about 5 seconds for a test to succeed, i.e. BT MAC found

deviceid=00:03:89:43:84:e2
devicename=HEADSET

count=0
while [ $count -lt 1 ] ; do
hcitool name $deviceid > /tmp/$devicename
if [ -s /tmp/$devicename ] ; then
echo $devicename IN RANGE ;
date
else
echo $devicename OUT OF RANGE ;
date
fi
sleep 7
done

Some Interesting Bluetooth Reads. Here are a few articles to give you an idea where all the bluetooth proximity detection stuff is headed. If it’s good enough for Bill Gates’ home, it’s good enough for yours.

  • Wireless Hotel Check-In and More
  • Wearable Hub for Communications in the Home
  • Blind Dating via Bluetooth
  • Bluetooth ID Badges
  • Bluetooth HandsFreeProfile for Asterisk
  • Smarter Schmoozing
  • Proximity Dating Service
  • Hacking Secure Bluetooth Devices
  • HINT: Using Applescript with the Nerd Vittles’ Telephony or Home Automation Server Projects for the Mac mini
  • Other Asterisk Tutorials. There are numerous additional articles in this Asterisk HOW-TO series to keep you busy. You can read all of them by clicking here and scrolling down the page. We recommend reading at least the first four or five articles from the bottom up so that the learning curve is less painful. Then you can skip around to your heart’s content.

    Be Sociable, Share!

    8 Responses to “Follow-Me Phoning: Implementing Bluetooth Proximity Detection with Asterisk, Part II”

    1. Jenn says:

      Fantastic articles so far. I’m anxiously awaiting the 3rd.

      Question: in the headset instructions, it isn’t clear why you changed the last digit of the MAC to another hex number. Can you explain?


      Write down the MAC address of your headset including the colons between the hex code digits. This is the notation we???Ǭ?Ǩ??ɂİ?Ǭ?Ǩ??ɂ?Ǭll be using to actually check whether your headset is within range. Here???Ǭ?Ǩ??ɂİ?Ǭ?Ǩ??ɂ?Ǭs the command so try it out substituting the MAC address of your headset for mine below:

      hcitool name 00:03:89:43:84:e2

      Now run the command again and change the last digit of the MAC address to another hex number:

      hcitool name 00:03:89:43:84:e6

      [WM: It was simply to demonstrate that you get the name of the device returned when you enter an existing MAC address, and you get a null string when you enter a non-existent MAC address. All will be made clear ... in Chapter 3.]

    2. Andy says:

      Why are you making things so difficult for yourself? Check out btp from digium cvs it’s a much neater and more integrated solution.

      [WM: We didn't really think much of our approach was difficult. In fact, it's pretty simplistic. But, each to his or her own, I suppose. I'm not sure many would share your view that compiling and configuring a CVS release of Asterisk is exactly a walk in the park. While I haven't checked lately, my recollection is that the Bluetooth Presence Daemon (asterisk-btp) lacked the necessary support for detecting Bluetooth headsets. And I hope our article made clear that this is the only practical way to implement Bluetooth Proximity Detection. Most Bluetooth cellphones usually have Bluetooth disabled when they are in "sleep" mode which makes them virtually useless for accurate proximity detection.]

    3. Andy says:

      Although installing and configuring asterisk isn’t as easy as it could be, it’s not rocket science. Aside from that, btp doesn’t invlove a full cvs checkout. IIRC, asterisk@home does actually use a source install and builds it at install time. This means only btp needs checking out and building which is trivial.

      One of the problems with using headsets is the distance from the bt device tends to be pretty short (<10m) – The advantage of using a phone is that this can be much futher (<100m) – although those distances are maximums… Personally I use a SE P910i which doesn’t suffer from any of the side effects you mention (loss of bt on sleep) and gives good range. This essentially means I get coverage throughout the house (European houses tend to have brick internal walls). BTP also allows any linux box with a BT dongle to act as a reporter – reporting presence back to an asterisk server.

      You are correct that BTP doesn’t allow the method you employ, but that shouldn’t be too difficult to rectify :)

    4. Andy says:

      update:

      Ok, I found the cheapest (oh and I do mean cheap – nasty nasty cheap) bluetooth headset that I could – it cost about 4.99 (I’m sure the shop would have paid me to take it to be honest)- it’s totally useless as a BT headset, but as a BT tag it’s wonderful. I’ve just added it to my chan_btp/btpd config and it works perfectly. I think I’ll need to ge the Dremel out to make it better looking though.

      asterisk*CLI> show btp
      Bluetooth Presense Clients:
      andyhs/20:03:03:17:19:2C — SIP/2207 (score=246)
      Bluetooth Presense Locators
      test — SIP/2207

      Headset info:

      Manuf: Rayzor
      Model: BT-HS-01
      WWW : http://www.rayzor.nl

    5. Clint says:

      I’m using Asterisk@Home 2.2. When I try to rpm -Uvh the download (BTW, above link didn’t work) It says it’s not an RPM package. Not sure what the cause is yet, if I figure it out I will post it.

      [WM: WebMin works for me. You might want to try downloading 260 now that it's available.]

    6. David says:

      One thing that I’ve found is that if the headset and phone are connected then

      hcitool name MAC

      returns null. If they are not connected (and turned on) then I get the name as expected.

    7. Mike says:

      Hi, great article…I’m a bit of a linux novice. I can’t actually get my system to pick up the bluetooth dongle in the first place? Any idea’s on why this might be happening and how to resolve it? I’m running CentOS 4.2.

    8. newdawn says:

      Could anybody help me??? I did everything as its written here, but the system cant find my bluetooth device with hcitool dev. I get a null string. And its a dlink dbt 120. Im working with vmware, and trixbox. Please somebody help me!!!

      [WM: Bluetooth didn't work with the VMware build of trixbox 1.2.3. Download PBX in a Flash and use it. Bluetooth works out of the box.]

    Leave a Reply

    Ringbinder theme by Themocracy