From: David M. <dm...@ci...> - 2005-12-05 02:04:24
|
Neil Cherry <ncherry <at> comcast.net> writes: > > David Mark wrote: > > Neil Cherry <ncherry <at> comcast.net> writes: > > > >> Neil Cherry wrote: > >>> David J Mark wrote: > >>>> "A1AJ" is what is passed to the controller module, which converts it > >>>> to whatever format the device expects. This is by convention. For > >>>> more information, see X10_Items.pm. > >>> Big THANKS! That's what I needed to know. I'll go poking around in > >>> X10_Items.pm and see what I need. I'm playing with the PowerLinc V2 > >>> and I wan to get it running. I've only got a few days and it's back > >>> to the book. > >> Well it looks like I won't get this finished now (grr!). But let me > >> correct the info David sent. It's sending either "A1" or "AJ" not > >> "A1AJ" (all at once). The end outcome is that "A1" and "AJ" are > > > > I am not sure what you mean. It has to send both. Perhaps it is too calls > > (though I don't think so), but A1 ON is "A1AJ" when coming in from the cm11 > > module and that is what is passed to send it. Sending one or the other won't > > work. > > From Dan Sutther's Interface Communication Protocol (for the CM11A): > > PC Interface Description > 0x04,0x66 Address A1 > 0x6a Checksum ((0x04 + 0x66)&0xff) > 0x00 OK for transmission. > 0x55 Interface ready. > > The above appears to say that you can send the 'halves' and the > CM11A will send it (the above is A1 A2 A Dim to ~72%. So that's > good to know. I think that means we may be saying the same > thing differently. Yes. A1 addresses the device and AJ turns on all addressed devices on house code A. We are talking about two different things. I was referring to the data passed from X10_Items to the cm11 module, not from the cm11 module to the serial port (which is sent in two packets.) > > Here's the send routine for the CM17A, Firecracker > (~mh/lib/site/ControlX10/CM17.pm): > > > Before I thought that the CM15A stuff was incorrect but after finding > this I'm not so certain. BTW, I've removed the code to make it easier > to read. If it expects "A1J" or sends "A1J" from mh, then it is wrong. > > OK, my head is spinning! I've tried to search through the X10_Items.pm > but I can't figure that out. The sub set routine ends up calling > > $self->SUPER::set($state, $set_by); > > Which ends up in Serial_Item.pm where I found these comments (part of > the sub set routine): > > sub set { > > which either calls: > > sub send_serial_data { > > or it calls: > > sub send_X10_data { > > Where we we get this mess : > > if ($interface eq 'cm11') { > # Standard 1-cm11 code > # cm11 wants individual codes without X > } > > elsif ($interface eq 'bx24') { > &X10_BX24::SendX10($serial_data); > } > > elsif ($interface eq 'lynx10plc') { > # marrick PLC wants XA1AK > } > elsif ($interface eq 'cm17') { > # cm17 wants A1K, not XA1AK Oops. I never messed with the CM17 module (just the CM11), but I imagine it needs some work. It clearly is causing a mess at the moment... > > So the answer is: 'I'm confused!'. Looks like it depends. What we > need is to define an interface to a device. The problem is that everybody wrote a slightly different version and then mh was hacked to support all of the variations (instead of enforcing the original standard.) > > So to properly add an interface we need to modify mh, modify > Serial_Item.pm and create an interface.pm file. This is very > ugly! What am I going to do when I add an Insteon_Item to all > this? > Only if the controller module is written to accept or send non-standard strings. Other than STATUS commands, the cm11 module sends a house code with every command. If you understand the next layer (between the firmware and the controller module), I am sure you will agree that commands without house codes are ambiguous and require the controller module to guess about which house code is implied. |