Neil's Linux Home Automation Page

Note this was one of my original home page layouts from around 1996. I decided to keep it so I can see what I was thinking then verses now.

I think I have this page working much better under Lynx. I will continue to work on it to be sure. I appear to have no trouble with IE or Netscape.

The next release of this page will have a different look. It is, again, gettting too large to be comfortably read in one sitting. It really reads more like a small book.

About my HA interest

I live in Central NJ (East coast of the USA) and as you can tell I'm interested in home automation. I started using Linux at version 0.9. I ran it on my 386SX 16MHz ISA board and it ran well. I'm currently running 2.3.x (the beta test series). I am no longer content to put up with Microsoft's mediocre software (they can do better). I'm now also making an effort to keep my programs portable so I'm now going to also have a BSD system to test the code (now if I could only get the system built).

Home control system - Currently I don't have much in the way of devices I control. I'm working with X10 devices but I'm not using them for most of my important systems because they're not the most dependable. There are ways to improve dependability such as filters and such. One lesson that anyone who deals with X10 learns is that most (US) homes have 2 phases entering them (this gives us the 240V AC). If you have your controller on one phase and your device on another you're not going to communicate across the 2 phases unless you have some way to get the signal repeated on the other phase. Currently I'm playing games using my electric baseboard heating to do this. This is fine during the winter when at least one heater is on but I will eventually have to put in the signal bridge (which I have).

On a standard home PC you have the following interfaces which are easily accessed with hardware and software: serial ports, parallel ports, network interfaces (ie. ethernet), ISA, SCSI, IDE, USB, PCI and the keyboard interface. The first and foremost is the serial port. It is flexible with speeds as low as 50 baud and as high as 460K. You can use the input and ouput pins to bit twiddle (such as with the Dallas onewire interface). The next most popular interface is the parallel port. Often it is use to control simple things such as relays but it can also handle things as complicated as a camera or scanner. Building an ISA board is simple. Add a ready made board then use the I/O ports, DMA or shared ram, just add your circuits. A ready made board can be purchased and a prototype can be built. The use of distributed applications across a network is now extremely common. The SCSI, IDE, USB, and PCI are useable but are more difficult to use. Update: Seems that USB has made some real progress since I originally wrote this page in ~1996. USB may be real useful in at least the respect that you can put a couple of serial ports on an USB hub. Having devices that hooks directly to the USB would also be nice. And with todays new TCP/IP chip sets you can easily add small microcontrollers to an ethernet. God, I love technology.

