Hi all.
I have been working on a Pluto problem for the past weeks and I pretty much narrowed it out, but
I now need you guys to help solve it.
-=HARDWARE USED=-
CM11A (x10) (on ttyS0)
RR501 (x10) (later replaced by TM751)
LM456 (x10 light module)
MS16A (x10 motion sensor)
UR19A (x10 remote control)
Up-to-date Core/Hybrid Pluto
-=PROBLEM DESCRIPTION=-
When any of the RF devices sends a signal (MS16A or UR19A) to my RF receiver (RR301 or TM751 / never used at the same time BTW),
every other X10 controls stops working.
Eg:
From pluto I made a lighting scenario controling A2 on the LM456 and A9 on my RR501. Works great.
Then I put the batteries in the MS16A motion sensor A1 (or UR19A remotre control, dosent matter) and everything
stops working. To make it work again, I have to Unplug/Replug the CM11A module, and then it will work until
the next RF signal is tranmitted.
-=LOG MESSAGES=-
I found something interresting in the logs. Take a look:
(56_CM11A.newlog)
---LIGHT CONTROL 'BEFORE' RF (MS16A) IS TURNED ON-- SENDING OFF SIGNAL TO BOTH A2 AND A9
10 02/25/06 13:04:33.843 Child device 57 has channel A2.
10 02/25/06 13:04:33.845 Child device 58 has channel A9.
10 02/25/06 13:04:33.900 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:04:33.900 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:04:33.900 Sending header with Checksum: 72.
10 02/25/06 13:04:33.924 Got response: 72 from CM11A.
10 02/25/06 13:04:33.924 Sending ACK.
10 02/25/06 13:04:34.364 Got response: 55 from CM11A.
10 02/25/06 13:04:34.364 Address sent successfully.
10 02/25/06 13:04:34.364 Sending function with Code: 3.
10 02/25/06 13:04:34.364 Sending packet with HighByte=6, LowByte=63.
10 02/25/06 13:04:34.364 Sending header with Checksum: 69.
10 02/25/06 13:04:34.380 Got response: 69 from CM11A.
10 02/25/06 13:04:34.380 Sending ACK.
10 02/25/06 13:04:34.824 Got response: 55 from CM11A.
10 02/25/06 13:04:34.824 Function sent successfully.
10 02/25/06 13:04:34.824 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:04:34.824 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:04:34.824 Sending header with Checksum: 6b.
10 02/25/06 13:04:34.848 Got response: 6b from CM11A.
10 02/25/06 13:04:34.848 Sending ACK.
10 02/25/06 13:04:35.288 Got response: 55 from CM11A.
10 02/25/06 13:04:35.288 Address sent successfully.
10 02/25/06 13:04:35.288 Sending function with Code: 3.
10 02/25/06 13:04:35.288 Sending packet with HighByte=6, LowByte=63.
10 02/25/06 13:04:35.288 Sending header with Checksum: 69.
10 02/25/06 13:04:35.308 Got response: 69 from CM11A.
10 02/25/06 13:04:35.308 Sending ACK.
10 02/25/06 13:04:35.748 Got response: 55 from CM11A.
10 02/25/06 13:04:35.748 Function sent successfully.
Works fine
---LIGHT CONTROL 'AFTER' RF (MS16A) IS TURNED ON-- SENDING OFF SIGNAL TO BOTH A2 AND A9
10 02/25/06 13:06:02.877 Child device 57 has channel A2. <--- LM456
10 02/25/06 13:06:02.879 Child device 58 has channel A9. <--- RR501
10 02/25/06 13:06:02.955 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:02.955 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:06:02.955 Sending header with Checksum: 72.
10 02/25/06 13:06:04.079 Got response: 5a from CM11A.
01 02/25/06 13:06:04.079 Bad checksum received (send:72, recieved:5a). <------- BUG
10 02/25/06 13:06:04.179 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:04.179 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:06:04.179 Sending header with Checksum: 72.
10 02/25/06 13:06:05.919 Got response: 5a from CM11A.
01 02/25/06 13:06:05.919 Bad checksum received (send:72, recieved:5a). <------- BUG
10 02/25/06 13:06:06.019 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:06.019 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:06:06.019 Sending header with Checksum: 72.
10 02/25/06 13:06:07.763 Got response: 5a from CM11A.
01 02/25/06 13:06:07.763 Bad checksum received (send:72, recieved:5a). <------- BUG
10 02/25/06 13:06:07.863 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:07.863 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:06:07.863 Sending header with Checksum: 72.
10 02/25/06 13:06:09.603 Got response: 5a from CM11A.
01 02/25/06 13:06:09.603 Bad checksum received (send:72, recieved:5a).
10 02/25/06 13:06:09.703 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:09.703 Sending packet with HighByte=4, LowByte=6e.
10 02/25/06 13:06:09.703 Sending header with Checksum: 72.
10 02/25/06 13:06:11.447 Got response: 5a from CM11A.
01 02/25/06 13:06:11.448 Bad checksum received (send:72, recieved:5a).
01 02/25/06 13:06:11.547 Failed sending address.
10 02/25/06 13:06:11.548 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:06:11.548 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:06:11.548 Sending header with Checksum: 6b.
10 02/25/06 13:06:13.287 Got response: 5a from CM11A.
01 02/25/06 13:06:13.287 Bad checksum received (send:6b, recieved:5a).
10 02/25/06 13:06:13.387 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:06:13.387 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:06:13.387 Sending header with Checksum: 6b.
10 02/25/06 13:06:15.131 Got response: 5a from CM11A.
01 02/25/06 13:06:15.132 Bad checksum received (send:6b, recieved:5a).
10 02/25/06 13:06:15.231 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:06:15.231 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:06:15.232 Sending header with Checksum: 6b.
10 02/25/06 13:06:16.972 Got response: 5a from CM11A.
01 02/25/06 13:06:16.972 Bad checksum received (send:6b, recieved:5a).
10 02/25/06 13:06:17.071 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:06:17.072 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:06:17.072 Sending header with Checksum: 6b.
10 02/25/06 13:06:18.816 Got response: 5a from CM11A.
01 02/25/06 13:06:18.816 Bad checksum received (send:6b, recieved:5a).
10 02/25/06 13:06:18.916 Sending address with HouseCode=6, DeviceCode=7.
10 02/25/06 13:06:18.916 Sending packet with HighByte=4, LowByte=67.
10 02/25/06 13:06:18.916 Sending header with Checksum: 6b.
10 02/25/06 13:06:20.656 Got response: 5a from CM11A.
01 02/25/06 13:06:20.656 Bad checksum received (send:6b, recieved:5a).
01 02/25/06 13:06:20.756 Failed sending address. <------- BUG
-=TESTS DONE=-
After all the tests I made, It seems to be a small glitch in the Pluto code. Let me explain why and what I did:
-HARDWARE VALIDATION
Replaced the RR501 Tranceiver by a TM751 = Didn't help.
Tried from Motion sensor (MS16A) and Remote (UR19A) = Didn't help
Used 3 diffent AC outlets = Didn't help.
Moved Tranceiver's antena in countless ways = Didn't help
I installed PLUTO on a different Computer (diffent tty port) = Didn't help.
-SOFTWARE VALIDATION
I re-installed PLUTO 4 times (2xCORE, 2xHybrid) = Didn't help.
I installed my CM11A on the MD instead of Core = Didn't help.
I installed a third party software (autoM8bit) = Worked fine with all RF devices
I installed a third party software (homeseer) = Worked fine with all RF devices
(these test also validate my hardware now.)
-=MAYBE THE PROBLEM IS...=-
What the problem seems to be, is that the RF devices seems to "shift, de-phase" the data information in Pluto's buffers.
The data seem to be maybe Shorter or Longuer (bit terms) that what Pluto is expecting when comming from RF devices (input).
What makes me think that: the Checksum errors in the logs, Bad checksum received (send:6b, recieved:5a)
is always the same. So it's not noise or anything. It seems to be a protocol bug.
Also the fact that other software work fine with my hardware and electrical network tells me its only a bad interpretetation from Pluto.
Once the CM11A received a RF signal, the rests of the sequences are all messed up for ever until I unplug and replug
the CM11A.
-=CONCLUSION=-
Sure hope you can help me with that.
I did everything I could to solve this myself (forums, e-mails, tests, troubleshooting docs...).
I love Pluto and I want to use it really bad. But this problem is stopping me from using it the way I need to.
Please help me.
Thx alot.
If you have any suggestions, or tests you want me to do, pls contact me.
We actually never tested CM11A with RF because we don't have any. We even didn't test it with an X10 transmiter (like motion detector) but the code exists and theoretically should work.
So this may be / be not a bug in pluto.
I see the situation you describe a little different:
The part you must look at is
Quote10 02/25/06 13:06:04.079 Got response: 5a from CM11A.
01 02/25/06 13:06:04.079 Bad checksum received (send:72, recieved:5a)
The "0x5A" comming from CM11A is known as "Interface Poll Signal" on which we should respong with "0xC3".
This means that interface is trying to notify us of something. Howether it happend at VERY bad time:
CM11 was waiting for a checksum from command it sent few moments ago. Instead of getting a checksum it's waiting for (0x72) it get's pooling (0x5A), from it's point of view send was unsuccesifull and it retries.
Yes we have to limit this retrying (i'm not sure but i think it's already done), but this is also a misbehavior of CM11+RF.
As far as I know only 1 message should be on powerline on any given moment so it should finish sending one message (transmit, checksum, acknowledge) and only then start doing something else (like pooling).
Cant you test it somehow without triggering pooling while waiting for checksum ?
Hi !
Thx for the reply.
Instead of getting a checksum it's waiting for (0x72) it get's pooling (0x5A), from it's point of view send was unsuccesifull and it retries.
Here's the catch. Has I said the checksums occur when I plug in a RF device, like a Motion Sensor or a Remote Control. But what I might have not mentionned on my first post is this: When I put the motion sensor on, bad checksum starts. BUT then I take out the batteries, and even then, bad checksum continue, forever. So Im pretty sure its not Polling from the motion sensor, cause even once its gone, Bad Checksum keep rising.
I beleive that once my CM11A interface sends data to Pluto on the Serial Port, that some pins on the RS232 interface (DTR, DSR maybe) are set to a value that pluto can't deal with and then misunderstand the rest of the data.
As far as I know only 1 message should be on powerline on any given moment so it should finish sending one message (transmit, checksum, acknowledge) and only then start doing something else (like pooling).
Thats not a problem with my RR501 RF transmitter, cause thats exactly what he is programmed to do. He listens before he transmits (compare this to CSMA/CD on ethernet.) If you guys are willing to work on the problem, I could plug a BOB on the serial port to see if my concerns are real...
Cant you test it somehow without triggering pooling while waiting for checksum ?
I don't really understand what you want me to do?
Can you give me a little more info please.
Thx
Sorry but the message before somehow was posted as "guest".
What I was saying is that when CM11 initializes itself it does:
1. show child devices
Quote10 02/25/06 13:06:02.877 Child device 57 has channel A2. <--- LM456
10 02/25/06 13:06:02.879 Child device 58 has channel A9. <--- RR501
2. Trying to send something
Quote10 02/25/06 13:06:02.955 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:02.955 Sending packet with HighByte=4, LowByte=6e.
3. Expecting a checksum as described in http://hypermetrics.com/rubyhacker/x10proto.html
Quote10 02/25/06 13:06:02.955 Sending header with Checksum: 72.
4a. In your first example
Quote10 02/25/06 13:04:33.924 Got response: 72 from CM11A.
10 02/25/06 13:04:33.924 Sending ACK.
4b. Your second example
Quote10 02/25/06 13:06:04.079 Got response: 5a from CM11A.
01 02/25/06 13:06:04.079 Bad checksum received (send:72, recieved:5a).
It doesn't get a checksum for what it sent, and it retries forever (this is the only bug I see)
Now, the response instead of being 0x72 is 0x5A which may be (may be not) an interface pooling message. In this case somebody started transmition before completing previos transmision with checksum and acknowledge (the only "new" device is your RF)
Try to unplug you RF, quick reload router, let it work for few minutes, and only then plug your RF, and see what happends.
I use a CM11A with the CM11A driver. I get exactly the same behavior as described here.
The CM11 can send commands and lamps react accordingly.
As soon as I use (even just once) another device than the CM11 to send commands (I have tried with two different types of RF transmitters), pluto becomes unable to send commands and I get
Quote
Bad checksum received (send:72, recieved:5a).
It looks to me that the command sent via the RF transmitter is queued in the CM11 interface, and when the pluto driver sends another command later on, it gets the polling message from the CM11 because there is sth still in the queue waiting to be polled by the PC.
I would then guess that the pluto driver interpretes this as a checksum instead of a polling message. Of course I may be completely wrong...
When does the pluto driver poll the interface for incoming X10 events?
I know the CM11 driver isn't supposed to support incoming events (too bad) but wouldn't it be possible to at least flush the CM11 queue before trying to send a command ?
Hi,
I will make a review over CM11A source code in the next 2-3 weeks.
I hope I will detect the problems.
Regards,
Eugen