Are there some other X10 devices that you know that are working but aren't listed in the X10 wiki page? We can work together to fix and create missing X10 pages so WIKI becomes more usable also for others.

Looks like I subconciosly logged in as the first account that I originally created....... I forgot the password and the email adres i used then isnt working anymore. So I couldn't retrieve my password. Hari could delete that account karelvdm. Back to the topic.

Currently I have;CM11SA 3x PLC-R2263E to control lights1x PLC-R2268HE for fluorescent light1x TM13SA for RF signal communication for Motion sensors2x MS13E2 Motion sensor1x UM7206 this is a universal module that acst as a relay/dry contact switch. Controlling my electric/automated gate.The "SA" behind the CM11SA and TM13SA is just indication that its suitable for the South African market. 220V

Mochad <http://mochad.sourceforge.net/> is a good project to use to create a driver. From the wiki,

Everything sent by mochad appears on netcat standard output. In the simplest use case, mochad/netcat can be used to see X10 PL and RF activity. For example, run mochad on one host with a CM15A(CM19a) then connect to it using netcat from a netbook. Walk around with various X10 RF remote controls and the netbook to see which remotes work from various locations.

I'm using it with Misterhouse right now, and would need to port that to LMCE. I'm using it with X10 RF keypads to trigger scenes, and to send commands to devices behind Arc Fault Breakers (haven't converted everything to Insteon yet.

Thom, what would be the best method to implement a driver using mochad, given that netcat is normally used to send and receive data from mochad (which then handles the interaction with the CM15/19a)?

The most correct approach for mochad is to wrap the C in the C++ provided by our DCE driver.

If you look on the wiki, under Developing a DCE Device, you'll see an article detailing how to set things up so that this can be done, as well as an explanation of the device template, its parameters, etc.

At the other end of the spectrum, would be a GSD device, that launches mochad, and talks to it via its pipe.

The most correct approach for mochad is to wrap the C in the C++ provided by our DCE driver.-Thom

Thom, if I'm understanding you correctly, you're saying it would be best to take the mochad C source code functions, and put those into the C++ functions provided by the DCE driver, correct? Or are you meaning to wrap the binary like the General Info plugin wraps the mailx binary? I'm not a C programmer by any stretch of the imagination, so I'm just looking to clarify my understanding of which direction you're pointing me in ;-)

Mochad is GPL v3. Is there any issue with rolling it's code into a DCE device driver, which I think is GPL v2? I plan on contacting the author of Mochad as well, to see if he has any issues with rolling it into LMCE.

If all's good there, I'll likely implement it as a C++ driver, and as a GSD. It'll give me some experience with both, and there's a possible use case of the GSD with a remote mochad instance running on another computer/embedded device.

Would it be sufficient for me to set up a chrooted dev environment, or do you recommend a separate development environment (VM). I'm not running production workload on my LMCE instance at this point in time, so I'm not overly concerned about it.