S21 Protocol

The "S21 protocol" is the name given to the serial protocol used by Daikin indoor units over what the service manual calls the "HA connector" (which corresponds to header S21 on most boards), used to connect wired thermostats and Wi-Fi controllers to residential mini-split installations. It was reverse engineered by inspecting the flows going between indoor air conditioning units and the standard wifi controllers, as well as by sending arbitrary queries to see how the unit reacts or how the results change over time. This is an older protocol, but one which there is some documentation on the Internet.

Commercial and multi-split units, like the Daikin VRV, SkyAir or Altherma lines, will usually use the P1P2 protocol instead, while ducted HVAC units (called "Unitary" by Daikin One) likely have their own different protocol.

Data Packets

The data is a simple 8-bit serial at 2400 baud, even parity, two stop bits.

The packet format uses ASCII a lot, and each packet starts with STX (0x02), ends with ETX (0x03) and gets an ACK (0x06) response. Very crude.

Packet format (example request)

Hex	Description
02	Packets start 02 (STX)
46	Indicates some sort of request, “F”, also seeing 52 “R”, and 44 “D”
46	Request code - this is "Q", seems to always be ASCII
	Additional payload - often seems to be ASCII, but not always
97	Sum of bytes after 02 to end of payload
03	Packets end 03 (ETX)

Acknowledgement

Hex	Description
06	Ack

Packet format (example reply)

Hex	Description
02	Packets start 02 (STX)
47	Indicates reply, “G”, one more than request, also seen 53 “S”, and 45 “E”
51	Matching request code - this is “Q”
31 44 30 30	Payload. This example is 1D00
6D	Sum of bytes after 02 to end of payload
03	Packets end 03 (ETX)

Acknowledgement

Hex	Description
06	Ack

Since certain bytes have special meaning, they cannot be present in data payload. These bytes include: 02(STX), 03(ETX), 06(ACK), 0A, 15(NAK). In order to prevent these values from appearing in data stream, Daikin adds some bits, which we call "shield bits" below. Most often these constitute a value of 0x30, which is ASCII for '0'. Therefore in many cases (but not all) data bytes can also be interpreted as valid ASCII.

Commands

Warning

This page documents current knowledge of how the protocol works, but a lot of what these commands do and mean is still unknown.

Majority of command codes consist of two characters. However this rule has exceptions:

• FUxx, FYxx - v3 protocol commands with extended 4-character codes
• M - 1-character code, probably obsolete, but Daikin controllers still query it .

Most commands have no request payload, apart from F/U which is seen with strings 02 and 04.

Protocol versions

There appear to be different versions of the S21 protocol supported by different units. The protocol version appears to determine which commands a unit is known to respond to, and official controllers will alter their behavior based version probing. The list of supported R commands doesn't seem to vary across versions.

For version 2 and below FY00 command isn't supported and causes a NAK response. In this case protocol version is indicated by older F8 and corresponding D8 response. Note that for protocol v3 and above this command still indicates version 2, probably for backwards compatibility with some old software.

Version 3 and beyond is indicated by FY00 command. The response code is GY00, returned version may affect the meaning and/or presence of various other commands.

Additionally, F2, FK, and FU00 commands, if supported. are used to query for optional features supported by the unit.

BRP069B41 also has own protocol version; reported in /aircon/get_model_info as cpv= and cpv_minor= parameters. The controller tries to match own version against reported by the conditioner; and uses lowest common demoninator. For example, with version set to 3.10 in the simulator: pv=3.10,cpv=3,cpv_minor=01 . This means it treats the simulated A/C as conforming to version 3.01, which it knows, despite a higher number has been reported. Based on this we can understand which versions can be seen in the wild. The following version numbers have been found to be recognized by BRP069B41: v0, v2, v3.00, v3.01, v3.20.

Note

Note the model number nomenclature that Daikin follows when adding a model to the list. The first 4 letters denote the device class, not the revision.

Note

Below commands, queried by BRP069B41 controller are listed in their order. This gives a good overview of which commands are actually known by the controller and officially used by Daikin. [sensor] denotes one R family command out of sensor query sequence (TBD). I. e. the controller asks one particular each poll iteration. On next iteration next sensor will be queried.

Note

DJ and D7 commands aren't understood. DJ payload varies (saw also DJ2010 and DJ2030). It's unclear what it depends on. Maybe daytime after all ?

Protocol version 0

• "F8" result: "G8 '0' 0x00 0x00 0x00
• "FY00" result: NAK
• Reported BRP069 protocol version: pv=0,cpv=0,cpv_minor=00
• Known models: FTXS**L, FTXS**G
• Supported R commands: RA, RB, RC, RD, RE, RF, RG, RH, RI, RK, RL, RM, RN, RW, RX, Ra, Rb, Rd, Re, Rg, Rz
• Supported F commands: F1, F2, F3, F4, F5, F8
• Supported miscellaneous commands: A, M, V
• BRP069B41 startup sequence: F2 F1 F3 F4 F5 F8 RH Ra M
• BRP069B41 polling loop: F2 F1 F3 F4 F5 F8 [sensor]
• BRP069B41 sensor polling sequence: TBD

Protocol version 2.0

• "F8" result: G8 '0' '2' 0x00 0x00
• "FY00" result: NAK
• Reported BRP069 protocol version: pv=2,cpv=2,cpv_minor=00
• Known models: ATX20K2VTB
• Supported R commands: RA, RB, RC, RD, RE, RF, RG, RH, RI, RK, RL, RM, RN, RW, RX, Ra, Rb, Rd, Re, Rg, Rz
• Supported miscellaneous commands: A, M, V, VS000M
• BRP068B41 startup sequence: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FC FY00 M DJ2010
• BRP068B41 polling loop: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT [sensor]
• BRP068B41 sensor polling sequence: TBD

