LinuxMCE Forums

I have my CM11A set up per the wiki instructions. I have the correct Com port selected for its device data.

Now I am adding lights (or trying to anyways). I add a light as a child to the CM11A, but I'm unsure what to put for Device Data -> Port/Channel Number.

Just to test it out, I have a lamp module set to A1. Does this mean I just need to put A1 in the Port/Channel Number field?  I have tried it with no success so far.


thanks

Jon

Yes it's A1 that you'll need to put in the "Port/Channel" field.  You may need to set "Room" and "PK_FloorplanObjectType" as well.

Huh, still no go.

Do I need anything in the "Device Pipes used" field?

Here is my log while manually trying to send on/off commands to the switch at A1


/var/log/pluto/40_CM11A.log

10 02/09/08 11:46:40.296 Received MESSAGE 77             0x62b170 device: 40 <0x41001950>
10 02/09/08 11:46:40.296 Received Message type 1 ID 192 from 0 to 41 (device: 40) resp 0 <0x41001950>
10 02/09/08 11:46:40.296 Child device 41 has channel A1. <0x41001950>
10 02/09/08 11:46:40.323 Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10 02/09/08 11:46:40.323 Sending packet with HighByte=4, LowByte=66. <0x41802950>
10 02/09/08 11:46:40.323 Sending header with Checksum: 6a. <0x41802950>
10 02/09/08 11:46:55.330 No response from CM11A device. <0x41802950>
10 02/09/08 11:46:55.430 Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10 02/09/08 11:46:55.445 Sending packet with HighByte=4, LowByte=66. <0x41802950>
10 02/09/08 11:46:55.445 Sending header with Checksum: 6a. <0x41802950>
10 02/09/08 11:47:10.450 No response from CM11A device. <0x41802950>
10 02/09/08 11:47:10.550 Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10 02/09/08 11:47:10.550 Sending packet with HighByte=4, LowByte=66. <0x41802950>
10 02/09/08 11:47:10.550 Sending header with Checksum: 6a. <0x41802950>
10 02/09/08 11:47:25.553 No response from CM11A device. <0x41802950>
10 02/09/08 11:47:25.653 Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10 02/09/08 11:47:25.653 Sending packet with HighByte=4, LowByte=66. <0x41802950>
10 02/09/08 11:47:25.653 Sending header with Checksum: 6a. <0x41802950>
10 02/09/08 11:47:40.661 No response from CM11A device. <0x41802950>
10 02/09/08 11:47:40.761 Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10 02/09/08 11:47:40.761 Sending packet with HighByte=4, LowByte=66. <0x41802950>
10 02/09/08 11:47:40.761 Sending header with Checksum: 6a. <0x41802950>


jonjecker76,

It looks like there is no communication to the CM11A.  Maybe double check the port and baudrate settings..

how would I check/configure the baud rate settings?
I went into the BIOS and ensured that the serial ports are inabled, end even tried different IRQs and everything.

Quote from: ddamron on February 09, 2008, 05:56:18 PM
jonjecker76,

It looks like there is no communication to the CM11A.  Maybe double check the port and baudrate settings..

Dan, any suggestions how to solve bad checksum issue:
10      02/10/08 21:18:38.769           Sending address with HouseCode=6, DeviceCode=6. <0x41802950>
10      02/10/08 21:18:38.769           Sending packet with HighByte=4, LowByte=66. <0x41802950>
10      02/10/08 21:18:38.769           Sending header with Checksum: 6a. <0x41802950>
10      02/10/08 21:18:42.677           Got response: 5a from CM11A. <0x41802950>
01      02/10/08 21:18:42.677           Bad checksum received (send:6a, recieved:5a)

I still can't get my CM11A to work with LinuxMCE..  I've reinstalled the device several times, but nothing is working! I've tried on both com1 and com2....

Here is a recent log...

