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.

Testing S21 commands with Faikin

The easiest way to probe the S21 pins is to use Faikin's command/myFaikinUnit/send MQTT command (which will require that you have your units connected to an MQTT broker already, like people usually do with Home Assistant). That command takes a payload of either a single plain text ASCII command (such as D113BA) or a JSON array of commands to run in order (such as ["D113BA", "F1", "RC", "RG"]). In response, Faikin will send the debug output of each command over the info/faikin-salon/tx and info/faikin-salon/rx topics (which can be subscribed together as info/myFaikinUnit/#).

Topic: info/myFaikinUnit/tx
{"protocol":"S21","dump":"0246317703","F1":""}

Topic: info/myFaikinUnit/rx
{"protocol":"S21","dump":"02473130334C416803","G1":"03LA"}

Warning

Faikin's S21 command queue can get overloaded if the MQTT command/myFaikinUnit/send command is sent repeatedly without waiting, causing timing issues and garbage data to be sent and/or recieved. Make sure to wait for the replies to come back before sending another MQTT command, especially in automated scripts, or batch your commands into a JSON array. Avoid making the array too long as well, some dropped commands issues have been known to occur past 20-30 elements.

In the case of JSON, both for the payload and the replies, non-ASCII values can be sent as Unicode escape sequences for code points between \u0000 and \u00FF, where the hexadecimal codepoint value is converted to a byte with that exact value. For instance, the command "D1" with payload "1 2 0x80 A" can be sent as ["D112\u0080A"].

Commands that are rejected by the Daikin unit, whether because they don't exist, because the checksum is incorrect or because the payload isn't valid will have their rx MQTT response message contain the "nak": true key. Similarly, commands that do not issue replies will still be acknowledged by the indoor unit, and contain a "ack": true key to reflect that.

Topic: info/myFaikinUnit/tx
{"protocol":"S21","dump":"02494E56414C7A03","IN":"VAL"}

Topic: info/myFaikinUnit/rx
{"protocol":"S21","cmd":"IN","payload":"56414C","text":"VAL","nak":true}

Topic: info/myFaikinUnit/tx
{"protocol":"S21","dump":"02443431A903","D4":"1"}
2025-08-07 19:15:51:690

Topic: info/myFaikinUnit/rx
{"protocol":"S21","cmd":"D4","payload":"31","text":"1","ack":true}

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

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.

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 (D) and state reading (F) commands

Commands that start with F are mostly used for reading the settings of the indoor unit. They respond with a message starting with G and the field "name", followed by the current configured value. Commands starting with D are usually for writing those same configuration values, with the same format. These do not get a reply, and are only acknowledged.

Write	Read	Resp.	Semantics	Note	Protocol support
D1	F1	G1	Mode and temperature control		v0, v2, v3.0, v3.2
D2	F2	G2	Optionnal features support	D2 is sent with a 1 character payload of "0", even though G2 has a 4 character payload.	v0, v2, v3.0, v3.2
D3	F3	G3	On/Off timer	F3 reads 4 bytes. D3 will accept 3 or 4 bytes, but the 4th value does not seem to get written. Purpose of the 4th byte unclear.	v0, v2, v3.0, v3.2
	F4	G4	Unknown		v0, v2, v3.0, v3.2
D5	F5	G5	Swing, humidity setting	Supported values depend on optional features, see F2	v0, v2, v3.0, v3.2
D6	F6	G6	Special modes (Powerful, Streamer, etc.)		v2, v3.0, v3.2
D7	F7	G7	Demand control, econo mode	BRP069B41 initializes D7 on startup to known value "0000"	v2, v3.0, v3.2
	F8	G8	Protocol version (legacy)	Units with protocol v3+ still report as v2 here. V3 compatible controllers also use "FY00".	v0, v2, v3.0, v3.2
	F9	G9	Coarse temperatures, humidity (%)		v2, v3.0, v3.2

Write	Read	Resp.	Semantics	Note	Protocol support
	FA	GA	Unknown	Unused by BRP069B41, but units reply to it.	v2, v3.0, v3.2
	FB	GB	Unknown		v2, v3.0, v3.2
	FC	GC	Model code?	Only polled once. First byte appears to indicate unit size/capacity	v2, v3.0, v3.2
	FG	GG	IR remote counter	Increments on each IR command	v2, v3.0, v3.2
DH			Unknown
DJ			Unknown	Sent by BRP069B41 controller on startup, may be clock-related.	v2, v3.0, v3.2
	FK	GK	Optionnal features support (v2+)		v2, v3.0, v3.2
