Free x10 software for linux

rt_x10 is a realtime kernel driver for the X10 "two way power line interface" (model TM523).

X10 is a protocol for sending signals over power lines. There are lots of relatively cheap components available at x10.com (and other places) that make home automation
feasible for the average consumer.

If you want seamless automation without any glitches, X10 is not for you. If you want a pretty good system that mostly works, and is cheap, then you should give this a try.

X10 as a protocol is pretty awful, but it is at least very well documented (see X10.technicalnote.pdf). X10 signals are fragile, and are frequently garbled.

There is some amount of redundancy in the signal, so it is usually possible to detect a corrupt code, but the occasional glitch still happens, especially when packets collide.

The X10 devices do not respond to query, as provoded for by the X10 spec, so one can only send repeated commands in hopes that the device will eventually be put in the desired state.

You need to start with a "two way power line interface" module (Model TW523), and build a connection circuit as described on page 11 of the X10.technicalnote.pdf.

Attach this to a serial port, tying the 60 Hz "zero-crossing" signal to CTS, the X10 "receive" signal to DSR, and the X10 "transmit" to DTR.

Because of the inconvenient relationship between the two signals provided by the TW523, it is more practical to use real-time polling in software to sample the pulse windows rather than to extend the required interface circuitry by adding logic gates and counters and clocks.

For this, I wrote rt_x10.c. rt_x10.o is a kernel module that works with Linux RTAI. It could be easily modified to work with RTLinux or other similar infrastructures, but RTAI is the best, so give it a try first.

Once the realtime kernel module is installed, it writes X10 codes to /dev/rtf0 whenever they appear on the power line, and when X10 commands are written to /dev/rtf1, the module sends these codes over the power line.

There are two simple userspace example programs that demonstrate reading and writing X10 codes : recvx10 and sendx10.

These should serve as a basis for a userspace program that implements all the timing and logic for specific configurations of sensors, lights, and appliances.

x10mp3 is a plug-in for xmms and WinAmp. x10mp3 will allow you to control XMMS/WinAmp using an X10 remote. It is intended to be used as a replacement for the Boom 2000 Software. See below for requirements and compatibility with the various X10 remotes.

The main platform for x10mp3 is Linux. Some of the information on this site is only relevant to Linux versions.

The Boom2000 software is a seperate application, developed by X10, that sends messages to assorted programs like WinAmp and RealPlayer. There are two things wrong with that: 1. you must start a seperate application everytime you launch your Mp3 player, and 2. you must use Windows (blech!)

Since x10mp3 is a plug-in, it is started automatically everytime you run XMMS/WinAmp. x10mp3 has additional features that Boom2000 does not, like balance control, fast-forward/rewind, pause, etc. Also, Boom2000 doesnt run on Linux - x10mp3 does.

ControlX10::CM11 is a Perl extension for X10 ActiveHome Controller.

SYNOPSIS

use ControlX10::CM11;

# $serial_port is an object created using Win32::SerialPort
# or Device::SerialPort depending on OS
# my $serial_port = setup_serial_port(COM10, 4800);

$data = &ControlX10::CM11::receive_buffer($serial_port);
$data = &ControlX10::CM11::read($serial_port, $no_block);
$percent = &ControlX10::CM11::dim_level_decode(GE); # 40%

&ControlX10::CM11::send($serial_port, A1); # Address device A1
&ControlX10::CM11::send($serial_port, AJ); # Turn device ON
# House Code A present in both send() calls

&ControlX10::CM11::send($serial_port, B.ALL_OFF);
# Turns All lights on house code B off

Linux X10 universal device driver (also known as Project WiSH) provides a /dev interface to an X10 network through a combination of Linux kernel modules and daemons.
It is intended to provide a standard interface and syntax to shell script utilities (such as cat and echo), Perl scripts, C programs, or Java programs so that everything from a quick hack to a more advanced program can manipulate the X10 devices in an automated home regardless of the transceiver used.
Its simplest use is with shell scripts (examples of which are provided in the package). Currently the project supports the 3 X10 transceivers (PowerLinc Serial, PowerLinc USB, and CM11A).
Main features:
- Full /dev/x10 capability with enhancements for non-blocking writes
- Full support for PowerLinc Serial transceiver
- Full support for CM11A Serial transceiver
- Full support for PowerLinc USB transceiver (with kernel patches for USB)
Enhancements:
- X10 state machine simulator runs in userspace
- Kernel module maintains status of individual devices and implements API only
- non-blocking writes (by popular demand) so commands can be queued up in rapid succession
- PowerLinc USB now uses HID interface
- Version 2.0 drivers work with kernel 2.6.7 and higher and with kernel version 2.4.0 (the PowerLinc USB will not work with kernel 2.4 due to lack of support for multibyte messages in the USB subsystem of the kernel. If you require the PowerLinc USB and kernel 2.4, use wish-1.6.10. )
- Simpler compilation and installation method

