The page contains discoveries made while trying to understand the serial protocol used by LG air conditioners. LG machines often include a dongle which connects to the main indoor board. The dongle communicates using serial communication.
This work is in progress andI hope this can be helpful to other owners of LG units I will be glad to receive further information other users may decode based on this crude initial draft.
The connector is labeled as CN_LINK in my unit it is a 8 position female connector with male terminals. only 4 positions are in use with below clarifications:
- GND
- NC
- 12V
- NC
- LG TX - 5V
- LG RX - 5V
- NC
- NC
The physical connector is a rare type originating from South Korea SMh200-8H it uses a 2.0mm pitch
It may be possible to use the more widely known type JST HY which has the same pitch and somehow similar form factor.
The dongle and protocol seems to be common to a large variety of LG appliances, including dishwashers, fridges, kitchen hoods. in this page, i have only resarched about air conditioner.
The dongle uses a quite traditional 8N1 setting:
- 8 data bits
- no parity bit
- 1 stop bit
- 9600 bps
all values from serial line are in hexadecimal
There is a request response exchange, either dongle or AC can initiate the request. interestingly it seems to be full duplex, i.e. it is possible to send response to previous request and simultaneously listen to new requests.
There is always a 4 byte preamble 04 00 00 00
followed by a 3 byte command 0x65 0x02 0x01 (example for power off)
1 byte sequence number The sequence number is incremented for every subsequent request of the same kind remains at 0x00 for single time commands
- 1 byte length of payload This apparently restricts the payload length to 255 in my expereince the largest payload has been 124
The payload includes a set of 'type-lenght-value' data units.
- First 10 bits are for the data type (T)
- Subsequent 2 bit indicate the length (L) in byte of the value, valid values is mostly 0 and 1. Value of 0 means that only 2 bytes are used for the full TLV Value OF 1 means that 3 bytes are used for the full TLV data unit.
- remaining 4 bits are for encoding the value, which indicate 16 values in the most basic TLV.
To help identify the TLV, the full 2 bytes are used here in documentation although only the 10 first bytes define the type of data unit. To help documentation, It assumes that value is 0.
for example
- indoor temperature type is 7f 50
- setpoint type is 7f 90
The two last bytes are CRC16 checksum of the entire frame including preamble to payload. The CRC polynom is CRC-XMODEM
A complete switch off command has the below content: 0x04·0x00·0x00·0x00·0x65·0x02·0x01·0x00·0x02·0x7D·0xC0·0x73·0xC2
complete serial frame: 0x04·0x00·0x00·0x00·0x65·0x02·0x01·0x00·0x09·0x7D·0xC1·0x7E·0x40·0x7E·0x86·0x7F·0x90·0x2A·0x48·0x48
0x65·0x02·0x01
Sequence number is alway 0
value C1 for switch on value C0 for swtich off
cooling 40 dehum 41 fan-only 42 auto 43
Fan speed | Code |
---|---|
Auto | 88 |
1 | 82 |
2 | 83 |
3 | 84 |
4 | 85 |
5 | 86 |
For some reason either the type is on 2 bytes with value 1 byte or the value is 2 bytes with value one byte I have assumed that type is 2 bytes so far.
The value of temperature in C is hex_value / 2
Setpoint C | Encoding LG |
---|---|
21 | 2a |
22 | 2c |
23 | 2E |
24 | 30 |
25 | 32 |
26 | 34 |
27 | 36 |
28 | 38 |
29 | 3A |
0x04·0x00·0x00·0x00·0x65·0x02·0x01·0x00·0x02·0x7D·0xC0·0x73·0xC2
means request power off
0x04·0x00·0x00·0x00·0x87·0x02·0x10·0x00·0x00·0x77·0xE0 Above payload seems to be a 'standard' ack to a request from dongle
sent on regular basis
0x87·0x02·0x04
increments regularly as the AC sends command on regular basis
only one of the below payloads are seen with the command
0x7f·0x50·0x3d type 7F 50 The value of temperature in C is hex_value / 2 and result converted to decimal. Same as for setpoint. it only support .5 degree resolution.
Setpoint C | Encoding LG |
---|---|
21 | 2a |
22 | 2c |
23 | 2E |
24 | 30 |
25 | 32 |
26 | 34 |
27 | 36 |
28 | 38 |
29 | 3A |
This type and value is not identified
it is not known if this is one type 0x06 with value on 6 bytes or several types together. Complete frame: 0x04·0x00·0x00·0x00·0x87·0x02·0x04·0x87·0x03·0xCA·0xD0·0x8F·0x1B·0xA1
0x04·0x00·0x00·0x00·0x65·0x02·0x10·0x87·0x00·0x8A·0x60
is same as the initial request from AC (here 87)
no payload in response
65 02 10 no payload seems to acknoledge the update
roughly every 60s
0x04·0x00·0x00·0x00·0x87·0x01·0x02·0x01·0x02·0xAA·0x42·0x60·0x3E
0x87·0x01·0x02
seems to be always 0x01
AA 42 There is no information what t his means
0x04·0x00·0x00·0x00·0x65·0x01·0x01·0x02·0x02·0xAA·0xC1·0xCC·0xDB
0x04·0x00·0x00·0x00·0x65·0x01·0x02·0x01·0x02·0xAA·0xC1·0xB9·0xD5
it is not known what the payload means
0x04·0x00·0x00·0x00·0x87·0x01·0x10·0x01·0x00·0xDF·0x0D