I am using a CM11A to control one X10 appliance module for testing right now. The CM11A is connected via a usb to serial adapter. I am using the same adapter model without issue to control a TV on another media director.
I am able to control the X10 appliance module from linuxmce, however, I have found that the CM11A device gets disabled about once or twice a day.
Has anyone else encountered this problem?
To get it working again, all I have to do is re-assign the correct serial port and uncheck disabled on both the CM11A and lighting module.
Regards,
Alex
Here is the log for the CM11A device:
10 05/26/09 21:51:09.743 Receive string: MESSAGE 74 <0xb7145b90>
10 05/26/09 21:51:09.743 Received MESSAGE 74 0x806f740 device: 137 <0xb7145b90>
10 05/26/09 21:51:09.743 Received Message type 1 ID 192 from 0 to 138 (device: 137) resp 0 <0xb7145b90>
10 05/26/09 21:51:09.743 Child device 138 has channel A1. <0xb7145b90>
10 05/26/09 21:51:10.416 We have data to send for CM11A. <0xb6944b90>
10 05/26/09 21:51:10.416 Sending address with HouseCode=6, DeviceCode=6. <0xb6944b90>
10 05/26/09 21:51:10.416 Sending packet with HighByte=4, LowByte=66. <0xb6944b90>
10 05/26/09 21:51:10.416 Sending header with Checksum: 6a. <0xb6944b90>
10 05/26/09 21:51:10.428 Got response: 6a from CM11A. <0xb6944b90>
10 05/26/09 21:51:10.428 Sending ACK. <0xb6944b90>
10 05/26/09 21:51:10.860 Got response: 55 from CM11A. <0xb6944b90>
10 05/26/09 21:51:10.860 Address sent successfully. <0xb6944b90>
10 05/26/09 21:51:10.860 Sending function with Code: 2. <0xb6944b90>
10 05/26/09 21:51:10.860 Sending packet with HighByte=6, LowByte=62. <0xb6944b90>
10 05/26/09 21:51:10.860 Sending header with Checksum: 68. <0xb6944b90>
10 05/26/09 21:51:10.871 Got response: 68 from CM11A. <0xb6944b90>
10 05/26/09 21:51:10.871 Sending ACK. <0xb6944b90>
10 05/26/09 21:51:12.364 Receive string: MESSAGE 67 <0xb7145b90>
10 05/26/09 21:51:12.364 Received MESSAGE 67 0x806f740 device: 137 <0xb7145b90>
10 05/26/09 21:51:12.364 Received Message type 7 ID 0 from 14 to 137 (device: 137) resp 0 <0xb7145b90>
10 05/26/09 21:51:12.615 Command_Impl::OnQuit forwarding quit's to children <0xb7145b90>
10 05/26/09 21:51:12.615 Socket m_Socket 6/0x806f740 Command_Impl1 Dev #137 m_bQuit=1 <0xb7145b90>
10 05/26/09 21:51:12.615 Requesthandler 0x806f740 (device: 137) Closing request handler connection <0xb7145b90>
13 05/26/09 21:51:12.615 Exiting BeginHandleRequestThread thread... <0xb7145b90>
13 05/26/09 21:51:12.616 Exiting MessageQueueThread_DCECI thread... <0xb7946b90>
10 05/26/09 21:51:12.617 Destroying CM11A <0xb79476c0>
10 05/26/09 21:51:12.617 Destroying Thread - before Wait <0xb79476c0>
01 05/26/09 21:51:25.871 No response from CM11A device. <0xb6944b90>
10 05/26/09 21:51:26.421 Destroying Thread - After Wait <0xb79476c0>
10 05/26/09 21:51:26.422 Waiting for message queue thread to quit <0xb79476c0>
I seem to have eliminated this problem by switching the serial port to which the CM11A is connected. I moved the CM11A from the USB to serial adapter to a com port that is onboard the motherboard. I also moved my receiver's control connection from the onboard to the usb com port. So far both the receiver and the CM11A are working well.
I have seen this as well, while I was using the USBtoSerial adapter. As my system had a USB-UIRT on it, on a reboot, sometimes the device ID would change and /dev/ttyUSB0 would become /dev/ttyUSB1. I have since then purchased a serial daughter card for the header on my mobo, and now the issue has gone away. I thought it was just dumb luck, but now as you have experienced the same thing, I guess we can chalk it up to the USB bus.
My system is currently functioning with a CM11A, 19 X10 devices, and 3 Insteon Devices.
Regards,
Seth
Thanks for confirming that you've seen this too Seth. I too, was wondering whether the USB to serial adapter was actually the cause or whether there was something else going on.
Cheers,
Alex