DL	FL	GL	Unknown		v2, v3.0, v3.2
	FM	GM	Lifetime energy consumption	4 digit ASCII encoded hex number in reverse- indicates total Wh/10	v2, v3.0, v3.2
	FN	GN	Unknown	Reported as "itelc" by get_monitordata, might be internal model code.	v2, v3.0, v3.2
	FP	GP	Unknown		v2, v3.0, v3.2
	FQ	GQ	Unknown		v2, v3.0, v3.2
DR	FR	GR	Louver angle setting		v2, v3.0, v3.2
	FS	GS	Unknown		v2, v3.0, v3.2
	FT	GT	Unknown	Potentially related to outdoor unit capacity	v2, v3.0, v3.2
	FV	GV	Unknown	Found by brute-forcing, unused by BRP069B41	v2, v3.0, v3.2

D1/F1 command

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

Pos	Description	Values
1	Power	0: 0ff 1: On
2	Mode	1: Auto 2: Dry 3: Cool 4: Heat 6: Fan
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?

Operating mode

Value	Mode
"0"	Auto, Cooling
"1"	Auto
"2"	Dry
"3"	Cool
"4"	Heat
"6"	Fan
"7"	Auto, Heating

Values "0", "1" and "7" are treated as identical by D1, and all apply auto mode. When reading back with F1 (also RB), the unit will return "0" if auto mode is cooling or "7" if auto mode is heating (or was last cooling/heating if idle or off).

Fan speed setting

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

Command D1 will acknowledge and apply the quiet ("B") fan setting, but command F1 will read it back as if the fan was set to "Auto" mode. Command RG, however, which uses the same mode values as D1 and F1, will correctly return "B" if the fan is in quiet mode.

D2 command

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

Pos	Description	Values
1	Unknown	0

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

D3/F3 commands

Set/Read on/off timers
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
byte 3 - Reports 0x00 after bootup, changed to 0x30 by DJ on v2+ units. Meaning unknown. Value seems unchanged when writing.

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, and the v0 units tested so far exhibit no such behaviour. 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') or 0x00, probably depending on the protocol version

Values observed (FTXS**L, protocol v0):

G4 0\x00\x80\x00 (usual, both on and off)
G4 0\x00\xA0\x00 (after resuming from power outage; reading immediately resets the value from \xA0 to \x80)

D5/F5 commands

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	Humidity setting	0: Off `0x3A`: Low `0x3B`: Standard `0x3C`: High `0xFF`: Continuous
1	Unknown	0

There's a sixth "Moisturising" humidity setting that is reported as identical to the Off setting on units that have it. Also, the service manual states that the humidity setting corresponds to "Humidifies or dehumidifies with high/moderate/low power", the meaning of that byte changes based on operation mode.

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.

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.

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

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

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:

Byte 2 bit 7 in F2 is set to 1
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*)

FC command

Tip

Return values for this command are tracked on the Model Codes page.

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.

These don't seem to change across protocol versions, so version support is omitted in the table.

Cmd	Resp	Semantics	Note	Example value	Meaning
RA	SA	Power on/off	Either "SA0" or "SA1".	"SA1"	Online
RB	SB	Current indoor unit setting	Seems to always follow "F1", except for "Auto mode" which switches between "RB0" and "RB7" depending on whether the unit is trying to cool or heat, respectively.	"RB4"	Heat
RC	SC	Temperature set point	Signed decimal number, no decimals, in Celcius	"SC120+"	21°C
RD	SD	On timer setting
RE	SE	Off timer setting
RF	SF	Unknown	Only "SF00" so far	"SF00"
RG	SG	Fan setting	Seems to always follow "F1", except for "Quiet fan" mode, which F1 reports the same as "Auto fan" mode.	"SGB"	Quiet
RH	SH	Indoor temperature	Signed decimal number, one decimal, in Celcius	"SH562+"	26.5°C
RI	SI	Indoor heat exchanger temperature	Signed decimal number, one decimal, in Celcius	"SI572+"	27.5°C
RK	SK	Fan speed tap	Plain decimal number, divided by 10, "tap" means one of the finite fan speed targets	"SK670"	760 rpm
RL	SL	Fan speed (measured)	Plain decimal number, divided by 10.	"SL570"	750 rpm
RM	SM	Louvre angle set point	Signed decimal number, one decimal, in degrees. Snaps to target values, then SN slowly follows.	"SM780+"	87.0°
RN	SN	Louvre angle (measured)	Signed decimal number, one decimal, in degrees.	"SN510+"	15.0°
RW	SW	Unknown	"SW00" and "SW09" observed on offline units	"SW09"
RX	SX	Real target temperature	Signed decimal number, one decimal, in Celcius. Motion sensors and powerful mode mainly affect this value.	"SX522+"	22.5°C
Ra	Sa	Outside temperature	Signed decimal number, one decimal, in Celcius.	"Sa520+"	2.5°C
Rb	Sb	Indoor unit "pull"	Ressembles "Indoor frequency command signal", but always switches to "Sb900" during defrost.	"Sb700"	7/15
Rd	Sd	Compressor frequency (measured)	Plain decimal number, divided by 10. Rotation speed of the outdoors unit compressor.	"Sd450"	540 rpm
Re	Se	Indoor humidity	Plain decimal number. Units with no sensor seem to always report "Se050" (50%).	"Se970"	79% RH
Rg	Sg	Compressor on/off	Either "Sg0" or "Sg1". Unknown if it registers when the compressor switches off before defrosting.	"Sg1"	Online

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