Fri Feb 15 22:13:45 EST 2008 Restart
========== NEW LOG SECTION ==========
1 02/15/08 22:13:53 55 (spawning-device) Starting... 1
1 02/15/08 22:13:53 55 (spawning-device) Found /usr/pluto/bin/CM11A
10 02/15/08 22:13:53.132 Device: 55 starting.  Connecting to: localhost <0x2b6a5e585940>
10 02/15/08 22:13:53.159 Setting timeout for socket 4 to 20 <0x2b6a5e585940>
10 02/15/08 22:13:53.169 DCE Router asked us to wait--it's busy at the moment <0x2b6a5e585940>
10 02/15/08 22:13:54.223 Socket::SendMessage type 5 id 37 from 55 to -1000 <0x2b6a5e585940>
10 02/15/08 22:13:54.224 Requesthandler 0x62b170 (device: 55) runThread now running <0x41001950>
10 02/15/08 22:13:54.264 TranslateSerialUSB /dev/ttyS0 isn't serial usb <0x2b6a5e585940>
10 02/15/08 22:13:54.264 Using serial port: ttyS0. <0x2b6a5e585940>
10 02/15/08 22:13:54.264 Connect OK <0x2b6a5e585940>
05 02/15/08 22:13:54.264 Creating child 56 <0x2b6a5e585940>
10 02/15/08 22:13:54.264 Got CreateEvent for unknown type 37. <0x2b6a5e585940>
05 02/15/08 22:13:54.264 Note: Device manager has attached a device of type 37 that this has no custom event handler for.  It will not fire events. <0x2b6a5e585940>
10 02/15/08 22:13:54.264 Got CreateCommand for unknown type 37. <0x2b6a5e585940>
05 02/15/08 22:13:54.264 Note: Device manager has attached a device of type 37 that this has no custom handler for.  This is normal for IR. <0x2b6a5e585940>
10 02/15/08 22:13:54.264 Device Poll thread started. <0x41802950>
10 02/15/08 22:13:54.264 Child device: #56(A2)   Category:73 <0x41802950>
10 02/15/08 22:13:56.256 Receive string:  <0x41001950>
10 02/15/08 22:13:56.256 Received  0x62b170 device: 55 <0x41001950>
10 02/15/08 22:14:31.495 Receive string: MESSAGE 82             <0x41001950>
10 02/15/08 22:14:31.495 Received MESSAGE 82             0x62b170 device: 55 <0x41001950>
10 02/15/08 22:14:31.495 Received Message type 1 ID 760 from 0 to 55 (device: 55) resp 0 <0x41001950>
10 02/15/08 22:14:31.495 Could not find a handler for message - from 0 to 55 Type: 1 ID: 760 (device: 55) Command_Impl1 Dev #55 <0x41001950>
10 02/15/08 22:14:39.631 Receive string: MESSAGE 82             <0x41001950>
10 02/15/08 22:14:39.632 Received MESSAGE 82             0x62b170 device: 55 <0x41001950>
10 02/15/08 22:14:39.632 Received Message type 1 ID 760 from 0 to 55 (device: 55) resp 0 <0x41001950>
10 02/15/08 22:14:39.632 Could not find a handler for message - from 0 to 55 Type: 1 ID: 760 (device: 55) Command_Impl1 Dev #55 <0x41001950>


Can anyone help me?  There are tons of posts about the CM11A not working, and not one of them has been answered yet.

Sorry guys, I can't help with the CM11A...
I didn't write it..

I did however, update the Insteon PLM to support X10... If you're in NA, that's a much better solution.

Michael,

Have you tried to calculate the checksum?  the spec is out there..  I'd calculate it and see if it's the driver or the CM11A.

(compare your result with the log)

If you're a programmer, the CM11A source is in the svn.

All the best,

Dan

