The Daikin has an S21
and S403
port which talks the S21
protocol. This is not documented by Daikin, and so all of this document is based on reverte engineering and testing.
- The protocol has a common format, but the exact messages and features are not the same from model to model, so not all work on all models.
- The reverse engineering is far from complete, and may have errors, but the idea is to update this document, and in particular to cover the usage of
S21
protocol by the Faikin code. - Some settings are in more than one place, so different on different models!
The physical interface is basic serial data, low is 0
, high is 1
. However the Daikin appears to operate with a 5V internal pull up on Tx and Rx lines, and a pull down. The Faikin uses a FET each way, which means internally the lines are inverted.
The S403
port is a non-isolated S21
port, i.e. it is at MAINS POWER levels, and dangerous. Any connected device, such as a Faikin, needs to be inside the case.
The S21
port pin out is 1:1 the same as the Faikin pin out :-
Pin | Meaning |
---|---|
1 |
5V reference. If connected to the Faikin, it is used as a pull up for Tx line. Not always connected. |
2 |
Tx (from aircon) |
3 |
Tx (to aircon) |
4 |
Power, notionally 12V, used to power the Faikin. Faikin can handle 4V to 35V. |
5 |
GND |
Note that pin 1 is usually marked with a triangle/arrow, and unusually it is not GND.
The serial data is 2400 Baud, 8 bit data, even partity, 2 stop bits.
The packet format uses ASCII a lot, but not entirely. The payload design avoids clashes with STX/ETX for example. The basic packet format is :-
Example packet | |
---|---|
02 |
STX (start of packet) |
46 |
First byte of packet type, e.g. F |
51 |
Second byte of packet type, e.g. Q |
Additional bytes of payload, normally none or 4 bytes/characters, avoiding 00 -1F bytes by design |
|
97 |
Checksum |
03 |
ETX (end of packet) |
The checksum is the sum of all bytes after the initial 02
STX byte, to end of payload. But if this is ETX (03
) then ENQ is used instead (05
). This avoids ever seeing ETX (03
) within a packet.
The payload is empty for some simple poll requests, and in almost all other cases is 4 bytes/characters.
The other end then sends an ACK (06
) byte if OK, or NAK (15
) if not OK.
The 4 byte/characteer payloads are used to convery various types of data.
- Simple number, e.g. a character
0
to7
for a status, each number having a meaning. - Value coding, e.g. a character
@
± value, e.g. for temp@
is 18.0℃,A
is 18.5℃, but can also be negative, so?
is 17.5℃ - More complex valuue, e.g. fan speeds can be
3
to7
but alsoA
orB
- Bigger number, e.g. a character
In some cases the character can contain bits. This is based on 0
. This allows bits 0, 1, 4, 5, 6, or even 7, to be used based on 30
(0
chartacter).
In some cases a numeric value is conveyed as 4 characters, but they are backwards, and have a +
or -
, so 581+
means +185
which means 18.5℃. There are also cases where this is just a value, e.g. 001+
may be 100° angle of a vent.
In somde cases a numeric value is hexadecimal, and again backwards, so 25A3
means 0x3A52
which is 14930.
The general operation is that the controller sends a message (which gets an ACK), and the aircon sends a response message (which the controller ACKs).
The request can be a simple poll for data, which gets a status response message, or could be a command to change a value.
The commands starting F
are used to poll for responses starting G
. However you can also send a command starting D
to set the value. The format for the G
response and D
command are the same. These are generally settings, but in some cases sensors.
Using D
to set a value results in next F
poll returning the G
response with the new value. However, in some cases the selected value cannot be accepted by the aircon, in which case it is not returned as new value. It may be returned as old value, or may be limited, e.g. setting a target set-point out of range will usually end up set to the max/min that is allowed. It is also possible for settings to change independantly, e.g. via IR remote, etc.
D /G Meaning |
|
---|---|
1 |
Main control mode: power/mode/set-point/fan |
3 |
Auto start/stop logic |
5 |
Swing/vents |
6 |
Additional settings: powerful mode |
7 |
Additional settings: Econo mode |
9 |
Course temp measurement: inside/outside |
H |
? |
The commands starting R
are used to poll for responses starting S
. These are normally sensors.
S Meaning |
|
---|---|
H |
Inside temp |
a |
Outside temp |
X |
Set point temp |
N |
? another temp |
The following are the known payloads. Where settings have more than one place (e.g. econo) you can usually work it out on basis that one of the controls does not exist (NAK) and the other does. So you can tell based on which D
commands work and which do not.
Byte 0 | Byte 1 | Byte 2 | Byte 3 | |
---|---|---|---|---|
G1 |
Bit 0: Power on | Mode | Set point (@ based) |
Fan mode |
G3 |
Bit 1: Powerful | |||
G5 |
Bit 0: V-Swing, Bit 1: H-SWing | |||
G6 |
Bit 1: Powerful, Bit 6: comfort, Bit 7: Quiet | Bit 7: Streamer | Bit 3: Sensor, Bit 2+3: LED | |
G7 |
Demand ('0'+0-100) | Bit 1: econo | ||
G9 |
Home temp (@ based) |
Outside temp (@ based) |
||
GM |
Hex, Wh total energy usage | |||
SL |
Fan rpm, numeric (multiply by 10 for rpm) | |||
Sd |
Compressor rate, numeric | |||
SN |
Vertical swing angle | |||
SH |
Home temp, numeric (0.1℃ steps) | |||
Sa |
Outside temp, numeric (0.1℃ steps) | |||
SI |
Liquid temp, numeric (0.1℃ steps) |