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 everythingstops working. To make it work again, I have to Unplug/Replug the CM11A module, and then it will work untilthe 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

-SOFTWARE VALIDATIONI 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 devicesI 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 replugthe 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

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.

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 ?