Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[phorce1]

Well, I thought LOLA sucked wind pretty bad. So, I had a couple of CM19A transceivers lying around.

But, after grabbing the driver from http://www.lemaymd.com/main.php?frag=software and finagling the nits to get it to compile on my Debian Linux system (had to install the "kernel headers" package, full kernel source didn't do the trick for some reason -- also requires gcc-4.0, not 3.x or 4.1 -- 4.0!) I now have X-10 coolness on my home Linux box.

echo +b1 > /dev/cm19a0 turns on the living room light.

+ = ON
- = OFF
s = DIM (soften)
b = BRIGHT

It should also control the Ninja mounts (which I don't have yet)

u
d
l
r

(not hard to figure out what those represent)

Support for the CM15A is getting there also. Niel Cherry has quite a list going at http://www.linuxha.com/. Support is only being delayed by X10's obstinate refusal to share interface details with open source authors.

They just don't realize how much more HARDWARE they could sell if they'd quit trying to lock people into their proprietary (and badly broken) software.

I've pretty much decided against ever installing the AHP that I bought because of its intrusive nature. The required internet connection for something doesn't NEED the internet and is in CONTROL of my home is a BIG turn off. Even WindowsXP stays the fnork off of the Internet if I have auto-updates turned off. It works just fine with no net connection at all. Why does X10 NEED to know that my home is running their software after I've registered it? And if I do opt for control via the Internet, why do I have to send all of my video and home control commands TO THEIR SERVERS and allow them to relay the info? I don't care how careful they are, I'll bet there are a few enterprising X10 programmers watching the video streaming from random iWitness users around the U.S.A. Do you automatically set "security mode" as you leave the house? Are they watching your wife walk around naked because you left the cameras on?

Anyway, I went sideways there. Just get a little more irked every time I look over the software setup.

There are also Linux drivers for the VA11A so you can connect cameras. I think with a little bash scripting attached to a simple .cgi I may have a full web served house in a few months. Still need to get an "all house code" transceiver so I can run more than 16 devices. I may load AHP and turn on the CM15A to transceive all codes then unplug it from the computer. That would work for now. I'll wait for Niel's CM15A driver and the MisterHouse plugin to get a little more fleshed out before I attempt to integrate it into the system.

Gerald

[Charles Sullivan]

I've fiddled around a little with Lemay's CM19A driver, but not totally successfully.  The X10 commands work fine but my Ninja doesn't respond to the (limited) Ninja commands.

I had hacked a previous version of the driver to display the raw bytes received and accept a binary string of bytes for transmission, figuring I could just feed back a string received from a remote and have the same control via PC as with the remote.  This worked fine for X10 commands but I got nary a twitch out of the Ninja.  (I have only one CM19A so couldn't  verify I was receiving what I thought I was sending.)

The major problem with custom drivers like this is that unless they're popular enough and work well enough to be accepted into the official Linux tree, it's a constant battle to get updates as new kernels are released.

[phorce1]

And me != programmer at all. I just dig for what I can find and combine bits and pieces until I get something that works.

Another thing I like about the Linux setup is the fact that the VA11A isn't actually REQUIRED (as it is in AHP). I need a new video card for this machine anyway and am planning to add a TV Tuner card also. All I need to do is find a Linux supported card that accepts composite input and I won't have to fiddle with getting the VA11A driver compiled and working. May get a better frame rate than he did as well (although 10fps for home security is more than adequate -- I'd be happy with 1fps if that's all I could get).

I would like to know where he reads the bytes received from the remote. I haven't bothered installing X10XMMS because I wasn't thinking along the lines of controlling a multimedia player.

I'm hoping they incorporate this into MisterHouse or the CM15A support gets better.

I think these (or some version of them after they stabilize) will eventually get into the kernel tree just like all the support for the CP290 and CM11 is "there forever" now.

What I have is enough, I think, to put together a bash scrito that accepts parameters and use that as the back end for a pesonalized web app.

Gerald

[neil cherry]

I hope to have an Alpha version of the CM15A code running under Mr. House by the end of next week. I might play with the CM19A but I'm not sure as I'm working on several Power Line Controllers. The CM15A code is currently able to read data from the CM15A (only under Linux, with my driver) but isn't decoding it yet.

[InfernusDoleo]

Resurrecting an old thread...

Can anyone tell me how to READ FROM the CM19A under linux?

I got this working fine for sending commands... however... for the life of me I cannot read from the transceiver using this driver.

Can anyone point me in a direction?

[InfernusDoleo]

Found the answer myself by poking around the cm19a source tree, there's a program in there to read from the device.

[InfernusDoleo]

Ok, so, I've been messing with it more, and I've run into a roadblock... you can only read/write from/to the device from one thread/application/process at a time... I cannot have a daemon reading from the device, and another program writing to it. It just does not work.

But I need it to.

So I started hacking around in the code for the module... it seems data is only pulled from the USB if the device is being actively read from... I need to log data coming in regardless of if its being read or not (my idea is to log the incoming data to a log file, scan that file for incoming commands, then act on them, that way I dont need to be reading the device to actually see whats going on).

Anyone have experience with this? Its driving me crazy... I need a daemon to read from the device, then act on it by firing off sub-processes... I cant have the daemon run the sub processes because I cannot wait for the process to finish before I go back to monitoring.

Thoughts? Ideas? Halp?!

[pconroy]

Dunno if this helps - but here are two approaches I took for my CM11A and my CM19A.

The CM11A code is threaded up the wazoo - but I have only one thread that is allowed to communicate with the device. It's class exposes a read() method that, when called by other threads, grabs a mutex on a ring buffer and returns whatever data is in the buffer.

I don't need a  write() yet, but if/when - it'll be an asynchronous responder. It'll accept and queue the write, and either send them in order or something more sophisticated. And we'll see what kind of "bytes written" response I decide to send back to the caller.

The class then has a private read() method that spawns a thread that does nothing but spin on the COM port, waiting for data, and then sticking it in the ring buffer, moving the pointers.


I did it more as an exercise to see if I remembered some pthread() stuff and C++.
I'm not sure it's an elegant solution.
But it works for me.

--
As for the CM19A - I simply dedicate a process, deftly called "./cm19a" that owns the device.  Other processes then use standard IPC stuff to make their read/write requests.  In my case, I use TCP sockets (specifically SmartSockets).

I dunno if this is elegant either, but in 10 years of doing embedded device development, and 20+ years of large scale system creation, I tend to fall into a pattern of "separation of concerns" and asynch messaging between them.  It just scales so much mo' betta for me.


I have once process that is responsible for the CM19A interface.  A separate process that sends X10 commands to that CM19A process. Another process that takes CM19A receptions and does "heyu" things. etc.

--

Yeah - you're right. Sooner or later, you need some uber-app, or process in the center that keeps track of everything. That's the job of my app called "homeserver" and it runs on the Linux server in the basement.  It receives all of the socket transmissions and just keeps global state.


I'm not happy with that and have started on replacing that with an Enterprise Service Bus (currently Mule).
With an ESB - your not worried about threads or devices, they become endpoints on the bus.  And the bus handles routing of the events.



Not sure if I helped or made it worse. 
 

[altagir]

http://opendesktop.org/content/show.php/x10+Controller+Plasma+Widget?content=157168

Inspired from driver from lemay and libusb to make a Controller Widget under KDE.
-> directly access the device through libusb, with a queueManager. haven't done the read part

hope that helps