8

tl;dr;

What I need to be able to do is reverse engineer serial commands so that I can figure out how either the human readable values or the binary values are being serialized into raw serial commands.

IE:

if
   66 = 'A1' or '0110 1'
   6e = 'A2' or '0110 2'
   e6 = 'B1' or '1110 1'
   ee = 'B2' or '1110 2'
then
   what is A3 or B3, etc.

Im working on a wrapper for an open source automation project.

There is a way to send raw commands, and in theory string multiple commands together.
I've sniffed a few serial commands, and this is what they look like.

[init] [HouseCode | DeviceCode] [ready] [HouseCode | FunctionCode]   

04 66 06 62       // A1 ON
04 6e 06 62       // A2 ON 
04 62 06 62       // A3 ON
04 6a 06 62       // A4 ON
04 61 06 62       // A5 ON
04 69 06 62       // A6 ON
04 65 06 62       // A7 ON
04 6d 06 62       // A8 ON
04 67 06 62       // A9 ON
04 6f 06 62       // A10 ON
04 63 06 62       // A11 ON
04 6b 06 62       // A12 ON
04 60 06 62       // A13 ON
04 68 06 62       // A14 ON
04 64 06 62       // A15 ON
04 6c 06 62       // A16 ON

04 e6 06 e2       // B1 ON 
04 ee 06 e2       // B2 ON  
04 e2 06 e2       // B3 ON 
04 ea 06 e2       // B4 ON 
....
04 ec 06 e2       // B16 ON
04 66 06 63       // A1 Off
04 e6 06 e3       // B1 Off

04 66 06 61       // All A lights On (using A1 as the starting point)
04 e6 06 e1       // All B lights On (using B1 as the starting point)
04 66 06 66       // All A lights Off (using A1 as the starting point)
04 e6 06 66       // All B lights Off (using A1 as the starting point)

04 66 06 64 2a    // A1 Dim 20
04 66 06 64 2c    // A1 Dim 21
04 66 06 64 2e    // A1 Dim 22

04 66 06 65 2a    // A1 Bright 20
04 66 06 65 69    // A1 Bright 50

What I need to be able to do is reverse engineer this so that I can make the serial calls programmatically, or better yet, figure out how either the human readable values or the binary values are being serialized into raw serial commands.

Yes, I could sniff ALL the commands and store each value separately, but I'd like to know how this has been done.

Here's my current observation.

  1. The calls are broken up into two.
    • 04 is initiated and tells the device what to look for
    • ** tells the system which device is being controlled [HouseCode & DeviceCode]
    • hex 55 is returned to tell you it's ready
    • 06 is initiated and tells the device what to expect
    • ** tells the system the house code and command [HouseCode & FunctionCode]
      • ** is optionally sent and is a value between 0 & 100 to reference a dim level
    • hex 55 is sent back again to tell you it's ready
  2. The second pair uses the first character as the alphabetic code (HouseCode = A, B, C, etc) and the second character is the address (DeviceCode = 1, 2, 3, etc)
    • with this information, my personal guess is that...
      • 6 must directly correspond to A
      • e must directly correspond to B
  3. The forth pair starts with the same HouseCode as the second pair
  4. The forth pair ends with the FunctionCode
    • 1 = all on
    • 2 = on
    • 3 = off
    • 4 = dim
    • 5 = bright
    • 6 = all off
    • etc..
  5. The fifth pair only shows on a bright/dim command and represents the number between 0 and 100

Lastly, in the docs, each of the commands relate to Binary data, so it's probably not a matter of converting A1 to hex, but rather the binary to hex.

HouseCode       DeviceCode      Binary Value
    A               1               0110
    B               2               1110
    C               3               0010
    D               4               1010
    E               5               0001
    F               6               1001
    G               7               0101
    H               8               1101
    I               9               0111
    J               10              1111
    K               11              0011
    L               12              1011
    M               13              0000
    N               14              1000
    O               15              0100
    P               16              1100

FunctionCode                    Binary Value
All Units Off                   0000
All Lights On                   0001
On                              0010
Off                             0011
Dim                             0100
Bright                          0101
All Lights Off                  0110
Extended Code                   0111
Hail Request                    1000
Hail Acknowledge                1001
Pre-set Dim (1)                 1010
Pre-set Dim (2)                 1011
Extended Data Transfer          1100
Status On                       1101    
Status Off                      1110
Status Request                  1111

Does anyone know how I might go about achieving this?

Chase Florell
  • 46,378
  • 57
  • 186
  • 376
  • Can't you just use their SDK? http://www.x10.com/activehomepro/sdk/index.html There's a forum there as well, best place to ask. – Hans Passant Nov 12 '12 at 22:30
  • I am using the SDK. That's where `sendplc` and `sendrawplc` come from. Unfortunately their documentation don't instruct us on how those hex calls are generated. – Chase Florell Nov 12 '12 at 22:44
  • I mean ** doesn't ** [english much :(] – Chase Florell Nov 12 '12 at 22:57
  • 1
    Erm, that's not much of an SDK. You can use SysInternals' PortMon utility to spy on serial port traffic. – Hans Passant Nov 12 '12 at 23:03
  • Yeah, I'm actually using [Device Monitoring Studio](http://www.hhdsoftware.com/) to sniff the traffic currently. I can extrapolate EVERY command manually, but I'd rather know how it's being generated. – Chase Florell Nov 12 '12 at 23:05
  • ps: @HansPassant, I do have an [open thread](http://forums.x10.com/index.php?topic=27677.15) over in their forums as well. Unfortunately it's looking like sniffing every command is going to be the easiest approach, unfortunately it's not all that [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). – Chase Florell Nov 12 '12 at 23:46

1 Answers1

1

Heyu is a fantastic open source application for working with X10 devices. They have published a very comprehensive X10 protocol specification based on X10's original doc.

This should take the guess work out of your work. What is significant is that the housecode and unitcode are static maps and can not be computed. The protocol spec specifies exactly how the bitstream is formed. E.g.

PC      Interface   Description
0x04,0x66           Address A1
        0x6a        Checksum ((0x04 + 0x66)&0xff)
0x00                OK for transmission.
        0x55        Interface ready.

0x86,0x64           Function: A Dim 16/22*100%
        0xea        Checksum ((0x86 + 0x64)&0xff)
0x00                OK for transmission.
        0x55        Interface ready.
Alastair McCormack
  • 26,573
  • 8
  • 77
  • 100
  • Section `1.1` is exactly what I was looking for. So as I see it... [`6`=`a`=`1`] and [`e`=`b`=`2`].. That's what I was missing. Now to just figure out the encoding method for numbers `1` through `100` for dimming. – Chase Florell Nov 14 '12 at 16:29
  • @ChaseFlorell, I think everyone has misinterpreted your question. was it that you wanted to convert from binary to hex? The hex output from the serial monitor is just a representation of binary. I'm not a c# coder but apparently you can do something like: `byte b = Convert.ToByte("1110", 2)` then compare `b` with hex. E.g `0xE` or send `b` on the wire as is. – Alastair McCormack Nov 14 '12 at 18:20