printerpowerd project is a Daemon to automatically turn a printer on and off.

printerpowerd is a little Python script designed for users of older printers who want to save power when not using their printer, without manually turning it on and off.

It runs, checking the printer queue directory every five seconds, turns it on when it sees a job, and turns it off after a configurable amount of idle time.

It allows you to turn a printer on and off (when idle) using X10 or any other abitrary command.

Acme::OneHundredNotOut is a raise of the bat, a tip of the hat.

I have just released my 100th module to CPAN, the first time that anyone has reached that target. As some of you may know, I am getting ready to go back to college and reinvent myself from being a programmer into being a missionary. I dont forsee that many more Perl modules coming out of this.

Of course, this doesnt mean that Im going to abjure usage of Perl forever; any time theres a computer and something I need automated, out will come the Swiss Army Chainsaw and the job will get done. In fact, we recently needed to manipulate some text from a mission handbook to translate it into Japanese, and Perl was there handling and collating all that.

But 100 modules is a convenient place to stop and take stock, and I hope that those of you who have benefitted from my modules, programs or writing about Perl will forgive me a certain spot of self-indulgence as I look back over my CPAN career, especially since I feel that the diversity of modules that Ive produced is a good indication of the diversity of what can be done with Perl.

Lets begin, then, with some humble beginnings, and then catch up on recent history.
The Embarrassing Past

Contrary to popular belief, I was not always a CPAN author. I started writing modules in 1998, immediately after reading the first edition of the Perl Cookbook - yes, you can blame Nat and Tom for all this. The first module that I released was Tie::DiscoveryHash, since Id just learnt about tied hashes. As with many of my modules, it was an integral part of another software project which I actually never finished, and now cant find.

The first module that I ever wrote (but, by a curious quirk of fate, precisely the fiftieth module I released) was called String::Tokeniser, which is still a reasonably handy way of getting an iterator over tokenising a string. (Someone recently released String::Tokenizer, which makes me laugh.) This too was for an abortive project, webperl, an application of Don Knuths WEB system of structured documentation to Perl. However, given the code quality of these two modules, its perhaps just as well that the projects never saw the light of day.

There are a few other modules Id rather like to forget, too. Devel::Pointer was a sick joke that went badly wrong - it allowed people to use pointers in Perl. Some people failed to notice that referring to memory locations directly in an extremely high-level language was a dangerous and silly thing to do, and actually used the damned thing, and I started getting requests for support for it. Then at some point in 2001, when I should really have known better, I developed an interest in Microsofts .NET and the C# language, which I still think is pretty neat; but I decided it might be a good idea to translate the Mono projects tokenizer and parser into Perl, ending up with C::Sharp. I never got around to doing the parser part, or indeed anything else with it, and so it died a lonely death in a dark corner of CPAN. GTK::HandyClist was my foray into programming graphical applications, which started and ended there.

Bundle::SDK::SIMON was actually the slides from a talk on my top ten favourite CPAN modules - except that this changes so quickly over time, it doesnt really make much sense any more.

Finally, Array::FileReader was an attempt to optimize a file access process. Unfortunately, my "optimization" ended up introducing more overheads than the naive solution. It all goes to show. Since then, Mark-Jason Dominus, another huge influence in the development of my CPAN career, has written Tie::File, which not only has a better name but is actually efficient too.

The Internals Phase

1999-2000 were disastrous years for me personally but magnificent years Perl-sonally. Stuck in a boring job and a tiny flat in the middle of Tokyo, I had plenty of time to get stuck into more Perl development. I felt that getting involved with perl5-porters would be a good way of gettting to know more about Perl, and so I needed a hobby horse - an issue of Perls development that I cared about. Since I was in Japan and working a lot with non-Latin text, Unicode support seemed a good thing to work on, and so Unicode::Decompose appeared, while I fixed up a substantial part of the post-5.6 core Unicode support.