After a couple of weeks of frustration, I finally have it working.
What it boils down to is that the CM11A its self has a firmware problem that makes it lock up when you switch computers. To reset it, all you have to do is unplug it from the wall, unplug the serial cable, take the batteries out (keep them out, lmce doesn't need them) and let it sit at least 15 minutes. Plugged mine back in and it works as it should now.
I found this out here http://www.shed.com/ddt1.html (http://www.shed.com/ddt1.html) and it appears to be a common problem with these interfaces.

I added a troubleshooting section outlining these steps the the CM11 wiki

I have similar issue with CM12 but it help when  i move my CM12 in socket on other side of room. Probably something with electricity issue.

Thanks for the update and adding it to the wiki jondecker76.

grba, could it be that those outlets are on different phases?

jondecker76,

yes, thanks MUCH for that update!  That's info I didn't know...

Quote from: jondecker76 on February 20, 2008, 07:38:09 PM
After a couple of weeks of frustration, I finally have it working.
What it boils down to is that the CM11A its self has a firmware problem that makes it lock up when you switch computers. To reset it, all you have to do is unplug it from the wall, unplug the serial cable, take the batteries out (keep them out, lmce doesn't need them) and let it sit at least 15 minutes. Plugged mine back in and it works as it should now.
I found this out here http://www.shed.com/ddt1.html (http://www.shed.com/ddt1.html) and it appears to be a common problem with these interfaces.

I added a troubleshooting section outlining these steps the the CM11 wiki

Dude, thanks for finding this! Im moving to insteon (slowly)  but Im sure it will be a great boon for everyone with x10. We need more users to do this.

jondecker76:

I've just had a lightning BOLT hit me

started playing around with DCEGen and sql2cpp today..
*AMAZING*
while I'm soaking up all I can, I was comparing the CM11A driver to my dummy driver I created:

if I'm not mistaken, the CM11A driver IS BIDIRECTIONAL!!!!

BUT,

it looks like it ONLY LISTENS to HOUSE CODE 'A'.

I give you exhibit A.
in devicepoll.cpp Line 149:
   sbuff[6] = 0x61; /* hard coded house code A for monitoring, probably shouldn't be hard coded */

I was wondering if you could try this!

This is *GREAT* news...

see if it works!

All the best,

Dan

Dan-

I'm working on it now.. trying to get the checksum bug fixed as we speak :)

Quote from: jondecker76 on February 21, 2008, 08:44:59 AM
Dan-

I'm working on it now.. trying to get the checksum bug fixed as we speak :)

Excellent! Finally we'll get a 100% working CM11 interface :)

It may take a little while (I'm a bit rusty on my C++) but I had a good first night working on this. Most of the time so far has been spent commenting all the code so I can follow it better, as well as setting up a development environment (there are some really helpful guys on IRC - thanks for the help - you know who you are). I'm just now starting to make changes to the code and see where it gets me. I'll post back when I actually get somewhere

way tou go Jon!!

jon,

I'm sure you've found this, but the message.cpp file I believe is where the checksum is calculated..

HTH

Dan

Hey Guys:
Devicepoll.cpp Line 239, remove the '!'.
That fixes the polling! YAY

Tested and confirmed!

All the best,

Dan

Dan-

I found that too. Unfortunately I had to wrap up for the night and go to work (I'm working right now..)
Where I wanted to continue tomorrow is in Serial/SerialPort.cpp and take a look at CSerialPort::IsReadEmpty()
to make sure there wasn't a problem in there before removing the !
Anyways, good work! We were on the same track

Ok Jon, I've committed my change, and now I'm seeing everything coming in NO problem.

FYI, I had to change the monitoring house code to C (only device I had).  So if you look into that a bit closer, keep me posted.

Great Stuff!

Regards,

Dan

Dan

There should be no reson that I can see to change the Monitored house code from 0x06 (I'm assuming your talking about the hard-coded monitored house code in DevicePoll::SendClock()). The interface will receive on all house codes regardless of what the monitored house code is set to. The only time that function is called anyways is pretty much if the power goes out and comes back on, or when you first plug it in.

After a lot of reading, what the monitored house code appears to do is store the state of all devices for the specified house code. (So the CM11A has a 2-byte buffer, with the 16 bits representing on/off for all of the device code for the monitored house code). That way, when a power outtage occurs, the interface will send a timer request to the PC (0xA5) to resync the internal time clock, and set the house code to monitor states on.
After this point, if we send the CM11A a status request (0x8B), we can obtain the stored status of all the devices on the monitored house code.
(This is what I understand of it anyways, and I think i have a pretty good handle on it)

I don't believe LMCE uses this information anyways (though I haven't really looked yet), and even if it did, it would not be all that useful in the context of LMCE.

and on another note, I'm going to do some tests with motion sensors tomorrow :)

I'm at work and don't have much time to look into it, but I couldn't help but to check on the monitored house code thing...
if you look at cmllaconsts.h, the status request byte (0x8B) isn't defined, so without looking into it further I would say that LMCE doesn't even support it (and really doesn't need to)

Quote from: Zaerc on February 20, 2008, 08:00:13 PM

grba, could it be that those outlets are on different phases?

It's not it's on same phase. But work just fine and after 2-3 minutes start to switch on my lights. In other socket 3mtr from that one working fine.

dan -
I just got home after a 14 hour work night. I had a quick chance to test the change.
Polling does work - however there is still a problem. The latency of my X10 setup was about 1 second. Now, with the change, its anywhere from 5 to 12 seconds. I'm going to work on this today after I wake up - i need to get some sleep!

ok going to sleep for real this time..
X10 sensor causes and endless loop here:

do {
LoggerWrapper::GetInstance()->Write(LV_STATUS, "Reading the Upload Buffer Size...");

nread = serprt.Read((char*)&resp, 1, CM11A_READ_TIMEOUT);
LoggerWrapper::GetInstance()->Write(LV_STATUS, "got %x", resp);
} while (nread > 0 && resp == CM11A_INTERFACE_CQ);


I'm going to look at it when I get up.... Feel free to get a jump on this!

Quote from: ddamron on February 22, 2008, 01:56:05 AM
Hey Guys:
Devicepoll.cpp Line 239, remove the '!'.
That fixes the polling! YAY

Tested and confirmed!

All the best,

Dan

Cheers Dan,

Given the code below and your change this would infer that in logical/boolean terms somewhere in the pluto code FALSE is defined as being true  :o

bool CSerialPort::IsReadEmpty()
{
    Sleep(0);   
    return FALSE;
}

Does anyone know where FALSE is defined as if the above is correct then it makes reading code very difficult

NOS

Nosilla -

I chased that for a while too, but then I noticed this:

#ifdef WIN32


so there is another IsReadEmpth() method used by linux (look further down the page)

Quote from: jondecker76 on February 22, 2008, 06:06:13 PM
Nosilla -

I chased that for a while too, but then I noticed this:

Code Select Expand


#ifdef WIN32


so there is another IsReadEmpth() method used by linux (look further down the page)

Thanks,

I guess trying to read and edit source code on my TV is a bad idea  :-[

NOS

Don't feel bad - i didn't notice it until I did a debug statement in there!

We still have some work to do to get this interface working like it should

Yes although the key issue is now fixed so once the latency is resolved it should be quite usable  :)

NOS

Can you get on IRC?

I think the problem lies in IsReadEmpty()

I think I can see what is causing the latency..


if (serprt.IsReadEmpty()) {
unsigned char resp;
if(serprt.Read((char*)&resp, 1, CM11A_READ_TIMEOUT) != 0)
{


The if(serprt.IsReadEmpty) is checking to see if data is available to read.
Most of the time is should be empty. But by removing the "!", it is checking all the time for the most part.
Then it falls down to if(serprt.Read((char*)&resp, 1, CM11A_READ_TIMEOUT) != 0)
Here it tries to read the data (in the previous step we already found that it should be empty most of the time) that isn't there, until the CM11A_READ_TIMOUT is reached (15 seconds)
This is causing the delay I think.

I'm going to poke around in the IsReadEmpty() a bit more...

Yes you are correct a simple fix could be to create another constant called CM11A_POLL_TIMEOUT with a value of 500 and use this in the line you stated above although the fact that this routine is always called points to an error in the ser.IsReadEmpty() not correctly identifying if the RI indicator is being toggled so as you suggest that would be a better place to focus effort as the simple fix will increase CPU usage by the CM11A code.

Good Luck

NOS

@jondecker76

I have implemented a new function in serial.cpp named IsRngSet() which checks for the Ring Indicator as specified in the CM11A protocol definition.  By calling this function instead of IsReadEmpty() the CM11A code works properly with no other changes required.

The latency is approx 1 second for LinuxMce commands and externally trigered events are shown in the CM11A logs as expected.

I have only had one instance of the dreaded checksum error in the last hour after lots of testing so I am happy that the approach is a correct one, but still believe that the sendpacket() routine should also check for a 0x5A response and deal with it on the rare occasions that it crops up.

The function is listed below, you will also have to add a declaration in SerialPort.h have a try and let me know how you get on

/** Nosilla99 Added function IsRngSet() to check for incomming data from CM11A */
bool CSerialPort::IsRngSet()
{
int flags = 0;

pthread_mutex_lock( &d->mutex_serial );
int iRNG = ioctl( m_fdSerial, TIOCMGET, &flags );
pthread_mutex_unlock( &d->mutex_serial );

if( -1 == iRNG )
{
// bad serial device
return false;
}

if( !(flags & TIOCM_RNG) )
{
return false;
}

return true;
}


Best Wishes

NOS

Excellent Job!  I won't be able to help with testing until tomorrow as I am at work for another 14 hours - but it looks just like I expected it would after our talk on IRC.

***edited -there was a big error in my logic...****
I see what you are saying about dealing with the 0x5A from within sendPacket() now, and after looking at the source some more I agree. The easiest (and most direct) way of dealing with it would be to just totally discard any 0x5A polls (don't send the 0xC3 ACK either). The CM11A will send its 0x5A every second until we respond with the 0xC3 ACK, so just discarding them while in sendPacket() all together should be fine, as once we are finished with sendPacket(), the correct logic block will catch the 0x5A poll and deal with it accordingly. Once this is done, it should be 100% stable!

Great job once again!

What do you think about something like:

if(pport->Read((char*)&resp, 1, CM11A_READ_TIMEOUT) == 0) {
LoggerWrapper::GetInstance()->Write(LV_STATUS, "No response from CM11A device.");
return -1;
} else {
LoggerWrapper::GetInstance()->Write(LV_STATUS, "Got response: %x from CM11A.", resp);
if(resp == CM11A_CLOCK_REQ) {
LoggerWrapper::GetInstance()->Write(LV_STATUS, "CM11A requested clock SET UP", resp);
SendClock(pport);
return -1;
} else if(resp == CM11A_INTERFACE_CQ) {
//Do a log entry here maybe? Not really needed, but maybe a message like "Data ready to be received, we will deal with it after sending..."
return -1; //it will try again...
} else { 
if(resp != chksum) {
LoggerWrapper::GetInstance()->Write(LV_CRITICAL, "Bad checksum received (send:%x, recieved:%x).", chksum, resp);
return -1;
}
}
}

?


Once this is ironed out (shouldn't be long now) I'm going to dust off my CM15A (USB version) and see what we need to do to get it to work, and to get it to plug and play!

@jondecker,

unfortunately I believe we have to deal with any incomming data before the CM11A will allow us to send commands so the current CM11A logic needs recoding.

A dirty fix would be to carry out a poll of the CM11A interface in the SendPacket() function prior to issuing addresses and functions, if there is data waiting then we can read it and deal with it our just discard the event.

Discarding the event is a bad thing to do as it could have safety implications such as a security sensor being tripped, hence we probably need to completely re-work the logic.  I am going to see if I can find an RS232 breakout box as I also want to monitor the Ring Indicator to ensure it stays high when there is incomming data.

In terms of the CSerialPort::IsRngSet() it is generic and I only added a comment regarding the CM11A for my own documentation, but I will write a more general routine to check for any serial port status bits as requested.

Don't work too hard  ;)

Hopefully catch you later on IRC

NOS

Are you sure that you have to deal with incoming data before the CM11A will send commands? Have you tested this?
An easy way to test this is to change devicepoll.cpp so that the 0xC3 ACK is never sent (so that the 0x5A poll will transmit every second) once it receives data. Then, once in this state, try to send some commands.. If it works, then we are home free.

Also - by discarding, i just mean not responding to the 0x5A. We would just not respond to the poll until after we send our address/function. All of the data will still be there waiting - nothing would be lost, and the poll will continue to fire every 1 second until we do respond to it with the 0xC3 ACK. Therefore, if we can prove that we can send address/functions while the CM11A is doing its 0x5A poll, then this is the fix. If you don't get to it before me, i will test that part when I get home in an hour or two.

I also would like to know how long the RI stays high. My guess is that it will stay high until the CM11A receives the 0xC3 ACK from us, but it would be nice to know for sure

@jondecker

The problem is that unless you deal with the incomming data, you will not receive any valid checksum responses, I also know that after allowing the send requests to timeout i.e. fail the ring indicator is no longer set so we are definitely going to have to fix the CSerialPort::IsReadEmpty() function, although changing this could effect any other code which also uses this function so we will have to identify all other bits of software which call it  :(

I will try treating 0x5A as a valid checksum just to verify that the CM11A won't process requests if it has data waiting and let you know the result

NOS

0x5A is a valid checksum for x10 address header G1 ( (0x56+0x04)&0xFF)

ok, i'm just messing around..
But, will be interesting to hear your results!

@jondecker

I have finished testing the CM11A code and the my worst thoughts look to have come true

1. It is not possible to send commands to the CM11A if it has data waithin in its buffer to be processed

2. It is possible for it to flag that there is data waiting even when you are halfway through issuing commands to the CM11A

3.  The logic in the CM11A code is fundamentally flawed and needs a complete re-write

Basically before sending packets you must check to see if the CM11A has data waiting and if so you must do something with it, fortunately most of the code is fine it is just a logic problem so we will need to breakout the CM11A reading code from _Run() into a sub function and during sending packets if data is found to be waiting call the new sub function to process it.

I don't think there is an excessive amount of work required, just some restructuring of the code and fixing the CSerial::IsReadEmpty() function

On a positive note the current code using the ring indicator works well if you don't have things like motion detectors(it is these which are causing events to be received in the middle of sending commands from LinuxMCE i.e I wave the motion detector around and select lights on or off in the orbitor is a sure way to break things  ;D

NOS

I have now recoded  and fixed the logic problems with CM11A  :)

All testing has proved successful with none of the old 0x5A checksum problems which caused a failure in the code

I still need to amend the code to correctly fire off DCE messages where appropriate, although this is not a major issue as the polling never used to work  ;D

NOS

Quote from: nosilla99 on February 22, 2008, 05:49:28 PM

Quote from: ddamron on February 22, 2008, 01:56:05 AM
Hey Guys:
Devicepoll.cpp Line 239, remove the '!'.
That fixes the polling! YAY

Tested and confirmed!

All the best,

Dan

Cheers Dan,

Given the code below and your change this would infer that in logical/boolean terms somewhere in the pluto code FALSE is defined as being true  :o

Code Select Expand

bool CSerialPort::IsReadEmpty()
{
    Sleep(0);   
    return FALSE;
}

Does anyone know where FALSE is defined as if the above is correct then it makes reading code very difficult

NOS

Yes, it does.  I'm just starting in C++ and as such didn't dig into it.  I just used logging here and there to try to find out WHY it was ignoring the 5A.
After about 4 recompiles, i found that the logic for CSerialPort::IsReadEmtpy() is reversed...  and I'm not sure (yet) of the effects of changing that code.

For now, to get you guys going, that works.  When I learn more, I'll revisit this.

All the best,

Dan

Dan - its about knocked out now - Nosilla restructured the code - it wend beyond just the IsReadEmpty()..  We will let you know when all the changes are finished (on the last part right now)

@Nosilla
Its 3:20PM right now, I leave for another long night at work at 5:00PM. Send me a message if you get on before then - I think I have the sending of events fixed. If not, I'll share it with you tomorrow.

@jondecker,

I will let you figure that one out and await your results tomorrow, as I could not think of an elegant solution so I hope you have better luck than me  ;D

I hope you are earning good money doing 14hr shifts as it can't be healthy

Take Care

NOS

I'll share my results with you tomorrow after I wake up. I haven't fully tested it yet, but I'm quite sure it works as it should.

Also I got to thinking about the sendpacket() routine.. There are 3 cases I can see that will mess things up in its current state..
1) Sending an address where the lowByte =checksum-highByte (basically 0x56 - G1 house:unit code since the dim bits won't be set in this instance) will have an actual checksum of 0x5A
2) Sending a function where the lowByte = checksum-highByte will have an actual checksum of 0x5A(there are many situations where this could happen)
3) Sending an extended function the sum of the data bytes & 0xFF = checksum-highByte (though extended functions are not yet supported so it really isn't relavant here)

I have rewritten the logic to deal with these situations elegantly - i will share those changes with you tomorrow as well.

About work - yes, the shifts are long, but I only work 15 days each month (and the pay is great). Its a strange schedule, but I work 4 night shifts, then I'm off for 4 days, then I work 3 day shifts, then i'm off for 1 day, then I work 3 night shifts, then I'm off for 5 days, then I work 4 day shifts, then I'm off for 7 days..  then this 28 day rotation repeats forever..  just takes some getting used to!

Well spotted, once both sets of issues are resolved we should have a perfectly functioning CM11A handler.

I look forward to receiving your updates

Best Wishes

NOS

Guys,

Great work going on in here..

I hope you don't mind, I'm moving this thread over to the Development area.

Keep up the great work!

Dan

@ddamron

Thanks for the support, and  I thought this thread might get moved to developers  :)

@jondecker

I have finally got to the bottom of the events handling code so I am now happy that the code should function as expected.  It looks like the device_status information is held locally within the CM11A code and hence not passed back to decrouter for the purpose of updating floorplans (this is the bit I was struggling to understand).  DCERouter is only informed of external events if they refer to a security device                                                                                                                                                               such as a motion sensor.

I will not be around for a couple of days, but if you could investigate the possibility of updating floorplan items I believe that would complete the CM11A module, if we are lucky it may only require a few lines of code.

PS the error you experienced in debugging was caused as you were trying to display an item which does not exist within the container !

Feel free to update the trac ticket with the latest code as Dan is hopefully going to test our work shortly

Best Wishes

NOS

cool, I can chime in here..
What you need to do is simply update the state of the device.
ie if you receive a command via x10 to turn B3 on.. Figure out which device B3 is,
and send it a cmd192...

now, sending STATE is a bit trickier.
To send STATE information, ie B3 50%..
where B3 is device 88
send a command TO 88 FROM 88 cmd 184(SetLevel) yada yada yada
and When you Receive Command for Child, if the FROM == TO, IGNORE.

HTH,

Dan

Nice tips Dan - I will be working on this over the next couple of days. Should have this all wrapped up very soon!

Heh, not a problem, I'll help where I can..

I banged my head over that damn state problem for WEEKS...

now, here's the kicker,

Ideally, to communicate status changes/state changes, the child devices SHOULD send EVENTS..

Notice, I'm sending COMMANDS..

this is because there is no event for STATE.  and to make things even trickier, (at least in gsd) when you send, for example a EVENT ON, the state is changed accordingly.  HOWEVER, because of AVTranslation.cpp (I assume this is only related to GSD devices) when you try to send a COMMAND to change the state back, it gets ignored.

it's hard to explain, and even harder to make a truth table..

In a nutshell, the whole 'state' information needs a revamp.

(This is also associated to SHOWING state information on the Orbiter... as right now, it doesn't)

Dan-

I have done a lot of poking around the sources, and it seams to me that there is a state event:
EVENT_State_Changed_CONST defined in pluto_main

Looking at the lighting plugin however, shows:

RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::LightingCommand ), 0, 0, 0, DEVICECATEGORY_Lighting_Device_CONST, MESSAGETYPE_COMMAND, 0 );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::LightingFollowMe ), 0, 0, 0, 0, MESSAGETYPE_EVENT, EVENT_Follow_Me_Lighting_CONST );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::DeviceOnOff ), 0, 0, 0, 0, MESSAGETYPE_EVENT, EVENT_Device_OnOff_CONST );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::GetVideoFrame ), 0, 0, 0, 0, MESSAGETYPE_COMMAND, COMMAND_Get_Video_Frame_CONST );