FY00 is used to distinguish between v2 and v3 protocols (see F8 description). v2 protocol units respond with NAK
If model code, returned by FC is '0000' (the case on ATX20KV1B), FY00 command is skipped completely.

Protocol version 3.00

• "F8" result: "G8" '0' '2' 0x00 0x00
• "FY00" result: "GY00 0030"
• Reported BRP069 protocol version: pv=3.00,cpv=3,cpv_minor=00
• Known models: S22ZTES-W
• BRP069B41 startup sequence: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FC FY00 FY10 FY20 M DJ2030 DJ2010
• BRP069B41 polling loop: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT [sensor]
• BRP069B41 sensor polling sequence: TBD

Protocol version 3.10

• "F8" result: "G8 0200"
• "FY00" result: "GY00 0030"
• Reported BRP069 protocol version: pv=3.00,cpv=3,cpv_minor=00
• Known models: None; found by probing on BRP069
• BRP069B41 startup sequence: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FC FY00 FY10 FY20 M VS000M DJ4030
• BRP069B41 polling loop: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT [sensor]
• BRP069B41 sensor polling sequence: TBD

Protocol version 3.20

• "F8" result: "G8 0200"
• "FY00" result: "GY00 0230"
• Reported BRP069B41 protocol version: pv=3.20,cpv=3,cpv_minor=20
• Known models: FTXF**D, FVXM**?, FVXM**A
• BRP069B41 startup sequence: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FC FY00 FY10 FY20 FU00 FU02 VS000M DJ5010 D70000
• BRP069B41 polling loop: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FU02 FU04 [sensor]
  
• BRP069B41 sensor polling sequence: TBD
• BRP069C41 startup sequence: F2 F1 F3 F4 F5 F8 F9 F6 F7 FB FG FK FM FN FP FQ FS FT FC FY00 FY10 FY20 FU00 FU02 VS000M Rd RL RH RN RI Ra RX FX00 FX10 FX20 FX30 FX40 FX50 FX60 FX70 FX80 Rz52 Rz72 FX90 FXA0 FXB0 FXC0 DY10 DY20

Note

Versions higher than 3.20 are only supported by "new" Daikin controllers, which are cloud-only and don't have local API (at least full implementation) Therefore information, specific to online controller's HTTP API is not available any more. BRP069C41 controller is used for testing those.

Protocol version 3.40

• "F8" result: "G8 0200"
• "FY00" result: "GY00 0430
• Reported BRP069B41 protocol version: pv=3.40,cpv=3,cpv_minor=20
• Known models: FTXM**R
• BRP069C41 startup sequence: TBD
• BRP069C41 polling loop: TBD
• BRP069C41 sensor polling sequence: TBD

Commands support matrix for different protocols.

"BRP069" column indicates whether a command is used by original Daikin controller. "Optional" means that the command is not mandatory, and the A/C is allowed to respond NAK. "Rudimentary" means that the command is supported, but the response looks like a stub and most likely not used.

