From: Neil C. <nc...@co...> - 2005-11-30 19:13:34
|
When an X10 command gets sent to a device it usually calls a routine such as send_cm11a. What would the X10 string look like is I did this: $garage_light = new X10_Item('A1', ); set $garage_light ON; Would it be A1J or A1ON or A1AON of A1 then AON .... ? -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: Scott K. <sc...@sc...> - 2005-12-01 00:13:33
|
Neil, I assume you are doing research for your INSTEON driver project. I just got my developer kit yesterday and am trying to play catch-up right now and have been playing with both the IDE and Device Manager w.r.t X10. Not sure if it helps, but I finally am able to control my X10 devices using both ways (I can't get Device Manager to control them with sendX10 or sendX10raw commands). So, here is what works to drive my test device on K6: K6: 02 40 01 65 00 01 FF 60 39 02 46 01 66 80 F7 KON: 02 40 01 65 00 01 FF 67 32 02 46 01 66 88 FF KOFF: 02 40 01 65 00 01 FF 66 33 02 46 01 66 88 FF Magically, when I paste these into the programs, my device turns on and off EVERY SINGLE TIME, unlike from the CM11, which currently has about a 15% success rate :( Now I just wish I had a signal strength meter to compare them... For my next trick, I am going to try your iplcd driver and see if these commands work from there as well... on 11/30/2005 2:13 PM Neil Cherry carved the following into a picnic table: >When an X10 command gets sent to a device it usually calls a >routine such as send_cm11a. What would the X10 string look >like is I did this: > >$garage_light = new X10_Item('A1', ); > >set $garage_light ON; > >Would it be A1J or A1ON or A1AON of A1 then AON .... ? > > > -- Scott Knight sc...@sc... |
From: Neil C. <nc...@co...> - 2005-12-01 01:06:02
|
Scott Knight wrote: > Neil, > > I assume you are doing research for your INSTEON driver project. I just > got my developer kit yesterday and am trying to play catch-up right now > and have been playing with both the IDE and Device Manager w.r.t X10. > Not sure if it helps, but I finally am able to control my X10 devices > using both ways (I can't get Device Manager to control them with sendX10 > or sendX10raw commands). So, here is what works to drive my test device > on K6: > > K6: > 02 40 01 65 00 01 FF 60 39 > 02 46 01 66 80 F7 > > KON: > 02 40 01 65 00 01 FF 67 32 > 02 46 01 66 88 FF > > KOFF: > 02 40 01 65 00 01 FF 66 33 > 02 46 01 66 88 FF > > Magically, when I paste these into the programs, my device turns on and > off EVERY SINGLE TIME, unlike from the CM11, which currently has about a > 15% success rate :( Now I just wish I had a signal strength meter to > compare them... > > For my next trick, I am going to try your iplcd driver and see if these > commands work from there as well... Just type A1AON and the X10 will turn on A1. B1BON and X10 turns B1 on (etc.). If you want to try the above it would be: !c0240650010FF6039 !c 02 46 01 66 80 F7 !c 02 40 01 65 00 01 FF 67 32 !c 02 46 01 66 88 FF To turn K1 on. iplcd doesn't care about white space. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: David J M. <dma...@ho...> - 2005-11-30 19:33:00
|
"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. ----- Original Message ----- From: "Neil Cherry" <nc...@co...> To: <mis...@li...> Sent: Wednesday, November 30, 2005 2:13 PM Subject: [mh] What do valid X10 strings look like? > When an X10 command gets sent to a device it usually calls a > routine such as send_cm11a. What would the X10 string look > like is I did this: > > $garage_light = new X10_Item('A1', ); > > set $garage_light ON; > > Would it be A1J or A1ON or A1AON of A1 then AON .... ? > > -- > Linux Home Automation Neil Cherry nc...@li... > http://www.linuxha.com/ Main site > http://linuxha.blogspot.com/ My HA Blog > http://home.comcast.net/~ncherry/ Backup site > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Neil C. <nc...@co...> - 2005-12-01 01:45:23
|
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. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: Neil C. <nc...@co...> - 2005-12-04 18:15:34
|
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 being sent but the interface only gets one at a time. I looked at the CM11A & CM17A interfaces. I wonder how the CM15A interface works because it thinks it sending "A1J" (???). I've also looked at many other interfaces and most seem to be just sending data to the device. More work to follow. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: David M. <dm...@ci...> - 2005-12-04 19:41:14
|
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. > being sent but the interface only gets one at a time. I looked at > the CM11A & CM17A interfaces. I wonder how the CM15A interface works > because it thinks it sending "A1J" (???). I've also looked at many That means the CM15A has an issue. "A1J" is wrong. CM11 breaks its own convention with the STATUS commands. It does "A1STATUSON" instead of "A1ASTATUSON." Luckily mh interpets it as "A1ASTATUSON" under most circumstances. > other interfaces and most seem to be just sending data to the > device. More work to follow. > |
From: Neil C. <nc...@co...> - 2005-12-04 21:48:35
|
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. 0x04,0x6e Address A2 0x72 Checksum ((0x04 + 0x6e)&0xff) 0x00 OK for transmission. 0x55 Interface ready. 0x86,0x64 Function: A Dim 16/22*100% 0xe0 Incorrect checksum. 0x86,0x64 Function re-transmission 0xea Checksum ((0x86 + 0x64)&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. Here's the send routine for the CM17A, Firecracker (~mh/lib/site/ControlX10/CM17.pm): sub send { my ($serial_port, $house_code) = @_; my ($house, $code) = $house_code =~ /(\S)(\S+)/; # skipped the dim processing statements my $data2 = $table_dcodes{$code}; And here's the send routine for the CM11A (~mh/lib/site/ControlX10/CM11.pm) : my ($serial_port, $house_code) = @_; # I removed a debug statement my ($data_snd, $checksum) = &format_data($house_code); return unless $data_snd; I've taken the liberty to remove a few statements, but they seem to be saying that they expect the X10 command from Misterhouse to be in the format of A1 or AJ but not A1AJ (i.e. at the same time). >> being sent but the interface only gets one at a time. I looked at >> the CM11A & CM17A interfaces. I wonder how the CM15A interface works >> because it thinks it sending "A1J" (???). I've also looked at many > > That means the CM15A has an issue. "A1J" is wrong. CM11 breaks its own > convention with the STATUS commands. It does "A1STATUSON" instead > of "A1ASTATUSON." Luckily mh interpets it as "A1ASTATUSON" under most > circumstances. 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. 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 } elsif ($interface eq 'homevision') { # homevision wants XA1AK } elsif ($interface eq 'homebase') { # homebase wants individual codes without X } elsif ($interface eq 'stargate') { # Stargate wants individual codes without X } elsif ($interface eq 'houselinc') { # houselinc wants XA1AK } elsif ($interface eq 'marrick') { # marrick wants XA1AK } elsif ($interface eq 'ncpuxa') { # ncpuxa wants individual codes with X } elsif ($interface eq 'weeder') { # Weeder table does not match what we defined # in CM11,CM17,X10_Items.pm # - Dim -> L, Bright -> M, AllOn -> I, AllOff -> H # Allow for +-xx% } elsif ($interface eq 'wish') { # wish wants individual codes without X } else { print "\nError, X10 interface not found: interface=$interface, data=$serial_data\n"; } So the answer is: 'I'm confused!'. Looks like it depends. What we need is to define an interface to a device. 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? -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
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. |
From: David H, L. Jr. <dh...@co...> - 2005-12-05 07:48:30
|
David Mark wrote: > >>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. > > You have to modify Serial_Item.pm to add the interface. The addition might not be significant, but you still have to do it. You have to modify mh in several other places to create the interface object, to recognize it in X10 item files, or X10_item commands, and to be able to assign a port to it in mh.ini presuming that it needs a configurable port. And finally you have to create an interface.pm that parses all the legitimate command strings and outputs the appropriate results to whatever controller you are using. Since the command strings MH uses map fairly directly to the X10 wire protocol, it is probable that most interfaces will have something close to a 1-1 mapping between the MH X10 strings and whatever communications thay want. >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. > > > This is just X10 battieness. Granted that X10 was implimented in the 70's - I do nto think PAL's existed yet and certainly the smallest available CPU was too complex and too costly. But still the wire protocol outputs every bit twice and in essence the house code 4 times 4 every command. Even adding partity and the most simple of ACK's from the device would have radically improved its robustness and reduced the redundancy. Regardless, the fact that the House code is repeated on the Wire does not mean it needs repeated in the ASCII command string MH uses. Utlimately, the messages have two parts - a target and a command. The MH X10 interface protocol, sort of diveds that way, but the housecode is only relevant in the command, because somewhere just before hitting the wire something is going to have to add the house code to the command. At the upperlevels it is only confusing and makes parsing harder, as does the odd mix of overlapping commands as strings, commands as singles letters ... I know why X10 has a plethora of means to do a dim, but why does the message stream have to deal with that? There is plenty of bandwidth between MH and the interface, Create a single DIM command, pass the device type, and let the interface figure out what the correct X10 way to dim that specific device is. Let me applogize somewhat for the rant above - I am just surely from trying to massage all the idiosyncracies of the MH ASCII X10 stream into a TI103 interface. |
From: David M. <dm...@ci...> - 2005-12-05 11:05:01
|
David H, Lynch Jr. <dhlii <at> comcast.net> writes: > > David Mark wrote: > > > > This is just X10 battieness. Granted that X10 was implimented in the > 70's - I do nto think PAL's existed yet and > certainly the smallest available CPU was too complex and too costly. > But still the wire protocol outputs every bit twice and in essence the > house code 4 times 4 every command. > Even adding partity and the most simple of ACK's from the device would > have radically improved its robustness and reduced the redundancy. Yes. I am sure. > > Regardless, the fact that the House code is repeated on the Wire does > not mean it needs repeated in the ASCII command string MH uses. I realize that. It is just a convention. The problem is if controller modules allow your to sent "A1" and then "J", they must assume that the second command goes with the previously received house code, etc. As noted below, the whole thing is a bit of a mess. I have a complete rewrite of the mh parse code that I am going to drop in one of these days. Trouble is that it relies on several other changes I have made. If you really want to clean up the X10 stuff: 1. Change definition of house code O and P commands (eg AO, AP) in X10_Items.pm. They are currently translated to ON and OFF, while the J and K are commented out. This is a strange twist. 2. Fix cm11 STATUS commands as mentioned before (new parse routine will not work with A1STATUS) 3. Fix all other controller modules that send and receive A1J, etc. If we can get all of that fixed in the distribution, I will submit the new parse code... > Utlimately, the messages have two parts - a target and a command. The MH > X10 interface protocol, sort of diveds that way, but the housecode is > only relevant in the command, because somewhere just before hitting the > wire something is going to have to add the house code to the command. At > the upperlevels it is only confusing and makes parsing harder, as does > the odd mix of overlapping commands as strings, commands as singles > letters ... Yes it is a mess. > I know why X10 has a plethora of means to do a dim, but why does the > message stream have to deal with that? It shouldn't. The dimming is the messiest and most confusing part of the main parse code. This is compounded by each controller having its own way of sending in levels. It makes it really impossible to reliably track the levels of the old lamp modules. > There is plenty of bandwidth between MH and the interface, Create a > single DIM command, pass the device type, and let the interface figure > out what the correct X10 way to dim that specific device is. > > Let me applogize somewhat for the rant above - I am just surely from > trying to massage all the idiosyncracies of the MH ASCII X10 stream into > a TI103 interface. I understand completely. I did a lot of work on the cm11 and w800rf modules. The latter hasn't been released as it works slightly differently than the original. Might have to make it a new module or something. I found the current version of that one to be impossible, but there are people using it. > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/? group_id=1365 > > |
From: Neil C. <nc...@co...> - 2005-12-05 17:33:04
|
OK, I feel like an idiot! I now have the PowerLinc V2 properly working with MH as transmit only. Sorry but I have to get back to writing the book (3 chapters on Wireless & networking this month, 6 chapters on MH next month :-). I may take a break and try to attack the read portion of the iplcs module. If anyone wants to work with my code its here: http://www.linuxha.com/athome/common/iplcd/iplcs.pm Follow the directions at the top of the file on what to change to use the module. The code is real ugly (stolen from CM11.pm, some USB left in there (sorry I got confused) and lots of junk). Bruce what do you need from me to have this added to MH? Hey, how do I add iplcs to the debug section? And last but not least, I want to help work on the rewrite of the device interface. Some kind of standard would be great. I'll keep reading the list while writing. MH has become my central HA app and I want to make it better. I know it can be done I'm just not sure how to do it. And a big thanks to everyone that helped point me in the right direction. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: Neil C. <nc...@co...> - 2005-12-05 22:36:48
|
Ok, I lied a little ... Does anyone know how to get MH to read from a newly added device? I added a read routine but it never seems to get called. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: David N. <dno...@ya...> - 2005-12-06 07:40:30
|
Not enough David's in this conversion, so I thought I'd chime in :) Actually, I wrote the Ocelot module so I've thought about these issues before. > David H, Lynch Jr. <dhlii <at> comcast.net> writes: > >> >> David Mark wrote: >> >> Regardless, the fact that the House code is repeated on the Wire does >> not mean it needs repeated in the ASCII command string MH uses. Yes it does. > I realize that. It is just a convention. The problem is if controller > modules allow your to sent "A1" and then "J", they must assume that the > second > command goes with the previously received house code, etc. As noted > below, > the whole thing is a bit of a mess. I have a complete rewrite of the mh > parse > code that I am going to drop in one of these days. Trouble is that it > relies > on several other changes I have made. If you really want to clean up the > X10 > stuff: The housecode of the first command does not always match the one in the second. Often, weird combinations of X10 commands are used to access special features of switches, thermostats and other X10 devices. If a user wants to send XA1BK, let them. > 1. Change definition of house code O and P commands (eg AO, AP) in > X10_Items.pm. They are currently translated to ON and OFF, while the J > and K > are commented out. This is a strange twist. Actually, O and P are for sending ALL LIGHTS ON and ALL UNITS OFF, respectively. That is why it's in the section that applies to the whole housecode. > 2. Fix cm11 STATUS commands as mentioned before (new parse routine will > not > work with A1STATUS) You should allow for XA1BSTATUS, since the X10 protocol allows for it and someone might want to do it. > 3. Fix all other controller modules that send and receive A1J, etc. The reason the CM17 firecracker module omits the second housecode is that the wireless X10 protocol combines the housecode, unit, and function in one command. It's imposible to send XA1BK via RF. > If we can get all of that fixed in the distribution, I will submit the new > parse code... Are your changes for sending or receiving? >> Utlimately, the messages have two parts - a target and a command. The MH >> X10 interface protocol, sort of diveds that way, but the housecode is >> only relevant in the command, because somewhere just before hitting the >> wire something is going to have to add the house code to the command. At >> the upperlevels it is only confusing and makes parsing harder, as does >> the odd mix of overlapping commands as strings, commands as singles >> letters ... > > Yes it is a mess. It's just X10, not a misterhouse complexity. >> I know why X10 has a plethora of means to do a dim, but why does the >> message stream have to deal with that? > > It shouldn't. The dimming is the messiest and most confusing part of the > main > parse code. This is compounded by each controller having its own way of > sending in levels. It makes it really impossible to reliably track the > levels > of the old lamp modules. Aren't there just two ways to do dimming? Relative and absolute (preset dim). That is all my Ocelot module supports. I realize only some X10 devices support absolute dimming, and there are a couple ways they have implemented it, but that should be handled higher up by the object for that device. >> There is plenty of bandwidth between MH and the interface, Create a >> single DIM command, pass the device type, and let the interface figure >> out what the correct X10 way to dim that specific device is. The specific dim command for a particular X10 device should be determined higher up by the object module for that device. All interface modules should support the same set of commands. >> Let me applogize somewhat for the rant above - I am just surely from >> trying to massage all the idiosyncracies of the MH ASCII X10 stream into >> a TI103 interface. > > I understand completely. I did a lot of work on the cm11 and w800rf > modules. > The latter hasn't been released as it works slightly differently than the > original. Might have to make it a new module or something. I found the > current version of that one to be impossible, but there are people using > it. My module accepts for sending a housecode followed by either: A unit code 1-9, A-G An X10 function J, # aka ON K, # aka OFF L, # aka Bright M, # aka Dim O, # aka All Lights ON P, # aka All Units OFF ALL_OFF, # aka All Units OFF, reported as P on receive ALL_ON, # aka All Lights ON, reported as O on receive ALL_LIGHTS_OFF, # reported as P on receive EXTENDED_CODE, # posibly ambiguous because E is valid unit HAIL_REQUEST, HAIL_ACK, PRESET_DIM1, # aka Preset Dim 0 EXTENDED_DATA, # posibly ambiguous because E is valid unit STATUS_ON, STATUS_OFF, STATUS, PRESET_DIM2, # aka Preset Dim 1 Relative dim n-times +/-## (I think percentages are converted to n-times by X10_Item) Leviton and LM14 style preset dim &P# (this is a special function on the Ocelot. I think it's an extended code X10 command) see http://www.geocities.com/ido_bartana/toc.htm David |
From: David H. L. Jr. <dh...@dl...> - 2005-12-06 20:37:38
|
> > The housecode of the first command does not always match the one in the > second. Often, weird combinations of X10 commands are used to access > special features of switches, thermostats and other X10 devices. If a > user > wants to send XA1BK, let them. But that is my whole point - the user does NOT want to send XA1BK. The user wants to Turn on a widget or Dim it or ask it something. The Command the users sends could just as easily be "DIM Christmas_tree 50%" > > >> 3. Fix all other controller modules that send and receive A1J, etc. > > The reason the CM17 firecracker module omits the second housecode is that > the wireless X10 protocol combines the housecode, unit, and function > in one > command. It's imposible to send XA1BK via RF. And again that is something that should be handled by the module. My point is that the message going to the module should be the same for all modules. The module is responsible for sending the correct information to the device in whatever format the device needs, and for reporting an error when it receives a message that is not valid for it - regardless of whether that same message may be valid for other modules. > > It's just X10, not a misterhouse complexity. But MH has chosen to reflect that mess. There is an expectation by people writing 'device drivers" etc. that they have to address the idiosyncracies of the device. but the idiosyncracies are not supposed to be on both sides. What if you were developing disk controller drivers for windows or linux and the OS decided that it was going to talk differently to each driver. > > Aren't there just two ways to do dimming? Relative and absolute (preset > dim). That is all my Ocelot module supports. I realize only some X10 > devices support absolute dimming, and there are a couple ways they have > implemented it, but that should be handled higher up by the object for > that > device. I think there are atleast 4 ways to dim a device, and I beleive only only the basic X10 relative dimming is guaranteed to work on all devices. But working that out should be the job of the controller module. That does require that CM11.pm or whatever needs to know the device it is talking to or it means that you can only use the more limited DIM/BRT commands for everything. > > The specific dim command for a particular X10 device should be determined > higher up by the object module for that device. All interface modules > should > support the same set of commands. And that is where we disagree. Among other things I do nto think there is any code in MH anywhere to determine or track the device type anyway. Atleast there is no way to distingush between 2way devices and devices that support extended codes or preset dims > > My module accepts for sending a housecode followed by either: > > A unit code 1-9, A-G > > An X10 function > J, # aka ON > K, # aka OFF > L, # aka Bright > M, # aka Dim > O, # aka All Lights ON > P, # aka All Units OFF > ALL_OFF, # aka All Units OFF, reported as P on receive > ALL_ON, # aka All Lights ON, reported as O on receive > ALL_LIGHTS_OFF, # reported as P on receive > EXTENDED_CODE, # posibly ambiguous because E is valid unit > HAIL_REQUEST, > HAIL_ACK, > PRESET_DIM1, # aka Preset Dim 0 > EXTENDED_DATA, # posibly ambiguous because E is valid unit > STATUS_ON, > STATUS_OFF, > STATUS, > PRESET_DIM2, # aka Preset Dim 1 > > Relative dim n-times +/-## > (I think percentages are converted to n-times by X10_Item) I did something similar in the TI103.pm I just submitted. But I handled the "String commands" EXTENDED_CODE, ALL_ON, ... by preprocessing those strings to a completely unique value avoiding having to deal with whether "E" is a unit or the begining of "EXTENDED_CODE" I do not know how MH handles percentages. The test_cm11.pl command sends them so I made TI103.pm convert them. At this point TI103.pm reliably parses everything that the test_cm11.pl test routine sends. It reports errors and success exactly as expected. Whether it sends the right stuff to the TI103 for every possible input, and whether it handles receives correctly are completely different issues, but the code is pretty clean and easy to understand, so adding, altering or fixing the transmissions should be easy. Also as the TI103 is an ASCII device converting text to bits itself unlikely most other X10 controllers. Though I am not sure I am completely happy with its ASCII protocol, it would still be a significant improvement over the normal X10 ASCII passed to the driver modules. It is easily parseable and unambiguous. Though ACT's TI103 documentation is extremely terse. It took me 3 days to figure out extended commands. |
From: Neil C. <nc...@co...> - 2005-12-07 20:53:47
|
Again I'm back to losing my mind! I now have the check_for_data correctly parsing the X10 data. But how do I return that data to MH so that it things like $garage are set accordingly? I've checked the others and I can't figure this out. I want my PowerLinc V2 to completely replace the CM11A. So far I can't see how MH reads from my device. Am I being stupid and missing the obvious? -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: Neil C. <nc...@co...> - 2005-12-07 21:33:36
|
Neil Cherry wrote: > Again I'm back to losing my mind! I now have the check_for_data > correctly parsing the X10 data. But how do I return that data to > MH so that it things like $garage are set accordingly? > > I've checked the others and I can't figure this out. I want my > PowerLinc V2 to completely replace the CM11A. So far I can't see > how MH reads from my device. Am I being stupid and missing the > obvious? As usual, I found the answer, but only after I posted the question! What I needed for X10 to listen to my PowerLinc V2 was for it to finish with a call to &main::process_serial_data. Sorry about that. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: David M. <dm...@ci...> - 2005-12-07 05:53:45
|
David Norwood <dnorwood2 <at> yahoo.com> writes: > > Not enough David's in this conversion, so I thought I'd chime in :) > Actually, I wrote the Ocelot module so I've thought about these issues > before. > > > David H, Lynch Jr. <dhlii <at> comcast.net> writes: > > > >> > >> David Mark wrote: > >> > >> Regardless, the fact that the House code is repeated on the Wire does > >> not mean it needs repeated in the ASCII command string MH uses. > > Yes it does. > > > I realize that. It is just a convention. The problem is if controller > > modules allow your to sent "A1" and then "J", they must assume that the > > second > > command goes with the previously received house code, etc. As noted > > below, > > the whole thing is a bit of a mess. I have a complete rewrite of the mh > > parse > > code that I am going to drop in one of these days. Trouble is that it > > relies > > on several other changes I have made. If you really want to clean up the > > X10 > > stuff: > > The housecode of the first command does not always match the one in the > second. Often, weird combinations of X10 commands are used to access > special features of switches, thermostats and other X10 devices. If a user > wants to send XA1BK, let them. > > > 1. Change definition of house code O and P commands (eg AO, AP) in > > X10_Items.pm. They are currently translated to ON and OFF, while the J > > and K > > are commented out. This is a strange twist. > > Actually, O and P are for sending ALL LIGHTS ON and ALL UNITS OFF, > respectively. That is why it's in the section that applies to the whole > housecode. I know. But they are attached to "on" and "off" (which are J and K.) They need their own tokens (eg "allon", "alloff") so that you can create an X10 item like "A", which has states: "AJ", "AK, "AO", "AP." This is necessary to support controllers that send "AJ", etc. without a device prefix (implies all currently addressed devices.) > > > 2. Fix cm11 STATUS commands as mentioned before (new parse routine will > > not > > work with A1STATUS) > > You should allow for XA1BSTATUS, since the X10 protocol allows for it and > someone might want to do it. You have to for the templincs. That is another reason why A1STATUS, etc. is invalid. > > > 3. Fix all other controller modules that send and receive A1J, etc. > > The reason the CM17 firecracker module omits the second housecode is that > the wireless X10 protocol combines the housecode, unit, and function in one > command. It's imposible to send XA1BK via RF. I still say pass and receive in A1AJ form so as not to obscure the mh parse routine further. > > > If we can get all of that fixed in the distribution, I will submit the new > > parse code... > > Are your changes for sending or receiving? I rewrote the entire section of mh that receives and matches X10 strings. The main improvement is that it handles mutliple commands bunched together. Like C2CJA1ASTATUSONF1FK, etc. Once in a while I see things like this show up as unmatched. There was some really strange stacking of dim commands too. Some things were removed from the mh layer and left to X10_Items and vice versa. All in all, the new one is a much easier read for future developers. I should note that for all its benefits, I am not using it here. I just don't have the time to test a new X10 engine and have lost interest in keeping the logging 100% accurate (won't happen with X10 anyway.) The version I use here is only slightly modified from the distribution. At this point, I know all of its quirks and just live with them. I didn't do much (if anything) to the sending portion of mh. I have made additional changes to cm11's send routine. The hack concerning the previously addressed device has been fixed (so it is no longer a hack.) As I recall, it was using a static variable to hold the last device and then tacking it on to status commands. > > >> Utlimately, the messages have two parts - a target and a command. The MH > >> X10 interface protocol, sort of diveds that way, but the housecode is > >> only relevant in the command, because somewhere just before hitting the > >> wire something is going to have to add the house code to the command. At > >> the upperlevels it is only confusing and makes parsing harder, as does > >> the odd mix of overlapping commands as strings, commands as singles > >> letters ... > > > > Yes it is a mess. > > It's just X10, not a misterhouse complexity. Not exactly. Mh and the various controller modules introduce a ton of complexity (at least from my experience with the above-mentioned routines.) > > >> I know why X10 has a plethora of means to do a dim, but why does the > >> message stream have to deal with that? > > > > It shouldn't. The dimming is the messiest and most confusing part of the > > main > > parse code. This is compounded by each controller having its own way of > > sending in levels. It makes it really impossible to reliably track the > > levels > > of the old lamp modules. > > Aren't there just two ways to do dimming? Relative and absolute (preset > dim). That is all my Ocelot module supports. I realize only some X10 > devices support absolute dimming, and there are a couple ways they have > implemented it, but that should be handled higher up by the object for that > device. Yes and no. There are multiple ways to tell mh to dim. At least one is cm11- specific. In short, L and M, +n, -n and the standard preset dims (&P) plus the cm11 supports extended preset dims (by turning them into &P commands instead of dumping the raw hex into mh.) > > >> There is plenty of bandwidth between MH and the interface, Create a > >> single DIM command, pass the device type, and let the interface figure > >> out what the correct X10 way to dim that specific device is. > > The specific dim command for a particular X10 device should be determined > higher up by the object module for that device. All interface modules > should > support the same set of commands. > > >> Let me applogize somewhat for the rant above - I am just surely from > >> trying to massage all the idiosyncracies of the MH ASCII X10 stream into > >> a TI103 interface. > > > > I understand completely. I did a lot of work on the cm11 and w800rf > > modules. > > The latter hasn't been released as it works slightly differently than the > > original. Might have to make it a new module or something. I found the > > current version of that one to be impossible, but there are people using > > it. > > My module accepts for sending a housecode followed by either: > > A unit code 1-9, A-G > > An X10 function > J, # aka ON > K, # aka OFF > L, # aka Bright > M, # aka Dim > O, # aka All Lights ON > P, # aka All Units OFF > ALL_OFF, # aka All Units OFF, reported as P on receive > ALL_ON, # aka All Lights ON, reported as O on receive > ALL_LIGHTS_OFF, # reported as P on receive > EXTENDED_CODE, # posibly ambiguous because E is valid unit > HAIL_REQUEST, > HAIL_ACK, > PRESET_DIM1, # aka Preset Dim 0 I don't understand the aka. > EXTENDED_DATA, # posibly ambiguous because E is valid unit This is Z. Mh won't parse EXTENDED_DATA properly. > STATUS_ON, > STATUS_OFF, > STATUS, > PRESET_DIM2, # aka Preset Dim 1 Same as above. > > Relative dim n-times +/-## > (I think percentages are converted to n-times by X10_Item) > I can't remember which layer deals with these (in either version.) I think it has changed in my version. > Leviton and LM14 style preset dim &P# > (this is a special function on the Ocelot. I think it's an extended code > X10 command) &P is an mh syntax meaning preset dim. Cm11 sends/receives these as well. > > see http://www.geocities.com/ido_bartana/toc.htm > > David > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/? group_id=1365 > > |
From: David N. <dno...@ya...> - 2005-12-08 05:23:37
|
David Mark wrote: > David Norwood <dnorwood2 <at> yahoo.com> writes: >> > David H, Lynch Jr. <dhlii <at> comcast.net> writes: >> >> David Mark wrote: >> > 1. Change definition of house code O and P commands (eg AO, AP) in >> > X10_Items.pm. They are currently translated to ON and OFF, while the J >> > and K >> > are commented out. This is a strange twist. >> >> Actually, O and P are for sending ALL LIGHTS ON and ALL UNITS OFF, >> respectively. That is why it's in the section that applies to the whole >> housecode. > > I know. But they are attached to "on" and "off" (which are J and K.) > They > need their own tokens (eg "allon", "alloff") so that you can create an X10 > item like "A", which has states: "AJ", "AK, "AO", "AP." This is necessary > to > support controllers that send "AJ", etc. without a device prefix (implies > all > currently addressed devices.) I see your point and agree. It will break some scripts, but should be minimal. >> > 2. Fix cm11 STATUS commands as mentioned before (new parse routine will >> > not >> > work with A1STATUS) >> >> You should allow for XA1BSTATUS, since the X10 protocol allows for it and >> someone might want to do it. > > You have to for the templincs. That is another reason why A1STATUS, etc. > is > invalid. Agreed. >> > 3. Fix all other controller modules that send and receive A1J, etc. >> >> The reason the CM17 firecracker module omits the second housecode is that >> the wireless X10 protocol combines the housecode, unit, and function in >> one >> command. It's imposible to send XA1BK via RF. > > I still say pass and receive in A1AJ form so as not to obscure the mh > parse > routine further. I definetly agree that A1AJ sent to the interface module in two chunks is preferable to A1J sent in one. >> > If we can get all of that fixed in the distribution, I will submit the >> > new >> > parse code... >> >> Are your changes for sending or receiving? > > I rewrote the entire section of mh that receives and matches X10 strings. > The > main improvement is that it handles mutliple commands bunched together. > Like > C2CJA1ASTATUSONF1FK, etc. Once in a while I see things like this show up > as > unmatched. There was some really strange stacking of dim commands too. > Some > things were removed from the mh layer and left to X10_Items and vice > versa. > All in all, the new one is a much easier read for future developers. I > should > note that for all its benefits, I am not using it here. I just don't have > the > time to test a new X10 engine and have lost interest in keeping the > logging > 100% accurate (won't happen with X10 anyway.) The version I use here is > only > slightly modified from the distribution. At this point, I know all of its > quirks and just live with them. > > I didn't do much (if anything) to the sending portion of mh. I have made > additional changes to cm11's send routine. The hack concerning the > previously > addressed device has been fixed (so it is no longer a hack.) As I recall, > it > was using a static variable to hold the last device and then tacking it on > to > status commands. Your changes sound like an improvement, but should be tested by a few people. >> >> Utlimately, the messages have two parts - a target and a command. The >> >> MH >> >> X10 interface protocol, sort of diveds that way, but the housecode is >> >> only relevant in the command, because somewhere just before hitting >> >> the >> >> wire something is going to have to add the house code to the command. >> >> At >> >> the upperlevels it is only confusing and makes parsing harder, as does >> >> the odd mix of overlapping commands as strings, commands as singles >> >> letters ... >> > >> > Yes it is a mess. >> >> It's just X10, not a misterhouse complexity. > > Not exactly. Mh and the various controller modules introduce a ton of > complexity (at least from my experience with the above-mentioned > routines.) Yeah, you're right. Probably the best solution is to document the "officially supported" X10 commands and then try to keep all the interface modules in line with that. Right now you have to look at the code to see which are supported. There is a question in the FAQ about this, but the answer is incomplete. Here is a start (from Serial_Item.pm): if ($serial_data =~ /^([A-P]STATUS)(\S*)/ or $serial_data =~ /^([A-P]PRESET_DIM1)(\S*)/ or $serial_data =~ /^([A-P]PRESET_DIM2)(\S*)/ or $serial_data =~ /^([A-P][1][0-6])(\S*)/ or $serial_data =~ /^([A-P][1-9A-W])(\S*)/ or $serial_data =~ /^([A-P]\&P\d+)(\S*)/ or # Pre Dim Cmds $serial_data =~ /^([A-P]Z\S*)/ or # Scene Cmds for Switchlinc $serial_data =~ /^([A-P]\d+\%)(\S*)/ or $serial_data =~ /^([A-P][\+\-]?\d+)(\S*)/) { >> >> I know why X10 has a plethora of means to do a dim, but why does the >> >> message stream have to deal with that? >> > >> > It shouldn't. The dimming is the messiest and most confusing part of >> > the >> > main >> > parse code. This is compounded by each controller having its own way >> > of >> > sending in levels. It makes it really impossible to reliably track the >> > levels >> > of the old lamp modules. >> >> Aren't there just two ways to do dimming? Relative and absolute (preset >> dim). That is all my Ocelot module supports. I realize only some X10 >> devices support absolute dimming, and there are a couple ways they have >> implemented it, but that should be handled higher up by the object for >> that >> device. > > Yes and no. There are multiple ways to tell mh to dim. At least one is > cm11- > specific. In short, L and M, +n, -n and the standard preset dims (&P) > plus > the cm11 supports extended preset dims (by turning them into &P commands > instead of dumping the raw hex into mh.) The Ocelot supports the lm14a style extended dims also. >> >> There is plenty of bandwidth between MH and the interface, Create a >> >> single DIM command, pass the device type, and let the interface figure >> >> out what the correct X10 way to dim that specific device is. >> >> The specific dim command for a particular X10 device should be determined >> higher up by the object module for that device. All interface modules >> should >> support the same set of commands. >> >> >> Let me applogize somewhat for the rant above - I am just surely from >> >> trying to massage all the idiosyncracies of the MH ASCII X10 stream >> >> into >> >> a TI103 interface. >> > >> > I understand completely. I did a lot of work on the cm11 and w800rf >> > modules. >> > The latter hasn't been released as it works slightly differently than >> > the >> > original. Might have to make it a new module or something. I found >> > the >> > current version of that one to be impossible, but there are people >> > using >> > it. >> >> My module accepts for sending a housecode followed by either: >> >> A unit code 1-9, A-G >> >> An X10 function >> J, # aka ON >> K, # aka OFF >> L, # aka Bright >> M, # aka Dim >> O, # aka All Lights ON >> P, # aka All Units OFF >> ALL_OFF, # aka All Units OFF, reported as P on receive >> ALL_ON, # aka All Lights ON, reported as O on receive >> ALL_LIGHTS_OFF, # reported as P on receive >> EXTENDED_CODE, # posibly ambiguous because E is valid unit >> HAIL_REQUEST, >> HAIL_ACK, >> PRESET_DIM1, # aka Preset Dim 0 > > I don't understand the aka. I included this "also known as" because some sources refer to PRESET_DIM1 as Preset Dim 0. > EXTENDED_DATA, # posibly ambiguous because E is valid unit > > This is Z. Mh won't parse EXTENDED_DATA properly. I included this for completeness. It's possible to send an EXTENDED_DATA command without any actual extended data appended. I think misterhouse should be able to send all 16 standard functions. >> STATUS_ON, >> STATUS_OFF, >> STATUS, >> PRESET_DIM2, # aka Preset Dim 1 > > Same as above. > >> >> Relative dim n-times +/-## >> (I think percentages are converted to n-times by X10_Item) >> > > I can't remember which layer deals with these (in either version.) I > think it > has changed in my version. I guess I should support % as well. >> Leviton and LM14 style preset dim &P# >> (this is a special function on the Ocelot. I think it's an extended code >> X10 command) > > &P is an mh syntax meaning preset dim. Cm11 sends/receives these as well. &P is specific to the lm14a style extended command. Other devices like PCS dimmers accept standard (not extended) X10 commands like PRESET_DIM1. X10 Item should figure out which command to send to the interface module based on the 'type' field in the item. I realize the type field isn't used much, but this is what it's for. >> see http://www.geocities.com/ido_bartana/toc.htm |
From: David N. <dno...@ya...> - 2005-12-24 06:40:05
|
while ($serial_data) { if ($serial_data =3D~ /^([A-P]STATUS_OFF)(\S*)/ or $serial_data =3D~ /^([A-P]STATUS_ON)(\S*)/ or $serial_data =3D~ /^([A-P]STATUS)(\S*)/ or $serial_data =3D~ /^([A-P]ALL_LIGHTS_OFF)(\S*)/ or $serial_data =3D~ /^([A-P]EXTENDED_CODE)(\S*)/ or $serial_data =3D~ /^([A-P]EXTENDED_DATA)(\S*)/ or $serial_data =3D~ /^([A-P]HAIL_REQUEST)(\S*)/ or $serial_data =3D~ /^([A-P]HAIL_ACK)(\S*)/ or $serial_data =3D~ /^([A-P]PRESET_DIM1)(\S*)/ or $serial_data =3D~ /^([A-P]PRESET_DIM2)(\S*)/ or $serial_data =3D~ /^([A-P][1][0-6])(\S*)/ or $serial_data =3D~ /^([A-P][1-9A-W])(\S*)/ or $serial_data =3D~ /^([A-P]\&P\d+)(\S*)/ or # = extended direct dim cmd=20 $serial_data =3D~ /^([A-P]Z\S*)/ or # = Extended Code cmd with arbitrary extended bytes=20 $serial_data =3D~ /^([A-P]\d+\%)(\S*)/ or # = these are converted to &P above=20 $serial_data =3D~ /^([A-P][\+\-]?\d+)(\S*)/) { $serial_chunk =3D $1; $serial_data =3D $2; |
From: Neil W. <ne...@nw...> - 2005-12-24 06:49:00
|
Hi David, Great work. From a higher up level, it would be nice to see what commands are required for the various X10 modules. I only have appliance and modules dimmers. It would be nice to know the exact format of perl code I need to drive each of the various modules. I.e. Appliance Module is only ON/OFF, fair enough. But what options are available for a dimmable module or camera or what should I expect from a Hawk eye, curtain controller etc etc. Regards, Neil Wrightson. -----Original Message----- From: David Norwood [mailto:dno...@ya...] Sent: Saturday, 24 December 2005 5:40 PM To: mis...@li... Subject: Re: [mh] What do valid X10 strings look like? I have examined Serial_Item.pm and the various X10 interface modules and have documented the currently supported X10 codes. This is meant to guide users, but more importantly, it is meant as the definetive specification for the X10 strings sent and received by misterhouse interface modules. This thread started because there is a huge variation in the commands supported by the various X10 modules. The CM11 module was used as the model for this documentation, since it is the most fully implemented X10 interface module. I have tried to be complete as possible, so please let me know if you find any errors or omissions. Bruce, you should be able to copy and paste the html code from this message. Also, there are two "2.14" questions in the FAQ. And finally, I updated a section of code in Serial_Item.pm to add support for sending some of the rarely used X10 commands already supported by the CM11 module. David 2.15: What is the format of MisterHouse X10 codes? At a low level MH sends and receives X10 data in character strings (called Serial Items) that start with the letter X. It is usually easier to create an X10 Item (or similar) for each X10 device you have and manipulate those instead of using X10 strings. Most of the functionality descibed here is available in various items in easy to use states. Here is format of Misterhouse X10 strings: X10 strings always begin with an uppercase X (all letters in X10 strings must be uppercase.) The X is followed by one or more token pairs that are either a housecode and unitcode, or a housecode and command. A housecode is a letter in the range A through P. A unitcode is a number in the range 1 through 16. Unitcodes above 9 can be specified as two digit numbers or their hex equivalent A through G. Okay, there is no such thing as hex G, but X10 unitcodes start at 1, not 0. A note to X10 interface module developers: the Serial_Item module converts unitcodes above 9 to their hex equivalent before passing them to the interface module. The following four basic X10 commands are the most common and are supported by all the interface modules. Each command is listed here followed by the corresponding X10 command that is sent or received, plus any notes about its use: J - ON K - OFF L - Brighten M - Dim These commands are less common and are not supported by all the interface modules: O - All Lights ON P - All Units OFF STATUS - accepted by some 2-way X10 devices to request status PRESET_DIM1 - these are the original direct dim commands specified but never used by X10 PRESET_DIM2 - still used by some X10 venders, including PCS, SwitchLinc and RCS +# - increase brightness by # percent, not used for receive -# - decrease brightness by # percent, not used for receive Serial_Item rounds # to a multiple of 5 before it's passed to the interface module, the interface module calculates the number of Bright/Dim commands to send by multiplying # by 22/100, since there are 22 standard dim levels &P# - send an extended direct dim command accepted by some X10 devices, # is the brightness level in the range 0 through 63 #% - same as &P command, but # is a percentage in the range 0 through 100, Serial_Item converts this to a &P command before it's passed to the interface module, neither &P nor % are currently used for receive Z## - intended for sending and receiving EXTENDED_CODE commands with arbitrary extended hex ## bytes appended, but appears only receive is implemented by the CM11 module, no other tokens may follow this command These commands are rarely used and only supported for completeness by a few interface modules: ALL_LIGHTS_OFF - reported as P on receive HAIL_REQUEST HAIL_ACK EXTENDED_CODE - see Z above EXTENDED_DATA STATUS_ON STATUS_OFF Here are examples of valid X10 strings and what they do: XM1MK - turn off M1 XC1C2C3CJ - turn on C1, C2, and C3 simultaneously XI6IJIKIJIK - flash I6 twice For more examples, take a look at mh/lib/X10_Items.pm. Many of the X10 interface modules expect only a housecode/unitcode pair and a housecode/command pair, like the first example above. This makes it impossible to send more complicated strings like the other examples, and is therefore discouraged. This can't be avoided with interfaces like the CM17 and BX24 that transmit using the X10 wireless protocol, since it combines housecode, unitcode, and command in one transmission. |
From: David N. <dno...@ya...> - 2005-12-24 08:22:11
|
I considered creating a table showing which modules support which = commands, but decided it would be impossible to keep up to date. The = CM11 supports all the commands I documented. The Ocelot supports all = but the Z command. After that, it's a crapshoot beyond the basics. = Thanks to David Mark, most modules will support sending O and P in the = next release. I think documentation about particular X10 devices = (dimmers, cameras, hawkeyes, curtain controllers, etc) belong in the = objects section of the mh docs, or each in it's own FAQ. For example, = How do I use motion sensors in Misterhouse? =20 David=20 ----- Original Message -----=20 From: Neil Wrightson=20 To: mis...@li...=20 Sent: Friday, December 23, 2005 10:49 PM Subject: RE: [mh] What do valid X10 strings look like? Hi David, Great work.=20 From a higher up level, it would be nice to see what commands are = required for the various X10 modules. I only have appliance and modules dimmers. It would be nice to know = the exact format of perl code I need to drive each of the various = modules. I.e. Appliance Module is only ON/OFF, fair enough. But what = options are available for a dimmable module or camera or what should I = expect from a Hawk eye, curtain controller etc etc. Regards,=20 Neil Wrightson.=20 -----Original Message----- From: David Norwood [mailto:dno...@ya...] Sent: Saturday, 24 December 2005 5:40 PM To: mis...@li... Subject: Re: [mh] What do valid X10 strings look like? I have examined Serial_Item.pm and the various X10 interface modules = and have documented the currently supported X10 codes. This is meant to = guide users, but more importantly, it is meant as the definetive = specification for the X10 strings sent and received by misterhouse = interface modules. This thread started because there is a huge = variation in the commands supported by the various X10 modules. The = CM11 module was used as the model for this documentation, since it is = the most fully implemented X10 interface module. I have tried to be = complete as possible, so please let me know if you find any errors or = omissions. Bruce, you should be able to copy and paste the html code from this = message. Also, there are two "2.14" questions in the FAQ. And finally, = I updated a section of code in Serial_Item.pm to add support for sending = some of the rarely used X10 commands already supported by the CM11 = module. =20 David=20 2.15: What is the format of MisterHouse X10 codes? At a low level MH sends and receives X10 data in character strings = (called Serial Items) that start with the letter X. It is usually easier = to create an X10 Item (or similar) for each X10 device you have and = manipulate those instead of using X10 strings. Most of the functionality = descibed here is available in various items in easy to use states.=20 Here is format of Misterhouse X10 strings: X10 strings always begin = with an uppercase X (all letters in X10 strings must be uppercase.) The = X is followed by one or more token pairs that are either a housecode and = unitcode, or a housecode and command.=20 A housecode is a letter in the range A through P.=20 A unitcode is a number in the range 1 through 16. Unitcodes above 9 = can be specified as two digit numbers or their hex equivalent A through = G. Okay, there is no such thing as hex G, but X10 unitcodes start at 1, = not 0. A note to X10 interface module developers: the Serial_Item module = converts unitcodes above 9 to their hex equivalent before passing them = to the interface module.=20 The following four basic X10 commands are the most common and are = supported by all the interface modules. Each command is listed here = followed by the corresponding X10 command that is sent or received, plus = any notes about its use:=20 J - ON K - OFF L - Brighten M - Dim These commands are less common and are not supported by all the = interface modules:=20 O - All Lights ON P - All Units OFF STATUS - accepted by some 2-way X10 devices to request = status PRESET_DIM1 - these are the original direct dim commands = specified but never used by X10=20 PRESET_DIM2 - still used by some X10 venders, including PCS, = SwitchLinc and RCS=20 +# - increase brightness by # percent, not used for = receive=20 -# - decrease brightness by # percent, not used for = receive=20 Serial_Item rounds # to a multiple of 5 before = it's passed to the interface module, the interface module calculates the number of = Bright/Dim commands to send by multiplying # by 22/100, since there are 22 = standard dim levels=20 &P# - send an extended direct dim command accepted by = some X10 devices, # is the brightness level in the range 0 through = 63 #% - same as &P command, but # is a percentage in the = range 0 through 100, Serial_Item converts this to a &P command before = it's passed to the interface module, neither &P nor % are currently used for receive=20 Z## - intended for sending and receiving EXTENDED_CODE = commands with arbitrary extended hex ## bytes = appended, but appears only receive is implemented by the CM11 module, = no other tokens may follow this command=20 These commands are rarely used and only supported for completeness by a = few interface modules:=20 ALL_LIGHTS_OFF - reported as P on receive HAIL_REQUEST HAIL_ACK EXTENDED_CODE - see Z above=20 EXTENDED_DATA STATUS_ON STATUS_OFF Here are examples of valid X10 strings and what they do:=20 XM1MK - turn off M1 XC1C2C3CJ - turn on C1, C2, and C3 simultaneously XI6IJIKIJIK - flash I6 twice=20 For more examples, take a look at mh/lib/X10_Items.pm.=20 Many of the X10 interface modules expect only a housecode/unitcode = pair and a housecode/command pair, like the first example above. This = makes it impossible to send more complicated strings like the other = examples, and is therefore discouraged. This can't be avoided with = interfaces like the CM17 and BX24 that transmit using the X10 wireless = protocol, since it combines housecode, unitcode, and command in one = transmission. =20 |
From: David H. L. Jr. <dh...@co...> - 2005-12-24 20:41:15
|
I would tend to agree. X10 has a plethora of dimming commands. and aside from DIM/BRT what works is extremely module specific. Knowing exactly what dim variant to send for each module should be handled by MH or by the X10 driver. The "MH application developer" should just be setting absolute or relative percentages and MH should be able to figure out whether a specific module needs N DIMs or can use the extended dim commands or whatever. I am not sure how that works for other X10 devices like motion detectors, cameras, etc. I think the .mht should include a field for a module identifier. If it is left blank then MH should assume the least capable device. To deal with unknown devices, the module identifier could optionally be a module cababilites - either as a mask or string,with bits like 2way, supports extended dims, .... Neil Wrightson wrote: > Hi David, > > Great work. >>From a higher up level, it would be nice to see what commands are required > for the various X10 modules. > I only have appliance and modules dimmers. It would be nice to know the > exact format of perl code I need to drive each of the various modules. I.e. > Appliance Module is only ON/OFF, fair enough. But what options are available > for a dimmable module or camera or what should I expect from a Hawk eye, > curtain controller etc etc. > > Regards, > > Neil Wrightson. |
From: David N. <dno...@ya...> - 2005-12-25 03:22:46
|
> I think the .mht should include a field for a module identifier. > If it is left blank then MH should assume the least capable device. To > deal with unknown devices, the module identifier could optionally be a > module cababilites - either as a mask or string,with bits like 2way, > supports extended dims, .... There is a field called $type that is meant for this purpose, but hasn't been used much. I think the only valid type you can enter is lm14, which is an extended dim capable, 2-way lamp. Another approach is to create a new item like someone did for the Switchlinc. This makes sense for devices that have a lot of features. David |
From: David H. L. Jr. <dh...@dl...> - 2005-12-24 20:51:19
|
David Norwood wrote: I am presuming that you are spec'ing the User/X10_Items interface, not the interface to the controller as they all seem to be slightly different. I suspect the MH code could be simplified if all the controller interfaces supported the same interface to MH, and internally parsed things as they needed. I will try to verify that TI103.pm parses all the commands listed. But I can not test everything as I have a relatively limited number of different types of modules - mostly 1way appliance and lamp modules. Are we expecting all the > ------------------------------------------------------------------------ > > while ($serial_data) { > if ($serial_data =~ /^([A-P]STATUS_OFF)(\S*)/ or > $serial_data =~ /^([A-P]STATUS_ON)(\S*)/ or > $serial_data =~ /^([A-P]STATUS)(\S*)/ or > $serial_data =~ /^([A-P]ALL_LIGHTS_OFF)(\S*)/ or > $serial_data =~ /^([A-P]EXTENDED_CODE)(\S*)/ or > $serial_data =~ /^([A-P]EXTENDED_DATA)(\S*)/ or > $serial_data =~ /^([A-P]HAIL_REQUEST)(\S*)/ or > $serial_data =~ /^([A-P]HAIL_ACK)(\S*)/ or > $serial_data =~ /^([A-P]PRESET_DIM1)(\S*)/ or > $serial_data =~ /^([A-P]PRESET_DIM2)(\S*)/ or > $serial_data =~ /^([A-P][1][0-6])(\S*)/ or > $serial_data =~ /^([A-P][1-9A-W])(\S*)/ or > $serial_data =~ /^([A-P]\&P\d+)(\S*)/ or # extended direct dim cmd > $serial_data =~ /^([A-P]Z\S*)/ or # Extended Code cmd with arbitrary extended bytes > $serial_data =~ /^([A-P]\d+\%)(\S*)/ or # these are converted to &P above > $serial_data =~ /^([A-P][\+\-]?\d+)(\S*)/) { > $serial_chunk = $1; > $serial_data = $2; > |