X10 Interface for .NET

A few months ago I received some old X10 devices from a friend; this started my curiosity in home automation. Being able to turn lights on and off from a remote was great loads of geeky fun. After a little while I grew tired of the remote and wanted to write software to interface with the X10 devices directly. I looked around and found several intriguing open-source projects such as Mister House. Mister House looks great but it is written in Perl and I had a difficult time getting it to run on my Linux machines. I could dust off my old Perl skills to figure out what was wrong, or I could look a little further in to the .NET offerings (I’m a .NET developer and enjoy working with .NET for many of my hobbies). I found a few X10 interfaces for .NET, but they were all unreliable and buggy. Eventually, I started looking in to creating my own X10 interface for .NET. That journey ended with me writing my own interface from scratch and creating a new open source project, X10d.

X10d (pronounced Extend) currently only works with the CM11A X10 device. This device plugs in to a standard outlet and then communicates with a PC via a COM port. There are other devices such as the Firecracker, but I chose not to support it in the initial beta release. Once plugged in to the electrical system of the house the device is effectively a new node on the X10 network, able to send and receive messages. I found a whitepaper that described the X10 and CM11A protocol in great detail. This document was invaluable in creating the .NET classes.

During implementation, I used the state design pattern to model the X10 protocol. This implementation seemed to work out rather well, providing a lot of flexibility and making the code much more manageable than a monolithic design. An diagram of the Finite State Automaton (FSA) is shown below:

X10d FSA

As you can see, the X10 interface transitions through several states while sending the command to a device, such as a lamp module. Moreover, the interface may send interrupts to the PC regardless if a command is active. These interrupts must be serviced before the X10 interface will continue processing commands. Once the interrupt is serviced then the PC must restart the command sequence. Much of the existing open source NET projects did not handle interrupts correctly, leaving the software in an unusable state.

I hope X10 hobbyists, and maybe even some professionals, find this code useful. If you have any comments or suggestions, please send them my way!