Command	Response	Payload length	Semantics	v1	v2	v3	BRP069	Notes
A	C	1 (i.e. x)	Ping ?	?	Yes	Yes	No	Replies back with the same payload. On payloads longer than 1 byte replies something.
M	M	4	Supposedly model code for protocol v1	Yes	Rudimentary	Rudimentary	<=v2	Reports 'FFFF' (ASCII) for v2+ conditioners. BRP069B41 queries but appears to ignore it.
V	V	4			Yes	Yes	No	4 digit hex, seems constant per unit
VS000M	VS	14	Indoor unit firmware version		Yes	Yes	>=v3.01	Only polled once
D3	N/A	3	Set on/off timer		Yes	Yes	No
D7	N/A	4	Unknown		Yes	Yes	>= v3	Payload: '0000' ASCII
DJ	N/A	4	Unknown		Yes	Yes	Yes
DL	N/A	4	Unknown			Yes	Yes	Payload: '0000' ASCII
DR	N/A	4	Set louver angle	?	Yes	Yes	No
DY10	N/A	8	Unknown			Yes	>=v3.00	Payload: 41 38 44 33 36 36 36 46
DY20	N/A	4	Unknown			Yes	>=v3.00	Payload:
F1	G1	4	Power, mode, setpoint, fan speed setting	Yes	Yes	Yes	Yes
F2	G2	4	Optional features	Yes	Yes	Yes	Yes
F3	G3	4	On/off timer. "Powerful" mode on some models (?)	Yes	Yes	Yes	Yes
F4	G4	4	Error status(?)	Yes	Yes	Yes	Yes
F5	G5	4	Swing, humidity setting	Yes	Yes	Yes	Yes	Supported values depend on optional features, see F2
F6	G6	4	Powerful, Comfort, Quiet, Streamer, Sensor modes' LED control		Partial	Yes	Yes	See description for protocol version details.
F7	G7	4	Demand mode, econo mode	No	Yes	Yes	Yes
F8	G8	4	Protocol version (up to v2)	Yes	Yes	Rudimentary	Yes
F9	G9	4	Coarse indoor, outdoor temperature (℃), humidity (%)	No	Yes	Yes	Yes	Format: bytes 0, 1 are 0x80 + value/2. Byte 2 is '0' + value. Meaning: Byte 0: indoor temperature in C (granularity of 1C, rounded down), byte 1: outdoor temperature in C (granularity of 1C, rounded down), byte 2: indoor humidity in units of 1% (granularity of 5%, rounded down). e.g. 0xac:aa:4e:30 22C inside, 21C outside, 30% humidity
FA	GA	4		No	Yes	Yes	No
FB	GB	4		No	Yes	Yes	Yes
FC	GC	4	Model code	No	Yes	Yes	Yes	Only polled once. First byte appears to indicate unit size/capacity
FG	GG	4	IR remote counter	No	Yes	Yes	Yes	increments on each IR command
FK	GK	4	Optional features (v2+)	No	Yes	Yes	Yes
FL	GL	4		No	Yes
FM	GM	4	Power consumption	No	Yes	Yes	Yes	4 digit ASCII encoded hex number in reverse- indicates total Wh/10
FN	GN	4	ITELC. Some Daikin internal code.	No	Yes	Yes	Yes
FP	GP	4		No	Yes	Yes	Yes
FQ	GQ	4		No	Yes	Yes	Yes
FR	GR	4	Louver position setting	No	Yes	Yes	Yes
FS	GS	4		No	Yes	Yes	Yes
FT	GT	4	Unknown	No	Yes	Yes	Yes	potentially outdoor unit capacity in units
FU00	GU00	32	Optional v3+ features	No	No	>=v3.20	>= v3.20	Only polled once.
FU02	GU02	32	Allowed temperature ranges	No	No	Yes	>= v3.01
FU04	GU04	32	Unknown	No	No	>=v3.20	>= v3.20
FU05	GU05	32	Model name	No	No	>=v3.40
FU15	GU05	32	Production information	No	No	>=v3.40
FU25	GU05	32	Production order	No	No	>=v3.40
FU35	GU05	32	Indoor unit production information	No	No	>=v3.40
FU45	GU05	32	Outdoor unit production information	No	No	>=v3.40
FV	GV		Unknown	No ?	No ?	>= v3.01 ?	No	Found by brute-forcing; tested on FTXF20D5V1B (v3.20), S22ZTES-W (v3.00) and ATX20K2V1B (v2)
FX00	GX00	2	Unknown	No	No	Optional	Yes
FX10	GX10	2	Unknown	No	No	Optional	Yes
FX20	GX20	4	Unknown	No	No	Optional	Yes
FX30	GX30	2	Unknown	No	No	Optional	Yes
FX40	GX40	2	Unknown	No	No	Optional	Yes
FX50	GX50	2	Unknown	No	No	Optional	Yes
FX60	GX60	4	Unknown	No	No	Optional	Yes
FX70	GX70	4	Unknown	No	No	Optional	Yes
FX80	GX80	4	Unknown	No	No	Optional	Yes
FX90	GX90	4	Unknown	No	No	Optional	Yes
FXA0	GXA0	4	Unknown	No	No	Optional	Yes
FXB0	GXB0	2	Unknown	No	No	Optional	Yes
FXC0	GXC0	2	Unknown	No	No	Optional	Yes
FXD0	GXD0	8	Unknown	No	No	Optional (>=3.40)	Yes
FXE0	GXE0	8	Unknown	No	No	Optional (>=3.40)	Yes
FXF0	GXF0	8	Unknown	No	No	Optional (>=3.40)	Yes
FX01	GX01	8	Unknown	No	No	Optional (>=3.40)	Yes
FX11	GX11	8	Unknown	No	No	Optional (>=3.40)	Yes
FX21	GX21	2	Unknown	No	No	Optional (>=3.40)	Yes
FX31	GX31	8	Unknown	No	No	Optional (>=3.40)	Yes
FX41	GX41	8	Unknown	No	No	Optional (>=3.40)	Yes
FX51	GX51	4	Unknown	No	No	Optional (>=3.40)	Yes
FX61	GX61	2	Unknown	No	No	Optional (>=3.40)	Yes
FX71	GX71	2	Unknown	No	No	Optional (>=3.40)	Yes
FX81	GX81	2	Unknown	No	No	Optional (>=3.40)	Yes
FY00	GY00	4	Protocol version (v3+)	No	No	Yes	Yes	Only polled once
FY10	GY10	8	Unknown	No	No	Yes	Yes	Only polled once
FY20	GY20	4	Unknown	No	No	Yes	Yes	Only polled once
RA	SA	1	Power on/off	Yes	Yes	Yes	No
RB	SB	1	Current indoor unit mode?	Yes	Yes	Yes	No	One ASCII digit, using the same mapping as F1. Seems to always reflect the setting from F1, even if the mode is changed while the unit is off.
RC	SC	4	Temperature set point	Yes	Yes	Yes	No	4 digit ASCII encoded signed decimal in reverse e.g. "542+" for 24.5C
RD	SD	3	On timer setting	Yes	Yes	Yes	No
RE	SE	3	Off timer setting	Yes	Yes	Yes	No
RF
RG	SG	1	Fan mode	Yes	Yes	Yes	No	"A" = auto (or night on some models), "B" = night mode (on other models), "1" through "7" for fixed speeds
RH	SH	4	Indoor temperature	Yes	Yes	Yes	Yes
RI	SI	4	Liquid temperature	Yes	Yes	Yes	Yes
RK	SK	3	Fan set point	Yes	Yes	Yes	No
RL	SL		Fan speed	Yes	Yes	Yes	Yes
RM	SM	4	Louvre angle set point	Yes	Yes	Yes	No
RN	SN	4	Vertical swing angle	Yes	Yes	Yes	Yes
RW	SW	2		Yes	Yes	Yes	No
RX	SX		Target temperature (not set point, see details)	Yes	Yes	Yes	Yes
Ra	Sa	4	Outside temperature (0.5C granularity)	Yes	Yes	Yes	Yes
Rb	Sb	3	Indoor frequency command signal	Yes	Yes	Yes	No
Rd	Sd	3	Compressor frequency	Yes	Yes	Yes	Yes
Re	Se	3	Indoor humidity (1% granularity)	Yes	Yes	Yes	No
Rg	Sg	1	Compressor on/off	Yes	Yes	Yes	No
Rz	Sz	4	System state/System query?	Yes	Yes	?	No	Empty reply on my FTXF20 (v3), but was turned off