So the EVENT_State_Changed_CONST isn't even supported..  It would be easy to add it to the lighting plugin though..


Anyways, got some good things done so far today...  I finally have floorplan objects updating to show the state of lights when an external xx10 remote is used to turn them on and off..

Hi guys,

Well done, it's great news about the status update events

Keep up the good work

NOS

as I posted the initial mantis for the 0x5A lock with pluto team, I feel ashamed that I could not contribute more so far (except for the ugly heyu workaround). If that helps, I would be more than happy to do some testing of the latest developments. Where can I get a snapshot for 0710b4 ? Is it in SVN or is there a precompiled version around  ?

thanks,
Sam

I built CM11A from the sources. But It works on strange manner. I don't see any messages in its log except those which are stored there during device initialization.  The lighting works but with a big delay - about 20 - 30 seconds after sending a command.

It'd be really good if somebody from developers share CM11A for i386 and AMD64 similar manner it's done for Media and generic plug-ins on the 0710 Beta4 known issues list.

P. S. Nice to see you again Sam :)

The fix was submitted about a month ago, but it never made it to beta 4 unfortunately. It is however in the svn.linuxmce.com/pluto/trunk. You could download the required files from there:
CM11A/devicepoll.cpp
CM11A/devicepoll.h
CM11A/cm11aconsts.h
Serial/SerialPort.cpp
Serial/SerialPort.h
Lighting_Plugin/Lighting_Plugin.cpp
Lighting_Plugin/Lighting_Plugin.h
pluto_main/Define_EventParameter.h

