Mitsubishi Heavy x-y line protocol

ofc · October 3, 2019, 8:04am

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?

HamdiOlgun · April 4, 2022, 4:09pm

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?

splatch · April 4, 2022, 5:19pm

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

HamdiOlgun · April 5, 2022, 6:33am

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?

hmerk · April 5, 2022, 7:12am

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….

HamdiOlgun · April 5, 2022, 7:29am

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.

splatch · April 5, 2022, 8:08am

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.

HamdiOlgun · April 5, 2022, 9:23am

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.

Sascha_ · April 6, 2022, 6:22am

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

HamdiOlgun · April 6, 2022, 7:13am

I figured out finaly this protocol

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

iblue · October 31, 2023, 10:03pm

Here is my work. It should at least give some clues. https://github.com/iblue/mhi-xy-bus/blob/main/report.pdf

isikli · March 15, 2024, 1:15pm

I have reviewed your work and it has been very heplful to me, thank you. But ı didnt understand which bytes the receiver and sender addresses are located in data packet.

Your work includes receiver address (1:2 bytes), but i couldnt find any information about the sender address. Is there no information containing the sender address in the 48-byte main data packet ?

I research the X-Y line find that:

This logic signals inside 3 pieces 48 bytes data. The pattern is like this. I think first 48 byte packet belong to remote controller and second 48 byte packet belong to air condition. I dont know third 48 byte packet.

This datas is as follows:

[1. packet] FE FE FE 7F FE FE …(temp,mode,flap,venti)…checksum
[2. packet] FE FE FB FD FE FE …(temp,mode,flap,venti)…checksum
[3. packet] ?

I applied final byte formula you said.
[1. packet] FE FE FE 7F FE FE
0 0 0 7 0 0
000 000 000 111 000 000
00000000 00000111
0x0007

[2. packet] FE FE FB FD FE FE
0 0 2 1 0 0
000 000 010 001 000 000
10000000 00000001
0x8001

I checked my 1:2 bytes and see 0x0007(air cond. address) and 0x8001(remote cont. address). In this case my air condition address is 0 an this is true. But ı changed air condition address ( i use rc-e5 remote cont.). My air condition address 2 now and i listened the logic signals.

The address bytes of my first and second packets have changed. My expectation was that only one of them would change because I thought the remote control address would remain constant.

This is new packet:

[1. packet] FB FE FE 7F FE FE
2 0 0 7 0 0
010 000 000 111 000 000
00000010 00000111
0x0207

[2. packet] FB FE FB FD FE FE
2 0 2 1 0 0
010 000 010 001 000 000
10000010 00000001
0x8201

I’m getting confused here. 2. packet must be 0x8001 because it is remote control. The control address should not have changed… But it is changed. Why ? Could you please explain to reason?