I intend to build custom micro-controllers to do things such as get the outside temperature (I've since switched to using the a weather station), record the time of sun up and sundown (This may get hooked up to my HCS II or as a node on it's RS485 network), wind speed, rain detection, things of that nature (I just received a weather station for Christmas so have of that's taken care of :-). Currently I haven't any of these device built so there is no further information yet (but I hope that will change). I've include a couple of my book marks to hardware/home automation pages using the Microchip PIC processors (at the bottom of this page). Later I hope to add information on a MC68HC11 setup to home automation. You really should be able to use any processor you like. I have processor boards for the 6809, 6502, 6802, 68HC11, 68000, 8052AH w/BASIC, Z80 and the PIC chips from Microchip.

My current X10 system has changed. I had been running the daemon on a 486/33 MHz machine but that stopped working when the interrupt controller burnt out. I now have it on a 486/100MHz machine with SCSI, 10 serial ports and Linux kernel 2.2.5. This took a great deal of time to pull together a working system (software and hardware problems). I've resurrected my 386SX/16 system, now that I might be able to access the CMOS via /dev/nvram (it blew the keyboard controller). It will be used as a HA interface to one of my controllers and as a print server. Since the switch to the 486/100 the Dallas onewire network has stopped working. I'm not sure if this is due to the newer kernel, the new hardware setup, or problems with the serial port hardware.

The software I'm using as the daemon is Dan Lanciani's X10d (the version with the extended support). I'm also using Karl Denningers HomeDaemon to handle the events processing. I've modified both progams because of various problems (I can't tell if it's Linux or not) I also have Dan Suther's Heyu code and Xtend which I'm playing with to see what I want to be added to my programs/code. The X10d/HomeDaemon combination has the same functionality. I'll also be using the X10d & Homedaemon code as a shell for my interface to the HCS II. I've already gotten the hcsd code (alpha version) working. I'll work on the HomeDaemon interface later.

I have Dan Lanciani's code compiling and I am now starting to testing it. Here is what I will not be able to test: the Lynx-10 version (it compiles OK) and the 2 way Extended communications. I have been a bit lazy and not started up the LynX10 yet and I don't have any X10 devices which support Extended commands. I'm still using James Derrick's shell script but I've modified it enough were I might get away with calling it my own. I'm in the process of creating groups so you can call a device by it's group name and all the devices in the group get turned on or off (or whatever).

The devices I currently have in my possession are, a number of lamp modules, a number of appliance modules, 2 Ouelett OTE-x10 thermostats (BTW, Oulette has stopped making the OTE-X10), 3 key chain receivers, 1 transceiver module (RR501, this thing support Status request?), 2 TW523's, 3 CM11A (one partially disassembled for schematic purposes), a CP290, a wall switch module, a Lynx-10 kit (assembled but untested), an X10 firecracker, an ADI Ocelot, a JetEye RS232 to IR interface, and a HCS II with a PL-LINK (it uses the TW523). Unfortunately the switch module is half dead and needs to be fixed. The push button no longer works. I had thought that the unit might have gone dead because at times it would not respond to commands. Later I discovered that a set of compact fluorescent lights was jamming the signal (switching frequency of 55-65kHz, a close harmonic of the 120kHz X10 signal) and that it was on another phase (I have to put in the "signal bridge"). I will need to add some kind of filters there when the budget allows.

Last year (97) I impressed my wife with the computers ability to properly control various things. This year (98) things were going well until the switch module failed (after less than 3 months of use) and the PC I used died. This showed me some of the short comings of Home Automation very quickly. This, added to a program on TV about one of Bob Veilla's (sp?) "Home of the Future" total failures, has made my wife and myself a bit more cautious about over automating the home. I'll need to put a lot of work into get this stuff to be more fault tolerant. For now Christmas lights, house heating, outside lighting, and maybe the pool filter. Maybe next year, the world.... Come Pinky! (A reference to Pinky & the Brain, a cartoon done by Spielberg and Warner Brothers(sp?)).

Despite this my wife has again asked me to add some X10 controlled outlets for night light use. I turn the outlets on around sunset and we can use them for lighting up various areas so the house is not so dark. So far the porch light, the hutch light and the computer room light have worked well doing just that. Now she would like a few more areas added. This year (99) my wife has asked me to add further lights to the system. This time it some outdoor lights, a few X10 wall outlets (so as to to have a bulky appliance or lamp module exposed) and a few wall switch (not an X10 controller just a transmitter) to controll lights at the opposite end of the house.

I am currently taking Dan's code and moving it over to POSIX compatible code. This should allow it to be compiled under any POSIX compatible Unix, I will add a few features. It will be an X10 package which should include the X10 daemon, shell scripts using netpipes to be used in conjunction with cron and the unix shell, and a Java Applet to allow Netscape or IE (or other browsers that support Java/Javascript) to have access to the X10d. I have the ideas down now but I'm currently in search of a few of the drawing tools for the JPEGs. And I'm working on the Java security problems (security can be a pain under Java and is not portable). I've stopped adding features to Dan's program because I've started writting my own program to control the HCS II. I initially started with Dan's TCP/IP code but found some of my additional code was causing problems so I'm now removing his code and replacing it with my own. Many of the features I've added to my program will later be ported back to Dan's program. These are features a few user have asked for.

Here is a list of the various ideas I'm working with:

                        | GUI | Shell | cron |
                        +--------------------+  ^
                        |  CMDS  <=> scripts |  |
                        +--------------------+  |
                        | Network |  system  |  |
                        +--------------------+  |
                        |      Daemons       |  |
                        +--------------------+  |
                        |       Device       |  V

Hey that looks just like the ISO model, hmmm what a coincidence :-) It also happens to be the Unix design philosophy. Create a tool, keep it simple so that it does one thing really well. BTW the drawing is incorrect, the Daemons are built on top of the Network/Systems layer. I will correct that at a future date.

