Many things are To Be Done but it works on Ubuntu 10.04 and 10.10 and three OpenWrt devices: LinkSys NSLU2 (very old), Seagate DockStar, and Buffalo WZR-HP-G300NH WiFi router. However, details on building for OpenWrt are not in the README yet. TBD is creating a package for easier building and installation.

See the README for more details on which X10 modules are known to work with mochad.

mochad is not a full home automation program. It is a device driver with TCP socket interface. mochad is implemented using libusb-1.0 so is not a Linux kernel device driver.

Post questions or comments here or on the sourceforge discussion page.

Sorry, yes. mochad runs in the background and controls the CM15A and CM19A. mochad accepts TCP connections on port 1099 so client programs such as netcat can send RF/PL commands to mochad and receive RF/PL events from mochad.

I expanded the README into a Wikipage <http://sourceforge.net/apps/mediawiki/mochad/index.php?title=Main_Page>. This is clearer than my late night posting.

I do not own any X10 cameras so this is based on examining USB packets generated by AHP when clicking buttons in the virtual remote control pad for the VK7X module. I am interested in hearing if this actually works.

I did reverse engineer but with a lot of help from existing X10 protocol documentation listed in the README file and from USB Snoopy. USB Snoopy is an open source Windows USB sniffer.

Macros and timers are too complex so they are not supported. Looks like there are some similarities to the CM11A but there are too many differences for me to figure out.

The standard X10 PL, X10 RF, and X10 RF security packets should all work. The X10 camera commands are incomplete.

To Do list

Hotplug support so mochad runs when a CM15A/CM19A is plugged in. Currently, the controller must be plugged in when the mochad starts. If not, mochad bails out with a warning message in /var/log/messages.

TCP is the way applications communicate with mochad and the CM15A/CM19A. I have not used heyu or misterhouse but I was thinking they might be able to use mochad as a backend device driver by opening a TCP socket to it.

mochad is still a work in progress and I am writing my own HA app using mochad with more than one controller. Using more than one controller is the original, and still the primary, reason for the network interface. If I had more time I would get involved in other projects but it is not possible right now.

I was using heyu for it's CM17A (firecracker) support to send commands to my CM15A.

Now, with mochad, I can get rid of the CM17A and have a look at the CM15A transmitted and received x10commands.

But ...

I have a question, the dim and bright commands (of a normal lamp module) do not behave like withheyu. Can you give an explanation of what is the number 0..31 that we give ? With heyu, that was the numberof dim or bright steps (steps of 6% with a CM15A) sent to the device.

Also, an interesting feature to add would be adding a feature that would watch for certain command orlogs to launch a user defined script. I think I'll do that my way, but when the daemon starts, itwould be interesting to have a log file (and not having to log with netstat).

This only works with older lamp modules. I am fairly new to X10 so my gear hasbeen purchased in the last couple of years so none of my lamp modulesunderstand this command.

As far as I can tell, 0..31 is the number of steps to dim or brighten. The wayto make it go to 50% dim is to first turn the lamp on to full brightness thensend a dim 15. But this is just a guess because I have no way to test this.

pl a1 xdim 0..63 sends the extended pre-set dim

If you have newer lamp modules (LM465) with soft-start, the xdim command isrequired. 0..63 is the absolute intensity level so for 50% send 32, 75% send48, etc. 63 is a special value that means go to maximum intensity instantly.62 is the maximum intensity with soft-start.

The value can range from 0..255 according to the X10 specification but theLM465 ignores the higher values. The upper two bits are supposed to control therate at which the intensity changes (faster or slower) but the LM465 is notaffected.

I like the idea of mochad write a log file. I usually do something like this"nc localhost 1099 >logfile.txt &" but it is one extra step.

At least for the moment, mochad is more like an SDK than a full HA applicationlike heyu or misterhouse. It is fairly easy to use Perl as a scripting languageto implement your own HA app. Any language that can connect to a TCP socket canbe used.

For example, bash has a socket programming API so shell programmers can connectto mochad directly. It is "merely" a matter of examining ASCII text strings forthe desired events. This is simple enough for a single device but will getcomplex if you have a house full of various kinds of modules. But the minimumamount of code to create a useful HA app is quite small. BTW, flite is a smalltext-to-speech command line program.

#!/bin/bash#This bash program connects to mochad then scans for alert/normal events from #a specific DS10A. The lamp or appliance module M1 is turned on#for alerts and off for normal. Assuming flite is installed, voice prompts#should also be heard.#Sample event generated by mochad for a DS10A#12/20 11:53:58 Rx RFSEC Addr: EF:43:80 Func: Contact_alert_min_low_DS10A

Have you really tested the dim and xdim with a lamp module ?I have LM465 modules, and I've bought very recently, probably they're the newer model.

xdim doesn't work at all, does nothing (I could post the nc output, if you want).dim doesn't work at all like you say... i really don't understand how it works...it doesn't seem to be at % of the max intensity

with heyu, the dim command was really a small step in increasing or decreasing theintensity of about 6%, and it worked fine. I am not sure there was a wayto tell the module to directly go to 50% or 75% of the max intensity.In fact, if possible, both ways of controlling the intensity are interesting... depending on the application !

are you able to test it out ?

the on and off commands are working fine thought...

yes, redirecting the nc output was what I was doing (a line I added to rc.local or rc.start) but why not use a init script with the syslog facility ?and I was thinking of something like your bash script to keep an eye on eventsand exec some scripts...

give me news as soon as you "put some light" on the dim/bright commands ;-)