If you are running 64-bit, i will send you the binaries if you want them.

The fix is 100% stable, and extremely fast (fast for x10 anyways) - everything happens for me in well under a second. Also, I am using this in a house with around 100 active x10 modules (all light fixtures and outlets in the house are X10, as well as many sensors, plug-in modules, and inline modules.

I'm running 32 bits so I guess I'll have to compile it. Not sure how yet but I will figure it out.

thanks Jondecker76 !!!

Heres info on setting up a development environment: http://forum.linuxmce.org/index.php?topic=4718.0 (http://forum.linuxmce.org/index.php?topic=4718.0)

Heres the info you will need on where to get the changes, and what you need to recompile:http://forum.linuxmce.org/index.php?topic=4456.0 (http://forum.linuxmce.org/index.php?topic=4456.0)

Quote from: jondecker76 on March 21, 2008, 09:59:30 PM
The fix was submitted about a month ago, but it never made it to beta 4 unfortunately. It is however in the svn.linuxmce.com/pluto/trunk. You could download the required files from there:
CM11A/devicepoll.cpp
CM11A/devicepoll.h
CM11A/cm11aconsts.h
Serial/SerialPort.cpp
Serial/SerialPort.h
Lighting_Plugin/Lighting_Plugin.cpp
Lighting_Plugin/Lighting_Plugin.h
pluto_main/Define_EventParameter.h

If you are running 64-bit, i will send you the binaries if you want them.

The fix is 100% stable, and extremely fast (fast for x10 anyways) - everything happens for me in well under a second. Also, I am using this in a house with around 100 active x10 modules (all light fixtures and outlets in the house are X10, as well as many sensors, plug-in modules, and inline modules.

I understand why it doesn't work for me. I recompiled CM11A only. So, I should build Serial and Lighting_Plugin as well, right?

Michael

Yes, you must compile them too.
From /Serial run make, then copy the resulting libSerial.so to usr/pluto/lib
From Lighting_Plugin, run make so, then copy the resulting Lighting_Plugin.so to usr/pluto/bin

BIG THANKS to nosilla99 and jondecker76 for this awesome piece of work !!! I soo love opensource.
If you send me your address by PM, you get a belgian beer (and still waiting for the one from Michael)

It works indeed very well ! All activity on the X10 "bus" generated by remote controls is decoded properly and the x5 answers do not cause locks any more.

I thought I would share the binary for x86 to save some time for others:
http://www.k-net.eu.org/lmce/cm11a-x86.tgz (http://www.k-net.eu.org/lmce/cm11a-x86.tgz)

Sam

thank you caiman - if you don't mind, I may post your x86 binaries along with my 64 bit binaries to the "known problems" area on the wiki along with the other workarounds!

Glad to hear its working well for you

Jon

It'd be really helpful, Jon! Thanks to you, nosilla99 and Sam for fixing and building a correct binaries for CM11A interface! Well done!

you guys rock ;)

best regards,
Hari

What Hari said :)