Data formats

All multi-byte values are transmitted in little-endian rather than in wire order. That means a command with a result of "GM 1D00" is to be interpreted as having returned "00D1".

A number of data formats are used more than once.

Plain decimal number

Example value: Wire "300", Rectified "003", Interpreted 3

Just a regular ASCII number string. Used for things like fan speed and humidity sensors. There's never any actual decimal separator, but one may be implied.

Signed decimal number

Example value: Wire "720+", Rectified "+027", interpreted +27

ASCII number string with the sign always present. Used for things like temperature sensors and fin angle.

Hexadecimal number

Example value: Wire "B233", Rectified "332B", Interpreted 13099

Hexadecimal number as an ASCII string, more compact than the decimal one. Used for things like lifetime power consumption.

Operating mode

ASCII character representing what an indoor or outdoor unit is doing or should be doing.

Value	Mode
"0"	Idle/Off?
"1"	Auto
"2"	Dry
"3"	Cool
"4"	Heat
"6"	Fan

Fan speed setting

ASCII character representing one of the fan speed modes that the remote control can set.

Value	Mode
"3"	Low
"4"	Mid-low
"5"	Medium
"6"	Mid-high
"7"	High
"A"	Auto
"B"	Night/Quiet

Compact temperature setting

ASCII character representing a setpoint temperature that a remote can send to the unit.

Value	Meaning
"@"	18.0C
"A"	18.5C
…
"W"	29.5C
"X"	30.0C
0x80	N/A (for dry mode)

State setting commands (D*)

Commands, starting with D, change control values of the conditioner. They are sent together with the payload; the reply is simple ACK or NAK (if not supported).

D1 command

Set the power, mode, temp, and fan rates.
Payload length: 4 characters

Pos	Description	Values
1	Power	0: 0ff 1: On
2	Mode	0: ? 1: Auto 2: Dry 3: Cool 4: Heat 6: Fan 7: Auto (reported in status)?
3	Temp	@: 18.0C A: 18.5C … W: 29.5C X: 30.0C 0x80: N/A (for dry mode)
4	Fan	3: Low … 7: High A: Auto B: Quiet or Q for Night?

D2 command

The D2 command is unknown. It has a 1 character payload.

Pos	Description	Values
1	Unknown	0

D3 command

Set on/off timer
Payload size: 3 bytes

Sets on/off timer value. Payload is exactly the same as first 3 bytes, reported by F3:

• byte 0:
  • Bit 0 - On timer is set
  • Bit 1 - Off timer is set
  • Bits 4, 5 - shield bits, making up 0x30 (ASCII '0')
• byte 1 - On timer setting
• byte 2 - Off timer setting

Timer settings range from 1 to 12 hours, and corresponding values are: 0x36, 0x3C, 0x42, 0x48, 0x4E, 0x54, 0x5A, 0x60, 0x66, 0x6C, 0x72, 0x78. In other words, time value starts from 0x30 (which would be 0), then one hour equals to an increment of 6. This gives an idea that perhaps timer granularity is 10 minutes (1/6 of hour), but it's unclear if the unit would accept them properly.

D5 command

The D5 command controls the louver swing. It has a 4 character payload.

Pos	Description	Values
1	Swing	0: Off 1: Vertical swing 2: Horizontal swing 7: Both swing
1	Swing?	0: Off ?: On
1	Unknown	0
1	Unknown	0

D6 command

The D6 command controls the “powerful” setting. It has a 4 character payload.

Pos	Description	Values
1	Powerful	0: Off 2: On p: Comfort
2	Unknown	0
3	Unknown	0
4	Unknown	0? 4?

This command is optional for v2 conditioners. ATX20K2V1B does not support it, returning NAK.

D7 command

The D7 command controls the “econo” settings. It has a 4 character payload.

Pos	Description	Values
1	Unknown	0
2	Econo	0: Off 2: On
3	Unknown	0
4	Unknown	0

DH command

The DH command is unknown.

Pos	Description	Values
1	Unknown	1
2	Unknown	1
3	Unknown	0
4	Unknown	0

DJ command

Purpose unknown
Payload length: 4 bytes

This command is send by BRP069B41 controller on startup. The payload is sometimes '2010' and sometimes '2030' ASCII. The effect is the following:

1. Byte 2 bit 7 in F2 is set to 1
2. Byte 3 in F3 is changed from 0x00 to 0x30

Query commands

The following commands have no payload, when sent to the conditioner. They are used to query various values, and produce a response, whose body contains values requested

DR command

Set louver angle Payload length: 4 bytes

• byte 0 ASCII character. Louver position to set. Values are the same as per FR byte 0. Writing '?' turns on vertical swing (at least on my ATX20K2V1B, equivalent to sending D5 with respective value); and writing '0' stops the swing (it it was on), leaving the louver where it was (equivalent to disabling swing via D5).
• byte 1 - 3 - have only seen '0's, look like reserved.

State reading commands (F*)

F2 command

Query optional features
Response format: G2 [byte0] [byte1] [byte2] [byte3]
Payload bytes are bit masks:

• byte0
  • bit 0 - Unkown. set to 1 on CTXMxxRVMA, ignored by BRP069B41
  • bit 1 - Zero
  • bit 2 - Swing (any kind) is avaiiable
  • bit 3 - Horizontal swing is available
  • bit 4 - Shield bit (0x30)
  • bit 5 - Shield bit (0x30)
  • bit 6 - Zero
  • bit 7 - Zero
