Volume Number: 19 (2003)
Issue Number: 2
Column Tag: The Automatic Mac

Taming Open Source

Converting open source apps to control your OS X Mac and your home

by Chuck Shotton

There are lots of ways to tackle the challenge of bringing Open Source software to the Mac OS X universe. If you work your way through this article, by the end you should feel comfortable with most of the following:

• The basics of converting open source command line applications for use with Mac OS X

• Using Project Builder to modify and build Unix tools for Mac OS X

• Interfacing your Mac to home automation hardware

• Using the Unix underpinnings of Mac OS X to build a home automation system

There is a great potential to grow this project in many directions. Having built the system described here, we will be able to add user interfaces via AppleScript Studio, Web-based interfaces using Apache, PHP, and MySQL, and give you the ability to control your Mac remotely to create some amazing applications. But those are future topics and we need to address the basics of Open Source, Mac OS X's Unix underpinnings, and home automation first.

Computers that interact with the real world and each other have always intrigued me. The World Wide Web provided the first platform for most people to experience the power of two computers cooperating to perform a service greater than what either could do alone. Add to that mix the ability for your computer to interact with the local environment and you start to approach geek nirvana. So, in addition to Internet communications apps, I've also been a long-time fan of home automation. This series of articles will attempt to combine all these interests by using some off the shelf Unix and Linux software and the powerful Mac OS X development tools to create an environment for adding automation to the mix of tasks your computer running Mac OS X can perform.

MacTech ran a great article not too long ago, describing the basics of home automation and the X10 power line carrier protocol on the Mac. It is recommended reading before proceeding and the on-line version can be found at: <http://www.mactech.com/articles/mactech/Vol.16/16.06/HomeAutomation/index.html>. Unfortunately for Mac OS X users, the number of home automation software packages that have been converted to Carbon or Cocoa applications can be counted on a couple of fingers. You can always opt for one of the of the shelf solutions, which are all quite capable (in which case, you should move along.) If you are interested in getting your hands dirty, figuring out how to move open source apps to Mac OS X, and building your own solution, then let's roll up our sleeves and get to work!

