# Problems calculating checksum for AirConditioner

I am trying to reverse engineer an AC Indoor unit <-> thermostat communication. So far I've succeeded in parsing the bits and bytes.

I discovered that the upper and lower nibbles need to be reversed to get consecutive values for temperature values, for example, so I assume that part is correct.

Also, the unit sends the payload twice, so I assume the values are correct.

Finally, I am trying to calculate the checksum of the received values, but I cannot find a pattern that results in a matching checksum.

I did notice that value change of `0x01` raises the checksum by `0x10`, so I tried reversing each value and sum them up, but that did not provide the expected result. On the other hand, changing `0x10` to `0x30` does not affect the checksum at all.

Here some of the received bytes (received twice like this):

``````vent hex: 09 da d1 04 01 00 44 13 a4 09 00 40 10 04 01 1d

cool hex: 09 d8 d1 04 01 00 40 17 a4 09 00 40 10 04 01 6a

ai   hex: 09 de d1 04 01 01 40 17 a4 09 00 40 10 04 01 7c

dehumhex: 09 dc d1 04 01 00 40 15 24 09 00 40 10 04 01 5a

heat hex: 09 d9 d1 04 01 01 40 17 a4 f1 00 40 10 04 01 4c

hex: 2a d7 10 04 01 00 40 10 04 01 00 48 14 7c 09 78 1=0001

hex: 2a d7 30 04 01 00 40 10 04 01 00 48 14 7c 09 78 3=0011

hex: 2a d7 50 04 01 00 40 10 04 01 00 48 14 7c 09 79 5=0101

hex: 2a d7 70 04 01 00 40 10 04 01 00 48 14 7c 09 79 7=0111

hex: 2a d7 90 04 01 00 40 10 04 01 00 48 14 7c 09 7a 9=1001

hex: 2a d7 b0 04 01 00 40 10 04 01 00 48 14 7c 09 7a B=1011

hex: 2a d7 d0 04 01 00 40 10 04 01 00 48 14 7c 09 7b D=1101

hex: 2a d7 f0 04 01 00 40 10 04 01 00 48 14 7c 09 7b F=1111

hex: 2a d6 10 04 01 00 40 10 04 01 00 48 14 7c 09 7c

hex: 2a d6 30 04 01 00 40 10 04 01 00 48 14 7c 09 7c

hex: 2a d6 70 04 01 00 40 10 04 01 00 48 14 7c 09 7d

hex: 2a d6 50 04 01 00 40 10 04 01 00 48 14 7c 09 7d

hex: 2a d6 b0 04 01 00 40 10 04 01 00 48 14 7c 09 7e

hex: 2a d6 d0 04 01 00 40 10 04 01 00 48 14 7c 09 7f

hex: 2a d6 f0 04 01 00 40 10 04 01 00 48 14 7c 09 7f
``````

Here is some parsed output of a temperature decrease with the reversed payload(rhex):

``````source: 09  head 110 mode 38 modeb 11001 fan 0 bfan: 000 unkownb: 1000

swing: 4 bswing 00000100

plasma 1 tempStart: 0001 temp: 90 tempStop: 010 airclean 1

unkown: 01 01 44  splayload: e9  rest: 00 40 10 04 01  chksum: 2a

hex: 09 d9 11 04 01 01 44 15 a5 e9 00 40 10 04 01 2a

rhex 90 9b 88 20 80 80 22 a8 a5 97 00 02 08 20 80 54

source: 09  head 110 mode 38 modeb 11001 fan 0 bfan: 000 unkownb: 1000

swing: 4 bswing 00000100

plasma 1 tempStart: 0001 temp: 88 tempStop: 010 airclean 1

unkown: 01 01 44  splayload: e9  rest: 00 40 10 04 01  chksum: 6a

hex: 09 d9 11 04 01 01 44 11 a5 e9 00 40 10 04 01 6a

rhex 90 9b 88 20 80 80 22 88 a5 97 00 02 08 20 80 56
``````

Maybe somebody can give me a hint in the right direction.

The test setup is running in Python on a Raspberry Pi.

• Quote: I discovered that the upper and lower nibbles need to be reversed to get consecutive values for temperature values, for example, so I assume that part is correct. Sounds a lot like a difference in Endianess, but maybe not.. You are going to have to keep like you are doing, guessing at the algorithm. Your quick edits suggest strongly that it is very simplistic, so given time, I'm sure you will get it. – dyasta Jan 9 '17 at 2:48
• Try running reveng.sourceforge.net against it playing around with the parameters If it is a normal crc (initial value of 0) then you can also check the identity `CRC(A)^CRC(B)=CRC(A^B)` and if it's true you can use it to validate and generate checksums – Avery3R Jan 25 '18 at 2:36