• byte1
  • bit 0 - Unkown. set to 1 on CTXMxxRVMA, ignored by BRP069B41
  • bit 1 - Awlays 1, unknown
  • bit 2 - Zero
  • bit 3 - Unknown. Reflected by BRP069B41 in aircon/model_info. 0 => type=C, 1 => type=N
  • bit 4 - Shield bit (0x30)
  • bit 5 - Shield bit (0x30)
  • bit 6 - Zero
  • bit 7 - Zero
• byte2 - seen to be 0x00 on startup
  • bit 7 - Set to 1 by DJ command. Purpose is unknown.
• byte3
  • bit 0 - Zero
  • bit 1 - "humidity" operation mode is available
  • bit 2 - Zero
  • bit 3 - Zero
  • bit 4 - Humidity setting is available for additional operation modes (see matrix below)
  • bit 5 - Zero
  • bit 6 - Zero
  • bit 7 - Always 1. Perhaps shield ?

Humidity settings availability matrix (reverse engineered from Daikin online controller app)
s_humd is a per-mode bitmask, presented by BRP069B41 in /aircon/model_info

bit 4 = 0, bit 1 = 0; s_humd=0
Humidity settings not available

bit 4 = 1, bit 1 = 0; s_humd=146 (0x92)

Mode\Setting	Off	Low	STANDARD	High	Continuous
Auto	-	-	-	-	-
Cool	y	y	y	y	y
Heat	-	-	-	-	-
Fan	-	-	-	-	-
Dry	y	-	y	y	y

bit 4 = 0, bit 1 = 1; s_humd=165 (0xA5)

Mode\Setting	Off	Low	STANDARD	High	Continuous
Auto	y	y	y	y	y
Cool	-	-	-	-	-
Heat	y	y	y	y	y
Fan	-	-	-	-	-
Dry	-	-	-	-	-
Humidify	y	-	y	y	y

bit 4 = 1, bit 1 = 1; s_humd=183 (0xB7)

Mode\Setting	Off	Low	STANDARD	High	Continuous
Auto	y	y	y	y	y
Cool	y	y	y	y	y
Heat	y	y	y	y	y
Fan	-	-	-	-	-
Dry	y	-	y	y	y
Humidify	y	-	y	y	y

F3 command

On-off timer
Response format: G3, payload size: 4 bytes

• byte 0:
  • Bit 0 - On timer is set
  • Bit 1 - Off timer is set
  • Bits 4, 5 - shield bits, making up 0x30 (ASCII '0')
• byte 1 - On timer setting
• byte 2 - Off timer setting
• byte 3 - Reports 0x00 after bootup, changed to 0x30 by DJ. Meaning unknown.

Timer settings range from 1 to 12 hours, and corresponding values are: 0x36, 0x3C, 0x42, 0x48, 0x4E, 0x54, 0x5A, 0x60, 0x66, 0x6C, 0x72, 0x78. In other words, time value starts from 0x30 (which would be 0), then one hour equals to an increment of 6. This gives an idea that perhaps timer granularity is 10 minutes (1/6 of hour), but it's unclear if the unit would accept them properly.

On majority of units if the timer is disabled, the respective setting bytes are set to 0xFE. However, on ATX20K2V1B and S22ZTES-W they read as 0x30 in this case. Experiments with BRP069B41 controller on simulator show that it doesn't accept response of 0x30 0x30 0x30 0x00; it sends NAK and keeps retrying, falling into "SERIAL IF FALURE" state. It's also known that this controller actually works with ATX20K2V1B. I tried snooping boot process on my ATX20K2V1B; that yielded no clue. The response on bootup is 0x30 0x30 0x30 0x00; and everything works just fine.

According to commit 0c5f769894365d344012b36846f0b91023840d94 on some models bit 1 of byte 3 is used as "Powerful" mode flag. Those models apparently do not support F6 command, but unfortunately there's no information on which exact model that is. Given the above, that could be a mistake.

F4 command

Response code: G4, payload length: 4 bytes

• byte0: 0x30 ('0')
• byte1: 0x00
• byte2
  • Bit 5: Conditioner internal error flag. If reported as 1, BRP069B41 only polls 4 commands F1-F3-F4-F2 and reports in /aircon/model_info:
    ret=SERIAL IF FAILURE,err=252
    Experiments show, that once read, the bit resets to 0. It's not known which actions cause it to raise.
• byte3: 0x30 ('0')

F6 command

Special modes status
Response code: G6, payload length: 4 bytes

• byte 0: Special modes.
  • bit 2 - "Powerful" mode on
  • bit 6 - "Comfort" mode on
  • Bit 7 - "Quiet" mode on
• byte 1
  • bit 7 - streamer mode on
• byte 2 - not used ?
• byte 3 - according to current Faikin code:
  • Bit 3: "Sensor" mode on
  • Bits 3, 4 (mask 0x0C): if both set (value & 0x0C == 0x0C), LED is turned off.

Protocol version specifics:
Set of available special modes is determined by FU00, which is only supported in protocol v3. Early protocol versions (tested on ATX20K2V1B, also reported for FTXS series, which is known to be v0) support this command too, but only report "Powerful" mode. Those conditioners also appear not to support respective D6 control command. Therefore Faikin currently has no way of controlling special modes on those models. It's unknown whether they can be controlled over S21 protocol in principle.

Commit 0c5f769894365d344012b36846f0b91023840d94 suggests that some models don't support this command at all. If such a case "Powerful" mode flag would come from F3. Unfortunately information on which A/C model exhibits this behavior has been lost.

F8 command

Protocol version (old, prior to v3) Response code: G8, payload length: 4 bytes