Hi jondecker,

Did you start looking at the CM15A usb controller integration yet ?

Hello there,

let me introduce myself: my name is Xurde, I´m from Asturias (Spain) and I´m doing my Final Project with X10. I got stuck at some point, and from what I´ve read in this post I think (and hope) you can help me. My project is about sending X10 signals from the PC, through CM11 interface. The problem is I´m receiving the "evil" 0x5A and so I can´t send any signal. I tried to send the ACK 0xC3 but it doesn´t work!  I've read your post (to be honest I didn´t read it entirely) and I saw you solved it, but I didn't get How. I´d be really happy if you could help me, thanks in advance,

Xurde Duran

are you using 0710? X10 was broken on 0704, but fixed in 0710

Hi jondecker76,

actually I´m developing the program with Windows (big Mistake), anyway I´ve just realized I was interpreting the signal in a very bad way, I´m receiving 0xA5, no 0x5A, what means a power fail! A solved it by sending 0xfb and updating the clock.

Anyway, thanks, if you guys still need anything, just write down in this post.

Gracias!

The biggest thing we learned about the CM11A while tearing into it is that there exists some hardware flaws that make making a completely bulletproof driver extremely difficult.

For example, the CM11A can and will receive PLM data even during the middle of sending data. With a shared rx/tx buffer, you can see how this could get ugly. Before sending any data, queue it up and make sure that the serial ring is not indicating that data is coming in, and double check to make sure there isn't data already waiting to be processed. You can't fix the hardware flaw, but the more you can do to eliminate such collisions, the more stable things will be.

Another thing that can get you is that there are certain situations where 0x5A is a checksum, so be sure to include logic in your 0x5A handling that copes with situations where you are actually expecting it!

Hey Jon,
Thanks and great work!
Could you please send me the binaries (64bit) for CM11A that you've complied?
Thanks,
Stallione

Hi Jon:

Due to a kernel problem in 710 and my core computer, I had to go to 704, so I have broken CM11A as well.
Can you send me the X86 binaries or point me to where I can download them for use on my core?

Do you know if anyone has go the PLC (rs232 version) working yet?

Happy New Year.