Back to work
Last Saturday I backed from vacations. Me and my wife Maria had nice time: met with parents and friends, walked on the St Petersburg streets, watched a few performers in the theater and didn’t have an Internet (except weak dial-up). So, we got an excellent rest!
During that vacations I bought a set of X10 devices for testing: CM11 (USB and RS232), TM13U and MS13E. Yesterday I setup CM11 together with TM13U and tested them with LinuxMCE. They work perfectly without any problems (wrapper suggested by Sam is not needed in my case). The next step is adding MS13E and creation a few scenarios.
Updated: After adding MS13E TM13U is not working anymore. I’ll try to setup it again and if it won’t work I’ll add the wrapper suggested by Sam.
Related Posts:
4 comments:
Possible you’re right. I’ll add MS13E tomorrow and check how it works. I’ll write down results here.
Sam, you’re right. After I added MS13E the TM13U is not working anymore. In the log I see those messages:
10 10/25/07 22:31:24.148 Sending address with HouseCode=6, DeviceCode=6. <0xb6960b90> 10 10/25/07 22:31:24.148 Sending packet with HighByte=4, LowByte=66. <0xb6960b90> 10 10/25/07 22:31:24.148 Sending header with Checksum: 6a. <0xb6960b90> 10 10/25/07 22:31:26.056 Got response: 5a from CM11A. <0xb6960b90> 01 10/25/07 22:31:26.056 Bad checksum received (send:6a, recieved:5a). <0xb6960b90> 01 10/25/07 22:31:26.160 Failed sending address. <0xb6960b90>
I’ll try to use your wrapper.
Hi Michael,
exactly, that’s the problem. I think we need to do a few things:
1- I owe the community a better explanation of how to implement my workaround, I saw on the forums that many people were struggling to use the wrapper. I will update the wiki when I get a chance (time is not on my side)
2- the bugs exist on pluto Mantis, but they became a bit “messy”. I think the problem is clear (lmce expects a checksum from CM11 for the last sent command, and gets an X10 event instead), which could be solved by polling the CM11 (good time to make the CM11 driver bi-directional) or clearing its queue before sending a command (ugly). Now we need to find a good C++ coder to fix it…
I will also work on making the heyu wrapper bi-directional, it should be very easy because heyu includes the possibility to handle X10 events and execute scripts when they happen. That script could just be a wrapper to /usr/pluto/bin/MessageSend…
Sam
Welcome back Michael
CM11 + TM13 worked fine for me too with the LMCE driver. It’s when I added the MS13E (or any X10 device that generates events that “pollute” the input queue of the CM11 that I started getting into trouble (with early versions of pluto and LMCE). If you get the MS13E working with the native driver, please let me know, I’ll remove my wrapper and try again with the latest LMCE.
thanks !
Sam