Python X10 CM19A USB Driver version 3.0 is here
Download
New features
Basic command line argument functionality
- e.g. ./CM19aDriver.py A1 ON
- Send only, you cannot receive commands via this approach becuase the device does not maintain a queue of commands received.
- Relatively slow because the driver must initialise the device each time and then exit.
- This is the default mode of operation: MODE = 'Command Line'
Built-in HTTP server
- Send and receive commands via a web browser, any app that supports http get calls, or even the command line (using cURL)
- e.g. http://192.168.1.3:8008/?house=A&unit=1&command=ON
- The driver starts and remains running so it can monitor and respond to http requests and capture inbound RF commands received by the CM19a
- Faster than the basic command line interface becuase the device needs to be initilaised only once (at startup)
- You need to set MODE = 'HTTP Server' to use the driver this way. You also need to set the IP address and port you wish to use.
Bug Fixes
Fixed several bugs relating to bright/dim functionality
- Added in missing bright/dim commands to the protocol file
- Modified approach to decode bright/dim button presses from a X10 RF remote
- Now identifies the house code as well as the button pressed (bright or dim) on the RF keychain remote
Enjoy... Feedback and bug fixes welcome.
Andrew
I was looking for this. Thank you.
ReplyDeleteFirst off, great work Andrew. I really appreciate your work on this.
ReplyDeleteI was curious if you have done any testing with a VirtualBox environment passing through the USB device? I am getting "Operating timed out" and "Incorrect number of bytes written". Every couple sends and need to re-initialize (reopen in HTTP mode). I am pretty sure it is because the virtual box passthru is probably doing something weird.
Thanks again!
Found a way to work on a USB Firecracker just bought (12/16/2011) from X10.com.
ReplyDeleteFirst: sudo run the scripts.
Second: The end points are 0x83 and 0x04 instead of 0x81 and 0x02.
Third: The bright/dim commands look completely different. They are 8 bytes long and I cannot make sense of them. But, then, I have no lamp module.
The PC software sends the commands twice, btw.
Hi Andrew. I have a cm15a. It has an ID Product = 1. I have changed this in your code. Everything seems to be ok when I run a command like:
ReplyDelete./CM19aDriver.py A 1 ON
Initialising...
Cm19a opened and interface claimed.
Vendor ID (dev.idVendor): 3015 (0bc7 hex)
Product ID (dev.idProduct): 1 (0001 hex)
Device Version: 01.00
usbVersion: 01.10
Number of Configurations: 1
Doing A1 ON...
Sending A1 ON
Result A1 ON: True
Result: True
but the module with A1 code does nothing.
Do you have any suggestions?
Maybe the protocol es not the same?, but I have "True" result ??
Hi vicnala
DeleteI think the Cm15a has a different protocol.
It looks the driver found your device successfully (using the vendor ID and your product ID of 1) and that the command was successfully written to the device (result is True).
The CM19a doesn't complain if you write an invalid protocol byte string so there is no way to tell if the protocol is different for your device.
You might like to look here http://www.linuxha.com/athome/index.html#Software.
Let me know if you find details on the protocol and maybe we can add it to the driver.
For any readers that are wondering, this will also work in Windows 7. To get it working you must do steps 1 through 8 of Michael LeMay's Driver install. (http://m.lemays.org/projects/x10-cm19a-linux-driver)
ReplyDeleteAndrew, this works great. Thanks for your hard work.