Mitsubishi Heavy x-y line protocol

I am trying to understand Mitsubishi Heavy Air conditioner protocol. Its really interesting and different from other protocols than i have seen before.
Here i put some package examples
0xFB 0xFE 0xFE 0x7F 0xFE 0xFE 0xEF 0xFD 0xFB 0xFB 0xFE 0xFB 0xFE 0x7F 0xFE 0x7F 0x7F 0xF7 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFD 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFB 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0xF7 0xFD 0xFE vane 1
0xFB 0xFE 0xFE 0x7F 0xFE 0xFE 0xBF 0xFD 0xFB 0xFB 0xFE 0xFB 0xFE 0x7F 0xFE 0x7F 0x7F 0xF7 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFD 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFB 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0xDF 0xFD 0xFE
0xFB 0xFE 0xFE 0x7F 0xFE 0xFE 0xEF 0xFD 0xFB 0xFB 0xFB 0xFB 0xFE 0x7F 0xFE 0x7F 0x7F 0xF7 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFD 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFB 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0xF7 0xF7 0xFE

0xFB 0xFE 0xFE 0x7F 0xFE 0xFE 0xEF 0xFD 0xFB 0xFB 0xEF 0xFB 0xFE 0x7F 0xFE 0x7F 0x7F 0xF7 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFD 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFB 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0xF7 0xDF 0xFE
0xFB 0xFE 0xFE 0x7F 0xFE 0xFE 0xEF 0xFD 0xFB 0xFB 0xBF 0xFB 0xFE 0x7F 0xFE 0x7F 0x7F 0xF7 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFD 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFB 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0x7F 0x7F 0xF7 0xF7 0x7F 0xFE

Bytes only has one ‘0’ this shows the value of the byte
I think 3 bytes means only one value.

I have tested and i am sure these values are right.
0xfe means ‘0’ because ‘0’ is at the start of the byte.
the byte at the right is high byte and the left one is low byte.
every shifting to left on high byte increases the value +4
every shifting on low byte increases value +0,5
0xBF 0xEF setpoint 19 10111111 11101111
0xFE 0xDF setpoint 20 11111110 11011111
0xFB 0xDF setpoint 21 11111011 11011111
0xEF 0xDF setpoint 22 11101111 11011111
0xBF 0xDF setpoint 23 10111111 11011111
0xFE 0xBF setpoint 24 11111110 10111111
0xFB 0xBF setpoint 25 11111011 10111111
0xEF 0xBF setpoint 26 11101111 10111111
0xBF 0xBF setpoint 27 10111111 10111111
0xFE 0x7F setpoint 28 11111110 01111111
0xFB 0x7F setpoint 29 11111011 01111111
0xEF 0x7F setpoint 30 11101111 01111111

What i am trying to do is checksum calculation.
The last three bytes are changing if other bytes changes. I think the checksum is those bytes.
Do you have any idea how is calculated the checksum?
And this protocol is a common protocol?If yes what is the name of it?

Hi, i’ve been working over this procotol for a while and i have same questions like yours. Do you have any solution about your questions?

There are various checksum algoritms. Most common are crc16 (2 bytes) and crc32 (4 bytes). If your payload reacts with 3 bytes then none of above will fit easily. Have a look on Catalogue of parametrised CRC algorithms and Cyclic redundancy check - Wikipedia, maybe there you will find some hints on which algo would fit.

Best,
Łukasz

1 Like

I thing non of them is not fit for this protocol. Because there is only one ‘0’ bit in the bytes of packet. So, all results produced with standard crc algorithms doesn’t match with that rule and has more than one ‘0’ bit in the bytes.

  • 0x7F·0xF7·0xFE·0x7F·0xBF·0xF7·0xFB·0xEF·0xFB·0xFB·0xF7·0xFB·0xBF·0xDF·0xFB·0x7F·0x7F·0xF7·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFB·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFB·0xBF·0xFE·0xBF·0xFB·0xF7·0xFD·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFD·0xFB
  • 0x7F·0xDF·0xFE·0x7F·0xBF·0xF7·0xFB·0xEF·0xFB·0xFB·0xF7·0xFB·0xBF·0xDF·0xFB·0x7F·0x7F·0xF7·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFB·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xFB·0xBF·0xFE·0xBF·0xFB·0xF7·0xFD·0xFE·0xFE·0xFE·0xFE·0xFE·0xFE·0xF7·0xFB

The 2 packets above have only one byte difference. (bolded)
The difference is that, ‘0’ bit of F7 is shifted 2 bits left.
F7(11110111)
DF(11011111)
And the last 3 bytes of packet reacted the change same way.(2 bits lefted)
FD(11111101)
F7(11110111)
Also, i recognized that. If we think 48 bytes of packet like 3 bytes of group and which order of them is change, same order of last 3 bytes is changed.
I guess, last 3 bytes are calculated according to shifted bit count?

Where are you sniffing the packages ?
Intesis / Airconwithme are offering WiFi adapters for the Mitsibishi Heavy Duty series which have been successfully implemented with the Intesis Binding….

I have a homebus to ttl converter hardware and i’ve got log the packets with logic analyser. The packets can be sniffed as serial data 8e1 9600 baud.
I know intesis. But i try to do my own gateway.

1 Like

Maybe have a look on GitHub - absalom-muc/MHI-AC-Ctrl: Reads and writes data (e.g. power, mode, fan status etc.) from/to a Mitsubishi Heavy Industries (MHI) air conditioner (AC) via SPI controlled by MQTT. This repository links even older one which does mhi2mqtt which seems to be simplest possible thing. Maybe based on these two you will be able to go forward.

1 Like

I’ve been checked them but they are different protocol what communicates over SPI.
Actually the connector(CNS) mentioned in the project for a module what convert SPI to remote controller connector and the connector(CNS) is found over mainboard of split climates with has only IR controller (defaultly has no remote controller). https://www.greenspirit.ee/en-gb/sc-bikn-e
The protocol which is examined here is X Y protocol, and XY protocol has different connector, different bus layer(similar homebus) and mostly used for VRF climates.

Seems inverted to me. Increasing temperature while bytes decrease could also point in this direction.

Please invert your signal and test again.

Best luck
Sascha

I figured out finaly this protocol :slight_smile:

Each byte(hex) of packet represent a number. This number is found like that, how many times the zero bit is shifted in the byte.
0xFE (1111 1110) : 0
0xFD (1111 1101) : 1
0xFB (1111 1011) : 2
0xF7 (1111 0111) : 3

This founded number is actually 3 bits of a finalbyte and ordered lsb first. So, totally 3 bytes of packet provide 1 finalbyte (totally 9 bits = 8data + always’0’bit).
For example,

|----------|----|----|----|
|bytes     |0x7F|0xF7|0xFE|
|represent |  7 |  3 |  0 |
|bits      |111 |110 |000 |
            LSB        MSB
|-------------------------|
finalbyte = 00011111 = 0x1F

So, with this information, the packet size is reduced to 48/3=16.
new packet type = data[0:14],checksum[15]
and checksum = sum(0:14)%256

Best

1 Like