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 |