Id recommend this way to anyone who wants to get more involved in the Perl community, although I was very lucky in terms of who else happened to be around at the time: Gurusamy Sarathy was extremely gracious in helping me turn my fledgling C code into something fit for the Perl core, and he also helped me understand the perl5-porters etiquette (yes, there was some at the time) and what makes a good patch, while Jarkko Hietaniemi was always good for suggestions of interesting things for keen people to work on. Seriously, get involved. If I can do it, anyone can.
Anyway, this fixation with understanding the Perl 5 internals, and especially the Perl 5 compiler, (due to yet another of my Perl influences, the great Malcolm Beattie) led to quite a torrent of modules, from ByteCache, an implementation of just-in-time compilation for Perl modules, through B::Flags and B::Tree to help visualising the Perl op tree, to uninit, B::Generate, optimizer and B::Utils for modifying it.

Perl About The House

Now we abandon chronological order somewhat and take a look at the various areas in which Ive used Perl. One of these areas has been the automation of everyday life: checking my bank balance with Finance::Bank::LloydsTSB (the first Perl module to interface to personal internet banking, no less) and my phone bill with a release of Tony Bowdens Data::BT::PhoneBill.

Finance::Bank::LloydsTSB was meant to go with Finance::QIF, my Quicken file parser, to produce another now-abandoned idea, a Perl finances manager. It seemed that Im only capable of producing modules, not full standalone applications - or at least, it seemed that way until I produced Bryar, my blogging software, based on the concepts from Rael Dornfests blosxom and beginning my adventures with Andy Wardleys Template Toolkit. Bryar also tuned me in to the Model-View-Controller framework idea, of which more later.

Another project I briefly played with was a personal robot, using the Sphinx/Festival speech handling and recognition modules from Cepstral and Kevin Lenzo. I didnt have X10, so I couldnt shout "lights" into the air in a wonderfully scifi way, but I could shout "mail" and have a summary of my inbox read to me, "news" to get the latest BBC news headlines, and "time" to hear the time. Of course, getting computers to tell the time nicely takes a little bit of work. I dont like "Its eleven oh-three pee em", since thats not what someone would say if you asked them the time. I wanted my robot to say "Its just after eleven", and thats what Time::Human does. Shame about the localisation.

Javacelot project is a Java-based home automation utility for the Adicon Ocelot.
Javacelot is a Java utility for communicating with an Adicon Ocelot over the serial port. It uses Keane Jarvis RXTX utility for raw serial port I/O, Jakartas Log4J for logging, and Ant for building.
Javacelot mainly adds a friendly API for triggering and responding to X10, infrared, and other Ocelot signals.
Its not an application in itself, but a tool to facilitate the creation of Java-based home automation applications, especially heavily threaded Web-based applications.
Main features:
- Allows you to create and edit several Ocelot programs simultaneously.
- All configuration and source files are ordinary text files. Use your own text editors, versioning tools, scripts, or whatever.
- Built-in text editor with syntax highlighting and error navigation.
- New programming syntax similar to C# and Java, with support for multiple scopes, nested conditionals, aliases, and most other Ocelot features.
- Drag and drop of files for sharing between projects, or to reorder within a project.
- Built-in programming API allows you to write your own Ocelot-aware [java] applications.
- Generates a C-MAX compatible binary for each project.
- [RXTX] Upload programs directly to the Ocelot over the serial port, instead of using C-MAX.
- [RXTX] Send X10 commands
- [RXTX] Monitor X10, IR, and ASCII activity reported by the Ocelot.
- More to come!

DRACONi Automation project is a Web-based digital entertainment/automation control package.
DRACONi Automation aims to be a home automation and digital entertainment/automation control package. Its designed to be modular, meaning new kinds of functionality can be added easily.
Currently, the X10 CM11A and Applied Digital Ocelot/Leopard are supported. It can also control XMMS and the Festival Speech Synthesis System.
Enhancements:
- User based system complete with per-user security permissions (you can restrict certain users to only user certain parts of the system)
- Multiple interfaces
- HTML - for most standard web browsers
- mobile HTML - for mobile devices with smaller screens such as PDAs and larger cell-phones that can read HTML, but have
- xHTML Basic/WAP 2.0 - for mobile devices such as cell phones with very small screens and low bandwidth