One of the greatest advantages of Mac OS X lies in its Unix heritage. All of that power under the hood means that you should (theoretically) be able to take advantage of a lot of open source software. There are literally thousands of software packages available from places like SourceForge.Net, FreshMeat.Net, and via nifty tools like Fink (<http://fink.sourceforge.net/>). The reality is that it is often a lot of work to move a project from the Linux or BSD world into OS X. Unless you're comfortable with the world of shell scripts, Make files, vi, emacs, and the command line, this can be a daunting task. And even if you've worked with Linux, Solaris, or some other flavor of Unix-like operating system, Mac OS X does things differently enough to throw even hard-core digit heads for a loop.

While I've spent many years mucking around in the innards of various Unix systems, using command line tools and the litany of frightening things listed above, Apple has provided every OS X user with a much nicer set of tools in my opinion. Project Builder, AppleScript Studio, and all of the associated OS X development tools provide a much more approachable environment for doing Mac development. In an ideal world, all those thousands of open source projects would include the necessary project files for OS X developers to build each application using Apple's tools. Unfortunately, Mac OS X is just too new and many of these open source projects have been around literally for decades. Expecting more than a handful of them to have support for OS X development tools is not reasonable at this point. So we have to take matters into our own hands.

In order to get comfortable moving open source applications into the OS X development tools, we'll start with a relatively straight-forward solution that should provide some high geek appeal as well as actually do something quite useful. As with any good Unix project, we have to start with the acronym-based name first (sort of like designing the icon for a Mac app before writing any code). MUSCLE (Macintosh/Unix Shell Command Lighting Environment) seems sufficiently imposing and is reasonably descriptive. MUSCLE will actually be a suite of applications that cooperate to allow your Mac to interact with lights and appliances in your home via X10 and to allow X10 commands to be sent to your Mac, triggering events, scripts, and applications.

MUSCLE is based on two venerable Unix apps, heyu and xtend. Both are designed to talk to the real world via a CM11a X10 computer interface. The CM11a is far and away the most common interface for controlling lights and appliances and can be obtained from numerous on-line sources as well as stores like Radio Shack. Before getting started with this project, you'll need to collect the appropriate tools, source code, and hardware elements. Below is a list of the mandatory and optional ingredients. Download and/or purchase the appropriate components. Don't worry about what to do with the source code just yet. Just save the archives in a safe place and we'll get to them in a bit.

The heyu source can be downloaded from the heyu Web site at <http://heyu.tanj.com/heyu/>.

Source code for xtend should be downloaded from <http://heyu.tanj.com/heyu/beta/xtend-1.2beta4.local.tgz>. This is a copy of the xtend source code that has already been modified by the heyu author for compatibility. The original xtend home page can be found at <http://www.jabberwocky.com/software/xtend/>

If you don't already have the latest developer tools installed for Mac OS X, visit <http://developer.apple.com/tools/macosxtools.html> for instructions on how to download the installer that is appropriate for your version of Mac OS X. Note that you can download versions for both OS X 10.2 as well as 10.1.x, so make sure you get the appropriate tools for your OS release.

X10 modules for controlling lamps, appliances, and other devices are relatively inexpensive. Two great sources for all the X10 components you'll need are X10.Com and SmartHome.Com. At a minimum, you'll need a CM11a computer interface and one lamp module for testing. If you want to get fancy, some sort of remote control or tabletop controller will be required to send X10 commands to your Mac. Both suppliers have bundled collections of X10 components that provide everything you need to get started for approximately $40-$60. Check out these links as a starting point:

http://www.smarthome.com/1142.html

http://www.x10.com/products/x10_ck11a_1.htm

X10 computer interfaces lag somewhat behind the current state of the art. While all new Macs and most PCs come with USB serial interfaces, most X10 controllers still rely on old-style RS-232 serial interfaces. If you have an older Power Mac capable of running OS X, which has the original round DIN-8 serial connectors, all you need is a 9-pin RS-232 to 8 pin DIN adapter cable. (Note! Power Macs in the old 7500-9600 series make great home automation boxes and are perfectly capable of running OS X with the addition of an inexpensive G3 processor upgrade card and the free XPostFacto utility.)

If you have a newer Mac with only USB interfaces, you'll also need to throw a USB to serial adapter into the mix. It is important to have a true serial port adapter and not one of the USB PDA adapters. OS X driver support is imperative, so shop wisely. Keyspan makes several USB to serial adapters that are known to work fine with OS X and the CM11a interface. They also have products with 9 pin or 8 pin serial port support. Choose accordingly. See <http://www.keyspan.com/products/homepage-Serial.spml> for details.

Before we start hacking away at the source code for our MUSCLE system, we need to make sure all of the hardware is in place and functioning. There is nothing more frustrating than hours spent debugging software only to find that the problem is a ratty serial cable or flakey piece of hardware. Let's begin is by ensuring that all of the X10 and serial port hardware is properly installed and working as expected. The best way to do this is to get a demo version of one of the existing commercial Mac home automation apps, install it, and make it turn some lights on and off.

The two leading commercial applications for home automation on the Mac are XTension from Sand Hill Engineering, and Thinking Home from Always Thinking. XTension is far and away the most powerful X10 application because of its incredible support for AppleScript and phenomenal on-line support from the XTension user community. Unfortunately, a native OS X version hasn't been released yet, so you need to boot under OS 9 to test everything out. Alternately, you can get a copy of Thinking Home, which has a Carbonized version of the application that can be run under OS X. It's geared towards a less technical audience, but is perfectly capable of being used to evaluate your hardware set-up. Download one of these two applications from the following sources:

XTension - http://www.shed.com/

Thinking Home - http://www.alwaysthinking.com/products/

thinkinghome-main.html

Once you've evaluated your X10 hardware set-up using one of these applications, we're ready to move on to porting some open source applications to OS X and creating our own system to allow Mac OS X to interact with the real world. Here's a brief outline of the steps to take to complete this portion of the project.

• Un-archive heyu and xtend source and set up a build directory

• Configure Makefiles for each application

• Create Project Builder projects for each application

• Adjust Project Builder settings to match Makefile build environments

• Make source code modifications for OS X compatibility

• Install and test heyu

• Install and test xtend

• Create basic AppleScript interfaces to heyu and xtend

The first thing we need to do is create a folder where we'll do all the work. Open your Home folder (shift-command H in the Finder) and create a new folder called "muscle" in your Home folder. It's likely that Stuffit Expander has already done its thing and un-archived the heyu and xtend distributions. If not, drag the archives over Stuffit Expander. Then copy the resulting folders (heyu.dir and xtend-1.2beta4.local) into your "muscle" folder. To make things easier, rename these two folders to be simply heyu and xtend, respectively.

Neither heyu nor xtend come out of the box ready to build. As is the norm with many open source projects, they come with configuration scripts. These scripts are run to analyze the target system (in this case, Mac OS X) and determine what tools, libraries, headers, etc. are available. This information is then used to configure the Makefile, generate header files, and do anything else that is platform dependent. Before we move the source code for these two applications into Project Builder, we need to run the configuration scripts for each of them so we can discover what libraries and compiler flags are necessary as well as make the automated changes to any header files, etc.

Start by opening up a Terminal window. We'll configure heyu first, then repeat the process for xtend.

In the Terminal window, type the following commands:

cd ~/muscle/heyu
./Configure freebsd

which moves us into the heyu directory we created earlier and then configures the Makefile for a freebsd-like system (which is what Mac OS X is, more or less). Before we load the heyu and xtend source code into Project Builder, let's finish configuring xtend.

Type the following into your Terminal window:

cd ~/muscle/xtend
./configure --with-lockdir=/tmp

This hops over to the xtend directory and then configures its files, specifying that the /tmp directory should be used for its lock files as well.

Now both projects have been properly configured and we can proceed with loading them into Project Builder.

Project Builder handles almost all of the work associated with building relatively simple open source apps like heyu and xtend. We just have to tell it a few additional build parameters and then it's possible to modify source, build, and run projects from inside of Project Builder instead of having to use all the crufty command line tools. Let's start by creating the project file and loading the source code for heyu.

In Project Builder, select File->New Project...

The Assistant dialog presents many different project types. We want to build a simple C "tool", so scroll to the very bottom of the list and pick "Standard Tool," then click "Next."

The next screen asks us to enter a project name and location. Name this project "heyu" and change the location from "~/" to "~/muscle/heyu", omitting the quotes. Click "Finish."

Now the heyu source code has to be loaded into the Power Builder project. First, we need to get rid of the "main.c" file that was created by Project Builder. Click on the triangle beside the "Source" group, right click on the Main.c file, and select Delete. When prompted, delete both files and references.

Once the Source group is empty, the quickest way to repopulate it is to drag and drop all the appropriate heyu files into the project window. Open a Finder window showing the ~/muscle/heyu directory. Command-click to select each of the individual .c and .h source files, then drag them into the Source group in the Project Builder window. Note that you should omit the "dusk.c" and "sunrise.c" files. They are part of a related utility program and not actually used to build the heyu application.

When prompted by Project Builder, make sure the files are being added to the "heyu" target. You might want to change the "Reference Style" pop-up to be Project Relative from Default if you thing you might access the project files over a network or move them to a different location later. Click "Add" to complete this step. The Source group should now contain 22 files and look like Figure 1.

The last, and most important step, is to add the appropriate compiler and linker flags so that Project Builder replicates the same build steps that the command line oriented tools would have done via the make command. First, we need to see what has been added to the Makefile for heyu that we need to keep. Drag the "Makefile" file in the heyu folder over the Project Builder icon in the Dock.

The top portion of this file contains several definitions that are used to provide arguments to the C compiler and linker. These are the important lines:

#This makefile is built for freebsd
CC = gcc
CFLAGS = -g -O $(DFLAGS) -Wall
LIBS = -lm -lc
DFLAGS= -DHASSELECT -DNEEDGTIME -DFREEBSD

The CFLAGS variable contains a list of relatively standard arguments for added debugging symbols, optimizations, etc. All of these are controlled elsewhere in Project Builder and we don't really need to be concerned with them. The important line is the last one, which defines several compile time flags we'll need to transfer to Project Builder so it builds heyu as expected. Select and copy the text "-DHASSELECT -DNEEDGTIME -DFREEBSD".

In Project Builder, select the Project->Edit Active Target... menu (or type option-command E). Now click on the "GCC Compiler Settings" item and paste the copied text into the "Other C Compiler Flags" field. Figure 2 shows what the Compiler Flags field should look like when you're done.

Repeat the process for the arguments after the "LIBS" variable in the Makefile. Copy the text "-lm -lc" and paste it into the Linker Settings panel's "Other Mach-O Linker Flags" field. This ensures that Project Builder will link the heyu object files with the appropriate libraries. Refer to figure 3 for details on Linker Flags.

heyu is almost ready to build. Only one minor source file edit needs to be made. Select the x10.h source file from the list of files in the Source group. After the file opens, scroll down about 1 page until you see a line that looks like:

#define LOCKDIR "/var/lock"

Unix purists will probably disagree with what I'm about to tell you to do, but this definitely works and is much safer than relaxing permissions on directories that could contain sensitive info at some point. Change the line above to the following:

#define LOCKDIR "/tmp"

Save the file in Project Builder now we're ready to build the heyu application. Click on the build button (the hammer icon) or select the Build->Build menu. A few warnings will show up, but the final message in the build window should be something like figure 4.

While the temptation to run heyu may be large at this point, don't do it yet. We still have to configure some data files and need to create the project files for xtend as well. For now, close the heyu project window.

Creating the project files for xtend is nearly identical to the process we used for heyu. Start by creating a new project using the "Standard Tool" template. Name the project "xtend" and put it in the "~/muscle/xtend" directory.

Remove the Main.c file from the Source group and then drag and drop all of the .c and .h source files from the ~/muscle/xtend folder into the Project Builder window as before. You should end up with 12 files in the Source group, as shown in figure 5.

Now we need to add compiler and linker flags from xtend's Makefile to the Active Target settings. Open the Makefile by dragging it over the Project Builder icon in the Dock. In the Makefile, you'll see that there are no linker flags (LDFLAGS) and only one compiler flag (CFLAGS) that is of any interest (i.e., "-DHAVE_CONFIG_H"). Copy that single compiler flag and paste it into the GCC Compiler Settings panel's Other C Compiler Flags field. Refer to figure 6 for details.

xtend has a couple of source code incompatibilities with OS X. If you build the project at this point, you'll see what I mean. One of the problems is that a variable named commandtable is defined in two different source files. Older, less picky Unix compilers would often ignore a problem like this, assuming that they were references to the same variable. The gcc compiler under OS X isn't so slack, so we need to correct the problem.

It's a simple fix. Open the xtend.c source file and scroll down about a page to a line that looks like:

char *commandtable[NUM_COMMANDS][16][16];

Change it to:

extern char *commandtable[NUM_COMMANDS][16][16];

Save the file and build the project again. No more errors, but a few warnings. Unfortunately, we're not quite done. While everything builds OK, xtend won't run properly if you try it. It was written to use an older system call, "vfork", which needs to be updated to use a variant supported by OS X. (The terminally curious can enter "man vfork" in Terminal session for all the gory details.) To correct this problem, we need to edit the exec.c source file. There are two instances of the line:

child = vfork ();

Both need to be changed to:

child = fork ();

Now you can use the Build command to rebuild the xtend application with these changes. Compare with figure 7 to make sure it built as expected. That wraps up all the modifications necessary to convert both heyu and xtend to Project Builder format. Now it's time for the fun stuff.

As noted earlier, both heyu and xtend have multiple configuration files that need to be modified and copied to the proper location before either application can be run. This process is a little challenging because, as with most Unix-style config files, heyu and xtend use file names starting with a period ("."). This makes the file invisible in normal directory listings, and unfortunately, Mac OS X is a little overzealous and also prevents us from easily editing these "dot" files using normal GUI tools.

To get around these restrictions, we need to edit the original configuration files that are part of the heyu and xtend distributions, then copy them to the proper locations, renaming them along the way. Whenever we need to make changes, we'll modify the originals and copy them again. That way, we avoid the hassles of having to modify the operational config files directly with command line editors like vi or pico and we get back-ups as well.

Let's start by getting heyu configured and running. Since xtend depends on heyu for its communications, we'll save xtend for last. The sample heyu config file is located in the ~/muscle/heyu directory and is called "x10config". Open the Project Builder project for heyu and use the Finder to drag this sample file from the heyu folder into the "Products" group at the bottom of the Groups & Files pane in the Project Builder window. When prompted, make sure you select "Project Relative" as the reference style. This file should not be part of any target, so make sure the "heyu" target is deselected in the list of targets. After dismissing the dialog, you should see the x10config file in the Products group and the checkbox in the left margin should be deselected. If it is checked, uncheck it. Otherwise, Project Builder will try to invoke some sort of compiler for the config file and it won't be pretty.

Select the x10config file and we can make some quick edits to get heyu up and running. The only mandatory change we must make is to tell heyu what serial port device it needs to talk to. This value is set (on line 35) with the configuration command that looks like:

TTY      /dev/ttyS3

Unfortunately, this is merely a placeholder. You need to track down the real device name for your USB to Serial converter (or your legacy serial port) and replace the /dev/ttyS3 placeholder with the real name.

Since the actual device we need to specify here varies based on your serial port, you'll have to discover the correct value as follows. If you are using a legacy PPC machine (7500-9600, for example) the serial port will be a device like /dev/tty.modem or /dev/cu.printer, depending on which serial port you have the CM11a plugged into. If you have a KeySpan USB->Serial converter installed, you'll need to use the Terminal application to list the /dev directory and discover the actual device name. In a Terminal window, enter:

ls /dev

You should see a fairly lengthy listing. Keyspan devices have names like "tty.USA19QW1223P1.1" or "cu.USA19QW1223P1.1". You'll need to consult the documentation for adapters from other vendors in order to determine their naming conventions. One important thing to note about Keyspan adapters is that the device names can change if you move the adapter around on your USB bus. You'll get a different device name each time you plug the adapter into a different USB port or hub, so remember to track down the new device name if you shuffle cables around in the future.

It is important that you select the proper device name. As you may notice, Keyspan hardware has two device names mapped to the same hardware. One device starts with "cu" and the other starts with "tty". The differences are subtle but can make a huge difference in whether heyu works or not.. In general, Unix devices that start with "cu" are character oriented devices and do not interpret serial port signals like DSR or DTR. "tty" devices are assumed to be connected to terminal hardware and are supposed to pay attention to these hardware signals. Interestingly, if you are using a legacy Mac with old-style Mac serial ports, you want to use the device whose name starts with "tty". With Keyspan adapters, you need to use the "cu" device. You'll have to experiment with other hardware brands, but try the "cu" device first.

At this point, any additional changes to the x10config file are optional. The comments at the top of the file describe various commands you can enter in this file. You might want to examine the device aliases near the top of the file and adjust the names and X10 addresses to match your actual set-up, but this isn't required.

What is required is that we place a copy of this file in your home directory, and rename it so heyu can find it when it starts up for the first time. This step will need to be repeated each time you modify the config file using Project Builder. Of course, if you're comfortable with vi, pico, or emacs, you can just edit the config file directly in the future. To finish the installation of heyu, open a Terminal window and type:

cp ~/muscle/heyu/x10config ~/.x10config

This puts a copy of the config file in your home directory and renames it to the name expected by heyu. Alternately, you can always modify the source code to look for a different file name. Removing the leading "." might be a handy modification since it would let you open the config file for editing by double-clicking on it in the Finder. (As you may have already discovered, the Finder refuses to display files whose names begin with a ".")

Now we're ready to run heyu for the first time. As a test, lets assume you have a X10 lamp module plugged in with the address "A1" configured. In a Terminal window, type:

~/muscle/heyu/heyu turn A1 on

If everything is configured correctly, the light attached to the X10 module should have just turned on. You can reverse the process with the command:

~/muscle/heyu/heyu turn A1 off

Running heyu with no arguments will give to a list of all the other commands you can execute.

What you may not have noticed is that after the first time you ran heyu, it left behind a running process. If you use a Terminal command like:

ps ax

you should see a running process called heyu_relay. This little daemon handles communications between the CM11a and the command line heyu application. It also handles writing data received from the CM11a to a file on disk. It is this "spool" file that xtend will use when it needs to receive commands from other X10 devices.If you're curious, the file is written to the path /var/tmp/heyu.out.

heyu has an additional configuration file, x10sched.conf.sample, which contains commands that can be downloaded directly to the CM11a for timed execution, even if your Mac is turned off or disconnected from the CM11a. You can make changes to this file an copy it to ~/.x10sched.conf to implement your own timed macros. But getting xtend to work with heyu is a much more powerful solution, so let's continue.

All that we have left to do is modify and copy xtend's configuration file. As with heyu, add the xtend config file to the xtend Project Builder project. The sample xtend config file is named "sample-xtendrc". Once it has been added to the project, open the sample-xtendrc file and let's make a few changes.

Recall that xtend's role in the MUSCLE system is to receive incoming X10 commands and do something smart with them. Up to this point, we've been concerned with having our Mac tell X10 devices what to do via heyu. xtend will now give the Mac the ability to receive commands via the CM11a from real world devices like X10 table top controllers, wireless remotes, motion detectors, and other X10 transmitters.

The purpose of xtend's configuration file is two-fold. It defines what actions the Mac is supposed to take when it receives a particular X10 command. It also allows you to define complex sequences of events that can happen when triggered remotely or when triggered by a timer. The xtend config file is a bit complicated and it's worth spending some time reading through it from top to bottom to get a feel for what's possible.

While the examples in the sample-xtendrc file are instructive, it's highly unlikely that they'll be useful for your particular X10 set-up. You should probably delete or comment out all of the lines that define triggers, macros, and timers. For demonstration purposes, we'll make a simple timer that turns lights on and off at set times, and a trigger that makes the Mac speak an alert when a X10 motion detector is tripped.

Add the following lines to your sample-xtendrc file. Note that there are tab characters between each field and each line starts with the command "timer", "trigger", or "macro". You'll also need to replace the text "your_name" with your actual account name on OS X:

timer    smtwtfs   01/01-12/31 07:00   22:00   desk_lamp_on desk_lamp_off
trigger   a2  on    motion_on
trigger   a2    off    motion_off
macro   desk_lamp_on    /Users/your_name/muscle/heyu turn a1 on
macro   desk_lamp_off   /Users/your_name/muscle/heyu turn a1 off
macro   motion_on       /Users/your_name/muscle/motion_on_script
macro   motion_off      /Users/your_name/muscle/motion_off_script

A quick interpretation goes like this. The first line defines a timer that turns on the device at address A1 at 7 AM and off at 10 PM, every day of the week for the entire year. It uses two macros, desk_lamp_on and desk_lamp_off, to do the hard work. These macros, in turn, invoke heyu to turn the light on or off.

The two trigger commands define how your Mac is supposed to react when it receives an on or off command for the X10 device address "A2". In this case, we are going to have xtend invoke one of two macros that will run AppleScripts that will speak a message.

Save these changes, and copy the sample config file to your home directory with the following Terminal command:

cp ~/muscle/xtend/sample-xtendrc ~/.xtendrc

To create the two AppleScripts, fire up the Script Editor and enter the following AppleScript code:

say "Intruder alert! Intruder alert! Danger Will Robinson!"

and then save the script as an application with the "Never show start-up screen" checkbox selected. Name it "motion_on_script" and save it in the muscle folder. Repeat the process to create the "motion_off" script with a suitable message, naming it "motion_off_script" and saving in the muscle folder as well. Run both to make sure they work as expected.

Like heyu, running xtend for the first time starts up a background daemon process that handles all processing of X10 messages. You only need to run xtend once. If you need to modify your config file to add new triggers or timers, you will need to quit and restart the xtend process. Let's start by running xtend with the Terminal command:

~/muscle/xtend/xtend

If everything goes as expected, you should actually see nothing happen in your Terminal window. The best way to test that xtend is up and running is to issue the following command:

ps ax

and look for the xtend process in the list of running processes. For example, a fragment of the process status report might look like:

4080  ??  Ss     0:00.50 heyu_relay
4091  ??  Ss     0:01.70 xtend

You can see that xtend is up and running as process number 4091 in this case. If you tweak the config file for xtend, you need to kill the process and restart it, so it reads its configuration file again. Use the actual process number from your previous "ps" command and issue the following command:

kill -9 4091

This stops xtend (assuming you used the correct process number), and you need to re-run xtend to get it to read the new configuration, using the same command you used to run it the first time.

Assuming that xtend is up and running, you should be able to send your Mac an on or off command for device A2 and have it speak to you. Using a table top controller, a wireless remote, or some other X10 device that can send X10 signals, send an On command for A2. xtend should fire up the "hello_script" with obvious results. You can also test xtend's functionality by adjusting the on and off times for a timer in the xtend config file and watch while it does its thing.

The one missing piece so far is providing an easy way to operate remote lights and appliances from the Mac's user interface. While the gory details of how to do this are best left to future articles, here's a quick example to get you started. AppleScript under Mac OS X has great integration features with the underlying Unix environment. Consider the following AppleScript snippet:

do shell script "/Users/your_name/muscle/heyu/heyu turn a1 on"

If you place this statement in an AppleScript applet saved as an application, you can place an icon on your desktop or in the Dock that will turn on the lights with a simple mouse click. The "do shell script" command is an extremely powerful and useful addition to AppleScript. Using it in conjunction with AppleScript Studio would allow you to build quite elaborate user interfaces for controlling the real world from your desktop.

This completes the basic integration of heyu and xtend. There are limitless possibilities for extending this project. In the future, we'll address adding graphical interfaces to these applications, providing web-based interfaces, and some nifty projects like controlling iTunes via a wireless X10 remote. The "to do" list also includes making heyu and xtend start automatically at boot time, integrating both with a database like MySQL to keep track of device status and configuration info, and adding support for other X10 computer interfaces.

If you'd prefer to grab copies of the completed applications, preconfigured Project Builder projects, or any of several MUSCLE add-ons that have been completed to date, feel free to visit http://www.shotton.com/muscle/ and check out the latest info. And as with all good open source projects, if you create something cool with what you've learned here, please consider sharing it!

Chuck Shotton is the creator of MacHTTP and WebSTAR, the first commercial desktop Web servers. He's always had an itch for remote controlled gadgets and computers that communicate, and he spends his time in Leesburg, VA helping companies scratch that itch. You can contact Chuck at chuck@machttp.org or <http://www.shotton.com/>.