It does seem to be merely an error in how it reports the codes as we haven't seen complaints that it wasn't addressing the expected lights/appliances. As long as it's consistent, you can create your own translation to human readable codes.

The example you gave earlier in the thread shows where the error occurs.

The standard RF codes are sent as 32 bits. The first 8 bits are repeated in two's complement form as the second 8 bits. And, the third 8 bits are repeated in two's complement form as the fourth 8 bits. Two's complement is done with a logical NOT operation. All the bits flip from 0 to 1 and vice versa. This allows for some rudimentary error checking as the byte pairs should be two's complements of each other and sum to FFh or 11111111. It also allows for

*DC balance* in the RF signal.

And, the 1st & 3rd bytes are those given in the CM17A protocol from X10.

Your example shows this but uses hexadecimal rather than binary notation. The first two bytes identify the source as RF (5Dh) and indicate that 32 bits follow (20h).

A1 ON is 01100000 10011111 00000000 11111111 in binary and 60 9F 00 FF in hexadecimal.

But, in the second example, A15 OFF, the 3rd & 4th reported bytes are not two's complements of each other.

64 9B 68 93 in binary are 01100100 10011011 01101

000 10010

011.

(NOT 01101

000 = 10010

111)

68h + 93h = FBh or 11111011 binary.

Most likely, the CM15A is doing some undesired bit shifting but it would require a larger sample to verify this.