• byte0: Only observed 0x30 (ASCII '0') so far
• byte1: Version number, one ASCII digit. Reported in /aircon/get_model_info as pv= . v0 conditioners may just report 0x00 here (seen in FTXS50G), but experiments on BRP0690B41 show that there's no difference; the controller most likely masks shield bits out using "value & ~0x30".
• byte2, byte3: Only seen 0x00 (in ATX20K2V1B, real v2 protocol), or ASCII '0' (in v3 conditioners). Also seems to be ignored by Daikin controller.

This command only reports real version number prior to v3. v3 protocol froze F8 response to '0200' ASCII (which stands for v2) and superseded this command by FY00. Daikin controller distinguishes between protocol versions by probing for FY00 command, which is not recognized and returns NAK prior to v3.

Below is a table of known responses for F8:

D8 Response (hex)	protocol version	Example
0x30 0x32 0x00 0x00	2	1, 2
0x30 0x32 0x30 0x30	2	1
0x30 0x00 0x00 0x00	0	1, 2

FC command

Model code
Response code: GC, payload length: 4 bytes

Payload is 4 ASCII characters in reverse order (byte3 to byte0), which are reported as model= in /aircon/get_model_info. The controller by itself does not seem to do anything with this string, just pass.

The model code always looks like a hexadecimal number, nothing like customer-visible model code, printed on the label. This is most likely Daikin's internal model number, which can be looked up in some proprietary database.

FK command

Query extra optional features [protocol v2]
Response code: GK, payload length: 4 bytes

• byte0
  • bit 0 - Unknown. Reported as acled= value by BRP069B41 in /aircon/get_model_info
  • bit 1 - Zero
  • bit 2 -
  • bit 3 - "Laundry" operation mode is available.
  • bit 4 - Shield bit (0x30)
  • bit 5 - Shield bit (0x30)
  • bit 6 -
  • bit 7 -
• byte1
  • bit 0 - Unknown. Reported as elec= value by BRP069B41 in /aircon/get_model_info
  • bit 1 - Zero
  • bit 2 - Reported as temp_rng= value by BRP069B41 in /aircon/get_model_info. Used by Japanese controllers to select between the two temperature ranges.
  • bit 3 - Reported as m_dtct= value by BRP069B41 in /aircon/get_model_info. Probably "motion detector" AKA "Intelligent eye" availability
  • bit 4 - Shield bit (0x30)
  • bit 5 - Shield bit (0x30)
  • bit 6 - Unknown. Reported 1 by FTXF20D5V1B
  • bit 7 - Zero
• byte2
  • bit 0 - Unknown. Reported as "ac_dst=" value by BRP069B41 in /aircon/get_model_info: 0 => ac_dst=jp; 1 => ac_dst=--
  • bit 1 - Indicates simple "Humidify" mode implementation. When set to 1, humidity setting is not available regardless of respective F2 bits; and BRP069B41 reports s_humd=16 in /aircon/get_model_info
  • bit 2 - Fan controls available. When set to 0, swing bits in F2 response are ignored; and neither fan speed nor swing controls are available in "Daikin online controller" app.
  • bit 3 - Unknown. Reported as "disp_dry=" value by BRP069B41 in /aircon/get_model_info
  • bit 4 - Shield bit (0x30)
  • bit 5 - Shield bit (0x30)
  • bit 6 - Zero
  • bit 7 - Zero
• byte3
  • bit 0 - Demand mode if available. Daikin controller ignores this bit in protocol <= 2

FN command

ITELC, whatever that means
Response code: GN, payload length: 4 bytes
4 bytes of the payload are displayed by BRP069B41 in reversed order as itelc= parameter in /aircon/get_monitordata. The exact meaning of this isn't known; "ITELC" isn't mentioned anywhere on the web and in service manuals. Some internal code.

FR command

Louver angle setting
Response code: GR, payload length: 4 bytes

• byte 0 - ASCII character; reflects the requested louver angle setting:
  • '?' - Swing is active, no constant setting
  • '0' - Default position. Also reported on units, which don't support manual angle setting.
  • '1' - '5' - Manual setting in order: Upper position, high middle position, middle position, low middle position, lower position
• bytes 1 - 3 - always '0' ASCII, reserved.

Extension field reading commands "U" (FU**)

FU00 command

Special modes availability flags Response code: GU00, payload length: 32 bytes

• byte 0 - "Powerful" mode availability flag. 0x33 - enabled, 0x30 - disabled
• byte 1 - "Econo" mode availability flag. 0x33 - enabled, 0x30 - disabled
  
• byte 3 - unknown. Set to 0x33 (enabled) on FTXF20D5V1B, but no mode_info flag was found.
• byte 3 - unknown
• byte 4 - unknown. Set to 0x33 (enabled) on FTXF20D5V1B, but no mode_info flag was found.
• byte 5 - "Streamer" mode availability flag. 0x33 - enabled, 0x30 - disabled
• the rest - unknown, could be reserved.

Bytes 0, 1 and 5 effectively make up a bitmask, which is reported by Daikin controller as en_spmode= value in /aircon/get_model_info.

Apparently 0x30 and 0x33 are the only legitimate byte values for this command. Experiments show that 0x31 and 0x32 are treated no differently from 0x30; and value of 0x34 causes the controller to report "SERIAL IF FAILURE" error with code 252. I didn't try any other values because it's very time-consuming process. Since the command is only polled once; after every change the controller has to be rebooted.

Example payload from FTXF20D5V1B: 0x33 0x33 0x33 0x30 0x33 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30

FU02 command

Temperature limits
Response code: GU00, payload length: 32 bytes

