Fujitsu IR Remote Checksum Calculation - bit-manipulation

Question

I am trying to reverse engineer the Fujitsu AC remote control protocol for a home automation project. I have gotten as far as identifying which bytes correspond to which control information, however there is a checksum at the end.
I believe the checksum is calculated using three other bytes (temperature, mode and fan speed).
I have used a spreadsheet to try reverse engineering what operations have been performed to get the checksum and found that for a temperature of "00001010" and any mode/fan speed combination the following algorithm holds true;
Checksum = 392 - (Temperature + Mode + Fan Speed)
Example
392 - (10 + 64 + 128) = 190
392 - (10 + 192 + 128) = 62
392 - (10 + 32 + 128) = 222
However no other temperature (that I have tested) works this way. My current theory is that the temperature has some other operation performed on it first and that whatever this operation is results in the same value for a temperature of "00001010", but not other temperatures.
Raw data:
Temperature, Mode, Fan Speed, Checksum
00000110, 10000000, 10000000, 01110110
00001010, 10000000, 10000000, 01111110
00000010, 10000000, 10000000, 01110001
Full spreadsheet at: This link
I can't work out what operation(s) are being performed on the temperature, or in fact if I am even correct in my assumptions about what the algorithm is.
I'm wondering if there is anyone with more experience with this kind of problem that might be able to shed some light on this?
Extras:
The temperature value is the integer of the temperature say 21 degrees (00010101)
1. Reversed to get 10101000
2. Only the first four bits taken - 1010
3. Then expanded to get a value of 00001010
So 00001010 in the raw data above is a temperature of 21 degrees
Original question has been edited as I was originally approaching this incorrectly and assuming my hypothesis was correct

Answer 1

I found the following solution after some more sifting through Google search results.
Thanks George Dewar on Github
1. Reverse (flip) bytes 8 - 13 (I - N in spreadsheet)
2. Sum those bytes
3. (208 - sum) % 256
4. Reverse (flip) bytes of result
E.g.
Data: 00000110, 10000000, 10000000, 00000000, 00000000, 00000000
1. Reverse:
01100000, 00000001, 00000001, 00000000, 00000000, 00000000
96, 1, 1, 0, 0, 0
2. Sum:
96 + 1 + 1 + 0 + 0 + 0 = 98
3. Calculate:
(208 - 98) % 256 = 110 (dec) or 01101110 (bin)
4. Reverse:
01110110
Answer provided by #george-dewar on Github. So a massive thank you to him. I would never have worked that out. Mine only differs in that my remote has less options and therefore less bytes to reverse and sum, otherwise it works exactly as George has it in his example code.