X10 Smart Home Automation with
a Firecracker and Debian Linux
The material on this page was prepared using Sarge or Etch
configured using our Installation and Packages pages.
If you did not use our pages to set up your system, what you
encounter on your system may be different than what is given here.
X10 is a protocol (set of commands) for controlling lights, appliances, and other electrical devices in your house to make it a "smart home". The commands (electrical signals) travel over the existing electrical lines in your house so no cabling is required.
You can use your computer to send these control commands (ON, OFF, BRIGHTEN, DIM, etc.) to devices in your home called "X10 modules". You can harness the power of your computer to write scripts which send a series of commands to manipulate multiple devices at the same time. When used in conjunction with the cron scheduler to execute these scripts at specific times, you can automate the lighting and operation of appliances in your home. You could even write scripts with loops so that the same sequence of events are executed over and over again (such as with a Christmas or Halloween light display).Note: Be careful when evaluating HA (home automation) systems. Many do not use X10. Rather, the use a proprietary protocol that is specific to the company that made the system and you are tied to their products only.
X10 is a standard. Using X10 components helps ensure that one company's modules can be controlled by a different company's controller. Some vendors sell both X10 and proprietary hardware so be careful what you buy.
On this page we will use a fairly simple X10 interface commonly known as the "Firecracker" which we cover in more detail in the Hardware section below.
There are a couple similarities between X10 and an ethernet network. Like NICs, each X10 module has a unique address. (Unlike NICs you can set the address of X10 modules.) Like ethernet, X10 sends signals onto a common wire (house AC wiring) and all modules see all commands but only respond to the ones meant for it.
An X10 module address has two parts, the House code (which uses letters A through P) and the Unit code (which uses numbers 1 through 16). This allows you to have 16 modules for each house code for a total
(16 x 16)of 256 modules. The House and Unit codes are typically selected with a small dial that can be turned using a small screwdriver.
The House code can either be thought of as an "area" code, where all devices in one area of the house have the same House code, or it can be used for module grouping, so, for example, all appliance modules in the entire house would have the same House code.
Remember that multiple modules can have the same House code, and multiple modules can have the same Unit code, but no two modules should have the same House and Unit codes. The combination of the two codes make up the address and each module needs a unique address. Typical X10 module addresses are A2, B15, C4, etc. I would recommend not using consecutive addresses. Space them apart such as A2, A4, A6, etc.
X10 modules perform two functions. They provide a way of addressing different devices. i.e. they have the dials on them to set an address for a lamp or whatever. They are also a command decoder. They capture commands off of the electrical wiring, decode them, and then act accordingly. Some modules also perform a third function, that of a dimmer. Even if the lamp or ceiling light you're controlling wasn't dimmable before, controlling it with an X10 module may allow you to adjust the brightness as well as the on/off state.
Lamp and appliance modules plug into an AC outlet and then the lamp or appliance being controlled is plugged into the module. The module acts as an in-line switch passing or blocking AC power to the controlled device. Some modules are "two-way" modules which send informtion back to a controller as well as receive commands from it. Note that you must have a controller that supports this and this "feedback" is likely done using a proprietary protocol.
There are a lot of different X10 modules available. The most common is the lamp module which allows you to turn a lamp on and off. In addition, most lamp modules can also function as dimmers.
Appliance modules are meant to control small (low current) appliances like coffee makers and toasters. Appliance modules are similar to lamp modules but have beefier components to handle higher currents. They come in "2-pin" (no ground prong) and "3-pin" (with a ground prong) models. Lamps can be plugged into appliance modules but appliances can't be plugged into lamp modules.
There are also heavy-duty 15- and 20-amp appliance modules for things like small refridgerators, etc. They are made to withstand the higher current levels seen when larger appliances start up.
Screw-in lamp modules offer another means of controlling lights including ceiling lights (provided the module and bulb combined will still fit under a plastic or glass fixture cover).
A cleaner alternative to lamp and appliance modules is the receptacle module. Note that on some models only one of the outlets is controlled and the other is live all the time.
A cleaner alternaive to the screw-in lamp module is the switch module for controlling ceiling lights. There are also three-way switch modules available. These switch modules allow you to manually override the X10 controller. For example, if you set up an X10 timer to keep a ceiling light on for 30 minutes, and you want to shut it off after 10, you can use this type of switch to do so.
A unique type of module is the universal module. It's like a relay. It has two normally-open (NO) or normally-closed (NC) screw contacts up to which you can connect low-voltage systems such as garage door openers, sprinkler systems, or drapery controls. When an X10 'on' command is sent to this module, the NO contacts would close (or the NC contacts would open). This type of module has a LOT of possibilities for the experimenter.
For example, most garage door systems have a push button that you mount to the wall of the garage. Pushing this button open and closes the garage door. If you were to connect the two wires that would go to this push button to normally-open contacts on a universal module instead, you could control your garage door using X10 commands.
Something has to send X10 commands to X10 modules. Controllers do this and typically fall into two categories, computer-based and stand-alone.
Computer-based controllers run X10 software and that sends commands to X10 modules through some sort of transceiver that that interfaces the computer to the power line on which commands are transmitted. In these instanace the computer is the brains of the controller and it must remain on so devices can be controlled.
Stand-alone units plug into a wall outlet so it can send commands to X10 modules. They will typically have a computer connection like a serial or USB port. That's so you can use a software application to program the stand-alone unit. But once it's programmed you can disconnect it from the computer and turn the computer off. The stand-alone unit has its own memory for storing commands and timers. They also typically have batteries so they don't lose their programming in the case of a power failure or if they get unplugged from the wall for a short period of time (to be moved).
Some stand-alone controllers may also incorporate a wireless receiver and antenna. This is so you can use wireless "palm pad" remotes and keychain remotes to turn devices on and off without using a computer. The palm pad remotes allow you to control all devices from the comfort of your favorite chair or from your bedroom. A keychain remote allows you to remotely turn on lights and operate other devices (such as a garage door) from outside or while in your car.
We will use the first type of controller on this page. The Debian system will act as the controller and we will use a software application to send commands to X10 modules. This also gives us the option of using the memory-resident scheduler cron to set up pseudo-timers to control X10 modules.
We need some sort of transceiver to interface our Debian system to the power lines. A very popular device for doing this is called the Firecracker. It is actually a two-piece transceiver. One small piece connects to the serial port of our Debian system and acts as a transmitter. The other piece is the receiver and it has an antenna and plugs into a wall outlet.
When we use a special software package to enter an X10 command at a shell prompt on our Linux system the command is sent to transmitter connected to the serial port and is transmitted over the airwaves. The receiver uses its antenna to pick the command out of the air and place it on the electrical lines where it is picked up and processed by the addressed module.
A 4-piece Firecracker kit is available from the people that make the Firecracker, X10 Technology Inc., for around $40. It includes the two Firecracker transceiver pieces mentioned above, a Palm Pad remote, and a lamp module. Note that the Firecracker receiver module has an outlet on it so it can simultaneously be used as a lamp or appliance module which means you end up getting two modules. The Firecracker transceiver module is hardcoded to a Unit code of 1 but the House code is settable.
In this section we're assuming you've gotten the Firecracker kit (because you can't do anything without it). Set the House code dial on the receiver to C, plug a lamp into the receiver's outlet, and then plug the receiver into a wall socket. You may want to press the On/Off button on the receiver to make sure the device you plugged into it goes on and off. Then just connect the transmitter to a serial port on your Debian system.
Now that you've got the hardware all hooked up and plugged in lets try it out. There is a Debian package called Bottlerocket that will let you use a Firecracker to send X10 commands to modules from a Linux shell prompt. Install the package wth the command:
apt-get install bottlerocket
You'll be asked to specify which serial port the Firecracker transmitter is connected to. Be sure to use ttyS0 for COM1 or ttyS1 for COM2. That's all there is to setting up Bottlerocket.
Try testing your X10 installation with the following Bottlerocket command at the shell prompt (assuming you set the receiver House code dial to C):
br c1 on
and the device should come on. The br part of the command is the Bottlerocket executable. The c1 part of the command is the address of the Firecracker receiver (and whatever device you have plugged into it). The final part of the command turns the connected device on.
Now lets try a shell script. You create a shell script using the nano text editor with the command:
and enter the following statements into it:
br c1 on
br c1 off
(The sleep value is specified in seconds.) Press Ctrl-X and 'y' at the prompt to save the changes, and then Enter to exit saving the file. Then change the permissions to make it executable using the command:
chmod 755 /usr/local/c1for30.sh
Then run the shell script:
The device plugged into the receiver should come on for 30 seconds and then go off automatically. The & at the end of the command just puts the script in the background for the 30 seconds that it's running so you get your shell prompt back right away. This is a very basic script but it illustrates the point. You could add 'if' statements for conditional checks such as time of day, day of week, etc. If you wanted a living room light to stay on for 4 hours while you are gone out of town you'd just change the sleep value to 14400 (there are 3600 seconds in each hour).
You could create a shell script for each device, turning it on for a specific amount of time and then turning it off. Once you get your scripts created you would use cron to run them at the times you specify. We cover how to use cron near the end of the Packages page. The following are some example cron entries.
The living room table lamp should be turned on weekdays at
5 pm(set in cron) and go off at 10 pm(set using the sleep value in the script).
0 17 * * 1,2,3,4,5 /usr/local/c3for18000.sh
The front porch light should go on every day at
6:30 pmand go off at 9 pm.
30 18 * * * /usr/local/c8for9000.sh
Using Bottlerocket with a Firecracker system is a good way to get your feet wet with X10 and to automate certain functions. Using shell scripts would be a good way to automate and coordinate holiday lights or other special effect lighting.
With X10 hardware being standardized, the controlling software becomes an important factor. There are more sophisticated software packages available, such as
ActiveHome Profor the Windows platform from X10 Technology, Inc. Their ActiveHome Propackage includes a stand-alone controller and the software to program it. They also have several starter kits available that include modules and remotes. The more sophisticated software can handle "triggers" from motion sensors, etc. Triggers, in turn, allow you to create macros which act on several devices when a trigger is detected. This allows you to expand your system from home automation to home security as well.
Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.
Site, content, documents, original images Copyright © 2003-2013 Keith Parkansky All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.
This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.
IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.