• byte 0 - unknown
• byte 1 - Unknown, also looks like temperature limit. Reported by Daikin controller as atlmt_l= in /aircon/get_model_info if enabled by byte 0 bit 6 of FK command. Valid values are from 0xA0 to 0xB0 (inclusive); the value is determined as: atlmt_l = (byte - 0xA0) / 2.0. This yields range from 0 to 8.0. If byte value is outside of the valid range, the atlmt_l parameter value defaults to zero.
• byte 2 - Minimum allowed temperature for Heat mode. Reported by Daikin controller as hmlmt_l= in /aircon/get_model_info. Valid values are from 0x30 to 0x6F (inclusive); the value is determined as: hmlmt_l = (byte - 0x30) / 2.0 + 10.0. This yields range from 10.0 to 41.5 . If byte value is outside of the valid range, the hmlmt_l parameter is not present.
• byte 3 - unknown
• byte 4 - unknown
• the rest - looks like unused. 0xFF is often default content of unwritten EEPROMs.

Example payload from FTXF20D5V1B: 0xA0, 0xA0, 0x30 ,0x31, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF.

FU04 command

Unknown
Response code: GU04, payload length: 32 bytes
Seems to contain very long hexadecimal value, which slowly increases over time. The A/C has been turned off.
Example payloads from FTXF20D5V1B:
0x36, 0x43, 0x37, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF - non-FF bytes read as 00000000000007C6 (assuming inversion)
0x30, 0x44, 0x37, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF - 00000000000007D0

FU05 command

Model name
Response code: GU05, payload length: 32 bytes
Contains conditioner model name, spelled in ASCII, not backwards. The actual string length is 22 bytes; remaining 10 bytes are filled with 0xFF
Example payload from FTXA35C2V1B:
0x46 0x54 0x58 0x41 0x33 0x35 0x43 0x32 0x56 0x31 0x42 0x53 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
On some units the response appears to be all spaces: https://github.com/revk/ESP32-Faikin/issues/408#issuecomment-2395086066

FU15 command

Production information
bytes 0..3 - Production site? Looks like some Daikin internal code. Reported as prod_site= by /aircon/get_model_info
bytes 4..9 - Production line? Reported as prod_line= by /aircon/get_model_info
byte 10 - Unknown
bytes 11..31 - Unused ROM space, contain 0xFF

FU25 command

Production order
bytes 0..14 - Production order? Reported as prod_order= by /aircon/get_model_info
bytes 15..31 - Unused ROM space, contain 0xFF

FU35 command

Perhaps indoor unit production information. It is known that Onecta is capable of displaying indoor and outdoor unit data, but i (Sonic-Amiga) was unable to make BRP069C41 controller working with S21 protocol; so unable to verify Onecta's interpretation of the data.

bytes 0..1 - Reported as prod_inp_site= by /aircon/get_model_info
byte 2 - Reported as prod_inp_base= by /aircon/get_model_info
byte 3 - Reported as prod_inp_dev= by /aircon/get_model_info
bytes 4..11 - Reported as prod_inp_mdate= by /aircon/get_model_info
bytes 12..23 - Reported as prod_inp_serial= by /aircon/get_model_info
bytes 24..31 - Unused ROM space, contain 0xFF

FU45 command

Perhaps outdoor unit production information. Similar to the above

bytes 0..1 - Reported as prod_outp_site= by /aircon/get_model_info
byte 2 - Reported as prod_outp_base= by /aircon/get_model_info
byte 3 - Reported as prod_outp_dev= by /aircon/get_model_info
bytes 4..11 - Reported as prod_outp_mdate= by /aircon/get_model_info
bytes 12..23 - Reported as prod_outp_serial= by /aircon/get_model_info
bytes 24..31 - Unused ROM space, contain 0xFF

Extension field reading commands "X" (FX**)

Returned as "gx**" by /aircon/get_monitordata, purpose unknown.

Extension field reading commands "Y" (FY**)

FY00 command

Protocol version (v3 and beyond)
Response code: GY00, payload length: 4 bytes

• bytes 0,1: Protocol version minor as inverted ASCII
• bytes 2,3: Protocol version major as inverted ASCII Example: response '0230' stands for protocol version 3.20
  For protocols version below 3 this command isn't supported and returns NAK; in this case old F8 is used

FY10 command

Unknown
Response code: GY00, payload length: 8 bytes The returned value is an 8-byte hexadecimal string of unknown purpose. Could be conditioner firmware's git hash.
BRP069B41 controller only queries this command once in lifetime. Therefore it clearly has to do with A/C identification. Example payload from FTXF20D5V1B: {'A', '8', 'D', '3', '6', '6', '6', 'F'}

FY20 command

Unknown
Response code: GY20, payload length: 4 bytes The returned value is an 4-byte hexadecimal string of unknown purpose.
BRP069B41 controller only queries this command once in lifetime. Therefore it clearly has to do with A/C identification. Example payload from FTXF20D5V1B: {'E', '4', '0', '2'}

Sensor reading commands (R*)

Commands whose return values are mostly neatly formatted, ready to display strings representing volatile sensor data.

RH command

Home temperature
Response code: SH, payload length: 4 bytes
Payload format: signed ASCII in reverse order with one decimal place implied. Example: '123+' would stand for +32.1 C

RI command

Inlet temperature Response code: SI, payload length: 4 bytes
Payload format: signed ASCII in reverse order with one decimal place implied. Example: '123+' would stand for +32.1 C

RL command

Fan speed (RPM)

RN command

Louver angle
Response code: SN, payload length: 4 bytes
Payload formart: signed ASCII in reverse, the same as temperature. On my ATXF20 with swing on i observed the value changing from +000 to +090 and back.

RX command

Target temperature
Response code: SX, payload length: 4 bytes
Payload format: signed ASCII in reverse order with one decimal place implied. Example: '123+' would stand for +32.1 C
Temp. the indoor unit is actually trying to match, accounts for any powerful mode or intelligent eye modifiers or similar (heuristics are detailled in service manuals)

Ra command