A command

Payload format: 4 digit ASCII hex characters in reverse order.
Response code: C, payload size: 5 bytes. 6 bytes total.
Example payload: A1000; Meaning (presumed): 0x0001
Example response: C100D4; Meaning (presumed): 0x*001 is 0x4D

Presumably for reading a physical memory address. Like Rz**, it performs no input validation and will interpret the checksum as part of the payload if said payload is too short. It will also accept pretty much anything as its payload, including any ASCII character that is not a hexadecimal digit or, indeed, any non-ASCII 8 bit value. The payload is returned as-is, with any non-ASCII characters intact, and with the "final" byte (believed to be the most significant byte, so the one that wouldn't change on a sequential read) truncated. Both parts of the response payload are presumed to be in reverse order. The response payload also tends to change when the same command is sent multiple time, at least for certain payloads (like "0000"), so this couldn't be some kind of ROM dump command.

The internal "conversion" from non-hexadecimal values to hex ones is unknown.

M command

Note

Faikin may discard single-byte commands, so when testing over MQTT, something like "MM" tends to be more reliable than "M".

Tip

Return values for this command are tracked on the Model Codes page.

Response code: M, payload size: 4 bytes. 5 bytes total.
Payload format: 4 digit ASCII hex characters in unknown order.
Example payload: 0x33 0x45 0x35 0x33; ASCII (wire order) "35E3"

One of rare, perhaps very old, commands, whose code only consists of one byte (anything past the first letter is ignored so "M", "Mx" and "M12345" are treated the same). Unknown for sure, but looks like model code for protocol v0, according to https://github.com/revk/ESP32-Faikin/issues/408#issuecomment-2313256060
. Didn't differ between various indoor unit models connected to the same outdoor unit, so suspected to be related to the outdoor unit.

The command is supported in v2+ protocols, but the only seen reply is 'MFFFF' (ASCII). At least some protocol v1 units have return values for both M and GC, which don't appear similar or related so far. The official wired controller doesn't seem to do anything about the payload.

It seems clear that the returned ASCII string is to be interpreted as an hexadecimal number (akin to the output for FM/GM), though not much more can be discerned so far, including whether they are to be interpreted in forward or reverse order.

V command

Note

Faikin may discard single-byte commands, so when testing over MQTT, something like "VV" tends to be more reliable than "V".

Tip

Return values for this command are tracked on the Model Codes page.

Response code: V, payload size: 4 bytes. 5 bytes total.
Payload format: 4 digit ASCII hex characters in unknown order.

Another old, protocol v0 command. Assumed to be some kind of version identifier but unknown. Command payload seems to be ignored, so "V", "Vx" and "V12345" should be equivalent.

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.

On v0 units, this is treated like a normal "V" command.

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.

S21 Protocol

Data Packets

Testing S21 commands with Faikin

Commands

Protocol versions

Protocol version 0

Protocol version 2.0

Protocol version 3.00

Protocol version 3.10

Protocol version 3.20

Protocol version 3.40

Commands support matrix for different protocols.

Data formats

Plain decimal number

Signed decimal number

Hexadecimal number

Compact temperature setting

State setting (D*) and state reading (F*) commands

D1/F1 command

Operating mode

Fan speed setting

D2 command

F2 command

D3/F3 commands

F4 command

D5/F5 commands

D6 command

F6 command

D7 command

F8 command

DH command

DJ command

Query commands

DR command

State reading commands (F*)

FC command

FK command

FN command

FR command

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

FU00 command

FU02 command

FU04 command

FU05 command

FU15 command

FU25 command

FU35 command

FU45 command

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

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

FY00 command

FY10 command

FY20 command

Sensor reading commands (R*)

RH command

RI command

RL command

RN command

RX command

Ra command

Rb command

Rd command

Re command

Extension sensor reading commands (Rz**)

RzB2 command: Unit state

RzC3 command: System state

Rz52 command

Rz72 command

Miscellaneous commands

A command

M command

V command

VS000M command

F/G Responses

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

State setting (D) and state reading (F) commands