The fix was submitted about a month ago, but it never made it to beta 4 unfortunately. It is however in the svn.linuxmce.com/pluto/trunk. You could download the required files from there:CM11A/devicepoll.cppCM11A/devicepoll.hCM11A/cm11aconsts.hSerial/SerialPort.cppSerial/SerialPort.hLighting_Plugin/Lighting_Plugin.cppLighting_Plugin/Lighting_Plugin.hpluto_main/Define_EventParameter.h

If you are running 64-bit, i will send you the binaries if you want them.

The fix is 100% stable, and extremely fast (fast for x10 anyways) - everything happens for me in well under a second. Also, I am using this in a house with around 100 active x10 modules (all light fixtures and outlets in the house are X10, as well as many sensors, plug-in modules, and inline modules.

I understand why it doesn't work for me. I recompiled CM11A only. So, I should build Serial and Lighting_Plugin as well, right?

Yes, you must compile them too.From /Serial run make, then copy the resulting libSerial.so to usr/pluto/libFrom Lighting_Plugin, run make so, then copy the resulting Lighting_Plugin.so to usr/pluto/bin

let me introduce myself: my name is Xurde, I´m from Asturias (Spain) and I´m doing my Final Project with X10. I got stuck at some point, and from what I´ve read in this post I think (and hope) you can help me. My project is about sending X10 signals from the PC, through CM11 interface. The problem is I´m receiving the "evil" 0x5A and so I can´t send any signal. I tried to send the ACK 0xC3 but it doesn´t work! I've read your post (to be honest I didn´t read it entirely) and I saw you solved it, but I didn't get How. I´d be really happy if you could help me, thanks in advance,

actually I´m developing the program with Windows (big Mistake), anyway I´ve just realized I was interpreting the signal in a very bad way, I´m receiving 0xA5, no 0x5A, what means a power fail! A solved it by sending 0xfb and updating the clock.

Anyway, thanks, if you guys still need anything, just write down in this post.

The biggest thing we learned about the CM11A while tearing into it is that there exists some hardware flaws that make making a completely bulletproof driver extremely difficult.

For example, the CM11A can and will receive PLM data even during the middle of sending data. With a shared rx/tx buffer, you can see how this could get ugly. Before sending any data, queue it up and make sure that the serial ring is not indicating that data is coming in, and double check to make sure there isn't data already waiting to be processed. You can't fix the hardware flaw, but the more you can do to eliminate such collisions, the more stable things will be.

Another thing that can get you is that there are certain situations where 0x5A is a checksum, so be sure to include logic in your 0x5A handling that copes with situations where you are actually expecting it!