Outside temperature Response code: Sa, payload length: 4 bytes
Payload format: signed ASCII in reverse order with one decimal place implied. Example: '123+' would stand for +32.1 C

Rb command

Unsigned ASCII decimal. Represents how much this indoor unit currently "pulls" on the compressor. Ranges from 0-15 indicating no load through to maximum load, with a value determined by the difference between the target and indoor temperatures. The compressor uses this signal to determine its target operating frequency (documented in service manuals).

Rd command

Compressor speed (RPM)

Re command

Indoor humidity
Response code: Se, payload length: 3 bytes
Payload format:3 digit unsigned ASCII decimal in reverse, e.g. 970 means 79% humidity. Units with no humidity sensor seem to always report 50%.

Extension sensor reading commands (Rz**)

The Rz command family contains a number of extra queriable data fields (with a 2 byte response payload), some of which mirror the various other R* commands, and some of which contain unique information. Input validation appear to be looser than other commands, since it can interpret the checksum byte as input if the command is shorter than expected, and seems to alias values that are invalid or unknown (including non-ASCII input bytes) using some yet unknown logic. The results of these commands appear to be fairly consistant and reliable, though.

RzB2 command: Unit state

Bit-field as ASCII string. Represents the state of the unit.

• 0x01: Powerful mode
• 0x02: Defrost in progress
• 0x04: Refrigerant valve to this unit open (meaning it is actively heating or cooling)
• 0x08: Unit online, whether or not it uses the compressor
  • The unit reads as offline if it is turned off or if its current mode conflicts with the compressor (i.e: trying to use fan mode while the compressor is heating)

RzB2 response	Rectified	Bitfield	Bitfield meaning	Meaning
SzB200	00	0b0000_0000	(Not online)	Indoor unit is turned off
SzB280	08	0b0000_1000	Online	Unit is idle (or in fan-only mode)
SzB2C0	0C	0b0000_1100	Online + Active	Unit is actively heating/cooling
SzB2D0	0D	0b0000_1101	Online + Active + Powerful	Unit is heating/cooling "at max capacity"
SzB2A0	0A	0b0000_1010	Online + Defrost	Defrost sequence starting/ending
SzB2E0	0E	0b0000_1110	Online + Active + Defrost	Defrost sequence in progress (unit is cooling)
SzB220	02	0b0000_0010	Defrost	Compressor is defrosting but unit is offline

RzC3 command: System state

Bit-field as ASCII string. Represents the state of the unit with regards to the whole system.

• 0x01: Compressor locked/"3 minutes standby"
• 0x02: Unknown, not observed yet
• 0x04: Refrigerant valve to this unit open (meaning it is actively heating or cooling)
• 0x08: Defrost in progress
• 0x10: Unknown, not observed yet
• 0x20: (Multi-zone) Other units are online in a compressor-reliant mode, whether they're active or idle
• 0x40: Unknown, observed on protocol v2+ units, both single-zone and multi-zone.

Whenever the compressor stops for any reason (besides defrost) or if restarting after a power outage, it enters "3 minutes standby" and will not resume operation until a 3 minutes period has passed.

Response payload examples

Wire order	Reverse order	Meaning
"SzC340"	04	This unit is actively heating/cooling
"SzC380"	08	Defrost sequence, unit is idle (possibly offline)
"SzC3C0"	0C (0x04 + 0x08)	Defrost sequence, unit is cooling
"SzC302"	20	This unit is idle or offline, but other units are online
"SzC310"	01	Compressor just stopped and is unavailable
"SzC312"	21	Compressor unavailable, other units are online
"SzC300"	00	Unit is idle, compressor probably not in use

Rz52 command

Queried by BRP069C, seemingly static, meaning unknown.

Rz72 command

Queried by BRP069C, seemingly static, meaning unknown.

Miscellaneous commands

M command

Response code: M, payload size: 4 bytes. 5 bytes total.
One of rare, perhaps very old, commands, whose code only consists of one byte.Unknown for sure, but looks like model code for protocol v0. According to https://github.com/revk/ESP32-Faikin/issues/408#issuecomment-2313256060
The command is supported in v2+ protocols, but the only seen reply is 'MFFFF' (ASCII). The controller doesn't seem to do anything about the payload.

VS000M command

Indoor unit firmware version
Response code: VS, payload size: 14 bytes

• Bytes 0 - 7 - firmware version in text format in reversed ASCII as usual. Shown as "Indoor unit software" on "Indoor unit" page by Onecta app when using new cloud-only controller. Info provided by @nikbyte using FTXA35C2V1B's integrated controller.
• Bytes 8 - 13 - Always read as '00000M' again in reversed ASCII.

Example payload: 0x31 0x30 0x31 0x37 0x31 0x30 0x32 0x32 0x4D 0x30 0x30 0x30 0x30 0x30 ; firmware version "22017101"
This command is only polled once. BRP069B41 controller also polls this command, but no HTTP API endpoints are known to expose this information.

F/G Responses

TODO: Rewrite this section and merge with the previous

The F/G responses are various lengths. Mostly text, but not always.

Opcode	Description
G1	Same as sent with D1
G3	This seems to be related to start/stop controls, and so presumably can be set with D3
G5	Same as sent with D5 but last byte is 0x80
G6	Same as sent with D6
G7	First two characters same as sent with D7, but the AG on the end.
G9	First two bytes appear to be temp (inside, outside) as 0x80+C*2

G3 appears to be:-

• 0/1/2/3 for none, start, stop, start+stop
• Start time byte
• Stop time byte
• 0x80

The times appear to be 0xFE when not set, and these example values when set…

• 23:00=b=98
• 23:30=f=102
• 06:00=8d=141=-115, or 0x80+13
• 07:00=92=146=-110, or 0x80+18

More tests needed to work out the exact pattern.