What I had originally envisioned was to build simple daemons which would perform the I/O to the devices. They would convert simple ASCII commands to the proper format and timing to interface with the device. You could then connect to the daemon via a network socket (telnet me x10d for example) and type in commands to get it to do things. Then the next step would be to build commands that would interface to the daemon so you could type simple easy to remember commands from the command line (something a little closer to english such as on TV as opposed to A1AON). This of course would permit the commands also to interact with other commands (through the use of pipes or filters such as expect). Which would then permit the creation of GUI's to permit the Object Oriented view of things (you click on a TV to turn it on or off). We're not too far from that now. My problem is that I want to use the browser to be that interface. This would allow any user Windows, Mac, or Unix to bring up a display and make changes dynamically. I probably should tackle the problem using TCL code. And what a coincidence, I just received some TCL from someone that would permit the use of the CM11A with Heyu. It's Adam Hightower's software converted to use heyu. Now I'm pretty sure I can do something like this this too but to use the x10d software instead. I've also started working on using Perl/Tk because I can write the code once and run it under Windows and under Unix (it may also be possible to run it on a MAC but I'm not setup for this).

	       System A                              System B
	                                      | GUI | Shell | cron |   
	                                      +--------------------+  ^
	                                      |  CMDS  <=> scripts |  |
	+--------------------+                +--------------------+  |
	| Network |  system  | <------------> | network |  system  |  |
	+--------------------+                +--------------------+  |
	|      Daemons       |                |      Daemons       |  |
	+--------------------+                +--------------------+  |
	|       Device       |                |       Device       |  V
	+--------------------+                +--------------------+   

BTW the drawing is incorrect, the Daemons are built on top of the Network/Systems layer. I will correct that at a future date.

The reason behind using more than one computer came into play when I purchased my first computer with PCI slots. I was all set to move my boards over to the new computer when I discovered a shortage of slots. I had purchased a PCI video board and a motherboard which had built in serial ports, a ps/2 mouse, a USB interface, a parallel port, and 2 IDE controllers. When I attempted to add another serial board, a SCSI board and a network card I quickly discovered that I didn't have enough ISA slots to put everthing into one machine. So I distributed my I/O over several machines. I also quickly discovered that older and slower computers could be used. With no monitor or keyboard I ended up with a terminal/print server that I could telnet to and from. The speed of my slowest 386sx was 16 Mhz but it could easily handle the print services and the serial devices which ran at no more than 9600.

X10D - daemon to interface to CM11A, LynX10, HCS II, CP290, CPU-XA, Oceltot, or C17A (Firecracker). I've been rethinking the software and I've decided that the daemon should be kept simple. It will take ASCII commands and convert them to the appropriate commands for the device being interfaced to. The daemon will also write the raw input to a file so that external programs can read the raw commands and act on them. One of those external programs will be a state machine (like Karl Denniger's HomeDaemon) which keeps track of the current state of the X10 devices. The user interface is a plain socket which accepts a series of simple commands to turn devices on, off, dim, bright, request, status and extended. The external user friendly interface program will make it easier for a user to use X10d so that it doesn't really need to be that user friendly (K.I.S.S.).

CLI software for use in cron jobs, this code is working and uses netpipes. This is useful for cron jobs or just quickly turning on various things around the house at odd times (yeah, I spend too much time at the keyboard).

GUI software, a Java Applet. The image presented will be a house floor plan. On the floor plan will be images or the devices to be controlled. When the mouse rides over one of these hot spots an update is displayed. A click will either turn on/off or bring up a menu depending on the type of module (Appliance, lamp, thermostat, etc). Current problems: what package to use to create the images, how to create the hot spots, how to handle the module types and how to handle the security for each browser (Security is NOT portable!). This would enable someone like my wife who wants to know nothing about using the interface to use the software. She wants it so simple to use that it is obvious and goof proof. BTW my wife is not computer illiterate but doesn't want to learn a bunch of new commands to turn on a light when having the light switch is idiot proof.

I've done some proof of concept work written in Java (I'm know very little Java). So far I've been able to create a box on top of a gif and when the mouse enters the box a larger box (of a different color) appears. I can click inside the box and an X10 command is sent to the tcp daemon. Click on it again and it sends the opposite command (on or off). So far I don't have enough Java knowledge to take advantage of the code. So I'll continue reading and learning until I do. The demo on the EmWare home page is how things should work. (I have a very fast Internet Link so it works great on my Linux box). The images and the way the software can jump back and forth, it's pretty smooth. Of course it's a demo so it really doesn't do anything. But it does a lot more than my proof of concept software. Also it has provided me with the idea of having one program interface to all the daemons and machines running the automation software. The software doesn't need to reside on one machine. It can run on nay machine and the user interface can be on another. As long as each has a network connection information can be shared across the network and is accessible to anyone. Of course this leads to concerns of security...

Status & Event software. Keeps track of module status, issues commands on certain events, such as A1 ON may cause Tea pot to be turned on, kitchen lights to be brought up to 50 % dimmed, the radio is turned on to station KWXY... This set of tools would monitor various I/O (not just X10) like an IR interface so you would be able to use a TV remote to send commands to the computer for mood lighting. The Xtend software is a useful example of what can be done but with Heyu or by it self. Also Scotto Ostrander has written a daemon that allows you to execute commands when an X10 event occurs. It's written in Perl and works with Dan's X10d code. Now Karl Denninger has added his software to the collection (Karl's software works with X10d).

X10 Macro Compiler. The CM11A has provisions to handle macros (If C1 on send A1, A2, A3 ON for example) without the PC's intervention. What is need is to compile the macros into their byte codes and download it to the CM11A. Thanks to Rich Auletta we now have x10asm! Currently it doesn't do error checking but working code is enough to look at and study to get a better understanding.

Between other things I came across a program written to access the OneWire network devices created by Dallas Semiconductor. I currently have 4 thermometers (DS1821) and 2 DS2047's connected to the one wire network. I hope to create a proper daemon for the network to monitor and control the devices on that network. Here is the OneWire software I found on the net (onewire.tgz). Its for Linux and I finally found out who wrote it: Andrew A. Burgess. All I had to do was look in the code (DOH!).

Another addition to my collection is the hcs2d code. The HCS II is a set of boards originally made by Circuit Cellar (Steve Ciarcia's Computer Applications Journal) and now being handled by Mike Baptiste of CC-Concepts. The HCS2 has provisions to connect to digit I/O, Analog I/O, X10, a telephone interface, and voice output (on the telephone I think) all connected via RS485. The manuals are explicit enough that you can build other boards and access them though a special control language (Express) and you can issue commands over the RS232 interface. I am currently working on Linux HCS software called hcsd (see the Linux HCS Page for details).

I intend to add an X10 inline module to control my front porch lights. (I wrote this in 1996 an I still haven't done this. but I did automate the garage light) I have a program which determines sun rise/set times and I'll use it as a reference to turn on and off the lights at the appropriate times. I've also seen the X10 Timed Photocell and I may order that also to handle low light days. With the use of my X10 daemon software I'll be able to correctly handle the use and waste of the 4 X10 codes. I'm also spending a bit of time thinking about an IR interface so you can send commands out a serial port and control VCR's, TVs, stereos etal. I have some components and I should be able to build the hardware. I currently have the old LIR code (still looking for the SIR package) and I'll see what I can come up with.

Software information

A few years ago, my friend purchased a CM11 kit as a Christmas present. I played around with it for a while, I like the way it operated and decided to get it running under Linux. The first software I used was found on the Beowulf page and it had a lot of interesting ideas but I was never able to really get it working right. I later found Dan Suthers Heyu and it worked well but I wasn't able to determine what was on or off. Then I found Dan Lanciani's software which appealed to me most because it was a network daemon. This allowed me to put the software and CM11 on another machine (one with enough I/O space) and have the client software on any machine.

I like the way Dan Lanciani's software presents a TCP interface to the X10 software so I attempted to compile it. But it failed, so I poked around in the software and found a few things that needed to be changed to make it work under Linux. Although I probably just needed to add a few more ioctl calls to get it working I decided to steal the serial initialization from Dan Suthers' HEYU software (I understand Heyu's code better). It was just easier to take that which already worked than to search through all sorts of documentation for the ioctl calls. Dan Lanciani has put a lot of effort into his code to make it more compatible with other Unix's but I still had some trouble getting it to compile (hence my mods).

1999 - I've taken Dan's code one step further and written my software around Dan's TCP/IP code. The end product is a daemon which is a bit more POSIX oriented (still a few ioctl calls). It interfaces to the HCS II and is currently in an Alpha state (11/8/1999). I hope to have a beta release by 11/15/1999.

I've also just purchased a CPU-XA and I'm hoping to have a similar daemon interface for it. I may be able to start that project by 1/1/1900 ;-).

X10 Fireball

The name comes from a 60's British TV program called XL Fireball and the fact that my wife is always worried that my X10 projects will always end up in a fireball. This package will be the entire daemon, CLI software, all the support software, a status and events processor and the Java GUI software. It should work with the CM11A, Lynx-10 module, Lynx-10 PLD module, the CPU-XA and HCS II with the PL-LINK (or the PLIX module). The CP290 only allows one way communication and will not be supported.


I've taken Dan Lanciani's software and modified it to work under Linux. The tar file includes the source with the diffs already included, a README.html, a Makefile, a BASH shell script (see below) and a sample .x10alias file. This source file will not give you any warnings under normal compiling (don't use the -Wall gcc option). There are a few other features I want to add which relate to Status & Events (see below).


This is software written by Tim Witham. It fit right in with my daemon ideas so I don't have to write anything. He also provides client software which displays all the weather information from the WM918. I will be adding software which will keep track of some of the information for the day/month/year. I will also add a package that will (via a cron job) push the info out to a site so my friends can see the weather predications for the next 24 hours. I may add a java applet which constantly pulls the info off the home page (which the other program pushed up there).


The command line interface shell script was a script originally written by James Derrick but again I modified it (are you getting the impression I really don't write my own software? ;-}). I am, unfortunately, very forgetful so I modified it to allow the use of an alias file. I also change its name so I can remember the easier off, on, dim, bright, setback, and setforward. The last 2 deal with an X10 thermostat made by Ouellet. I hope to add further support for "All x on/off" commands.


I've switched this to the "most difficult" category. This is the code I am working part time on. I have just begun to learn Java and although it's not too difficult to learn there are a lot of topics I need to cover in order to do this right. So far I have been able to read in a gif file and write to the browser. I also think I have the threads part understood but we'll have to wait and see. I also have various chunks of code I've found to perform many of the more complicated tasks. It has also been suggested to me that I give PHP a try. This is a section that is in flux and needs work so I am open to suggestions. Please don't be offended if I don't go the CGI route. Many people have created simple interfaces using CGI. In my opinion this is not the best way to control a home. Something a bit more interactive is appropriate.

Status & Events Software

This is the was complicated piece of the software package (or at least I thought so). It needs to keep track of what has been sent and the requests it receives. This one is going to take quite a bit of fore thought before I release this software. In other words don't hold you're breath. David Shaw has software that works with heyu that does part of what I want. I'll need to modify the code to get it to work with X10d.

Initially I thought that this would be the most difficult software to write. I've been proven wrong (twice). Actually Scotto Ostrander has proven me wrong with a simple perl script that performs a part of the events software. We've managed to get it working as a daemon and it has been posted. We should really consider changing it from alpha to Version 1.0. It does work and it seems to be stable.

Karl Denninger has also proven me wrong with code written in C. Karl's reason for C is a simple one, speed. Karl has notice that Perl can really hog up a CPU.

X10 Macro compiler Software

Rich Auletta has creat an X10 macro compiler written in TCL. Although I still don't completely understand it it does look like it can download macros to the CM11A's EEPROM.

Other X10 Devices

There are other devices and I'm going to attempt to build code to support them. Currently I have a CP290, a TW523, the CM11A and the HCS II with PL-LINK. I now have the Lynx-10 board but I don't have it on line. A fire in one of my drives has required that I take down my systems, clean them, tidey up the cabling and reassemble them. I'm currently in the process of building permanent adapters instead of the jury-rigs I usually have. If you want support for other devices then I'll need to get my hands on the device and programming information. Dan Lanciani has code to support the Lynx-10 and the Red October. I can only guess my code can be used to make it work.


There really isn't any good reason as to why I do this other than because I want to. I do it for curiosity and to keep up various skills and knowledge but it all comes down to "because I want to".

How can I get device X to work with this project?

There are 2 ways to get a device, not listed here but you're interested in, added to this project. The first way is to get my hands on the device but remember I am dealing with a limited budget. Because I do this as a hobby and not a business I don't have a very large research budget. The second is for you to get involved and start writing the daemon code to interface to your device. I personally think that this would be easier with my hcsd code as a shell as opposed to Dan's x10d code. That's because I further broken down Dan's code. This should make it easier to pull out everything but the TCP/IP code. Then you can begin writing the interface software to the device.

Other Links

See the main page, either afore mentioned software, other hardware, other software or other links. If you have other links to X10 software of Unix please email me and I'll try to include the links here if they appear to be interesting. You may email me at .

Last updated: Tue Jan 2 11:40:59 EST 2007