revk
[Documentation] S21 protocol: new findings
Long story short, I've also been reverse engineering S21 protocol and here are some of my findings.
Hardware
- air conditioner: S22ZTES-W (interior unit), F22ZTES-W (exterior unit)
- interface adaptor for wired remote controller: KRP067A41
- wired remote control: KRC081A1
Communication method
UART, 2400bps, 8 bit data, 2 bit stop, even parity, DC 5V voltage level.
Request commands
1) Message format
STX Byte(0) Byte(1) Checksum ETX
Checksum is the Modulo256 of the sum of Byte(0) and Byte(1).
2) Command list
Here is a list of what might be new commands.
| Byte(0) | Byte(1) | Description |
|---|---|---|
| F | 3 | Timer |
| F | 9 | Coarse indoor, outdoor temperature (℃) |
| F | M | Total energy consumption (kWh) |
| R | g | Compressor status (ON/OFF) |
| R | A | Power status (ON/OFF) |
| R | B | Operation mode |
| R | D | ON Timer setting |
| R | E | OFF Timer setting |
| R | F | Swing setting |
| R | K | Cross flow fan speed setpoint (rpm) |
| R | L | Cross flow fan speed (rpm) |
| R | M | Louver vertical angle setpoint (degree) |
| R | N | Louver vertical angle (degree) |
3) Unknown command list
Here is a list of commands my air conditioner responds to but I have not yet identified. (Result of testing the commands F0 to F9, FA to FZ, R0 to R9, Ra to Rz and RA to RZ.)
| Byte(0) | Byte(1) | Response |
|---|---|---|
| F | 2 | 0x34 0x3A 0x80 x080 |
| F | 4 | 0x30 0x00 0x80 0x00 |
| F | 8 | 0x30 0x32 0x00 0x00 |
| F | A | FFFF |
| F | B | 0000 |
| F | C | 1A01 |
| F | G | 0801 (see below) |
| F | K | 1001 |
| F | L | 0000 |
| F | N | 0000 |
| F | P | 8300 |
| F | Q | F200 |
| F | R | ?000 |
| F | S | 0000 |
| F | T | 1000 |
| R | b | 300 |
| R | e | 050 |
| R | z | 0x53 0x7A |
| R | C | 720+ |
| R | G | A |
| R | W | 00 |
Details: [ . ][X][ . ][ . ] increments by one (from 0 to F and repeat) each time the air conditioner receives a command from the remote control.
2) Request sequence
The wired remote control sends the following sequence of commands indefinitely.
D20 -> F8 -> F2 -> F4 -> F3 -> F1 -> F5 -> D80000 -> RH -> F8 -> F2 -> F4 -> F3 -> F1 -> F5 -> D80000 -> Ra
I haven't figured out D20 neither D80000 yet. Response to D20 is always ACK while D80000 is always NAK.
Upon receipt of a response, the remote control sends an ACK after about 45ms.
The time between the remote control sending an ACK and then sending a new command is about 36ms.
Response
1) Message format
ACK STX Byte(0) Byte(1) ... Byte(n) Checksum ETX
Checksum is the Modulo256 of the sum of Byte(0) to Byte(n)
2) Timer
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | G | - |
| Byte(1) | 3 | - |
| Byte(2) | 0, 1, 2, 3 | Timers disabled, ON Timer, OFF Timer, Both timers |
| Byte(3) | 0x36~0x78 | ON Timer (1~12 hours) |
| Byte(4) | 0x36~0x78 | OFF Timer (1~12 hours) |
| Byte(5) | 0 | - |
Timer setting (hours) = (Value – 0x30) / 6.
3) Coarse indoor, outdoor temperature (℃)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | G | - |
| Byte(1) | 9 | - |
| Byte(2) | see below | Coarse indoor temperature |
| Byte(3) | see below | Coarse outdoor temperature |
| Byte(4) | 0xFF | - |
| Byte(5) | 0x30 | - |
Temperature = (Value – 0x80) / 2.
4) Total energy consumption (kWh)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | G | - |
| Byte(1) | M | - |
| Byte(2) | 0~F | Data[3] |
| Byte(3) | 0~F | Data[2] |
| Byte(4) | 0~F | Data[1] |
| Byte(5) | 0~F | Data[0] |
Total energy consumption = Data[0~3] → Decimal / 10.
5) Compressor status (ON/OFF)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | g | - |
| Byte(2) | 0, 1 | Compressor OFF, Compressor ON |
6) Power status (ON/OFF)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | A | - |
| Byte(2) | 0, 1 | Power OFF, Power ON |
7) Operation mode
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | B | - |
| Byte(2) | 0, 2, 3, 4, 6 | Auto, Dry, Cooling, Heating, Fan only |
8) ON Timer setting
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | D | - |
| Byte(2) | 0~9 | Minutes tens |
| Byte(3) | 0~9 | Minutes hundreds |
| Byte(4) | 0~1 | Minutes thousands |
9) OFF Timer setting
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | E | - |
| Byte(2) | 0~9 | Minutes tens |
| Byte(3) | 0~9 | Minutes hundreds |
| Byte(4) | 0~1 | Minutes thousands |
10) Swing setting
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | F | - |
| Byte(2) | 0, 1, 2, 7 | Disabled, Up & down, Left & right, Both |
| Byte(3) | 0, F | - |
Byte(3) is 0 when Byte(2) = Disabled, F otherwise.
11) Cross flow fan speed setpoint (rpm)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | K | - |
| Byte(2) | 0~9 | Speed tens |
| Byte(3) | 0~9 | Speed hundreds |
| Byte(4) | 0~1 | Speed thousands |
12) Cross flow fan speed (rpm)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | L | - |
| Byte(2) | 0~9 | Speed tens |
| Byte(3) | 0~9 | Speed hundreds |
| Byte(4) | 0~1 | Speed thousands |
13) Louver vertical angle setpoint (degree)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | M | - |
| Byte(2) | 0~9 | Angle units |
| Byte(3) | 0~9 | Angle tens |
| Byte(4) | 0~1 | Angle hundreds |
| Byte(4) | +, - | Angle sign |
When the louver is in the closed position, the vertical angle is 120°.
14) Louver vertical angle (degree)
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | S | - |
| Byte(1) | N | - |
| Byte(2) | 0~9 | Angle units |
| Byte(3) | 0~9 | Angle tens |
| Byte(4) | 0~1 | Angle hundreds |
| Byte(4) | +, - | Angle sign |
Hope this help.
this is a wonderful work, but i wonder why i use mostyle different commands 🤣 being serious, i assume there are different S21 protocol versions. For example, i have F1 that gives me all basic info (mode, fan, power), you have not. F5 for me is swing state, you have not.
however, some of these commands get an answer also on my unit. Thanks! just wondering why there is the info of target and real angle of VERTICAL louver, but not HORIZONTAL
have you tried also SETTING values? (i assume via D commands)? would be nice to set target position of louver :) will it be DK?
I've only posted the commands that I believe are not fully documented or commands that are still unknown. The commands you mentioned including the following work with my air conditioner:
| Byte(0) | Byte(1) | Description |
|---|---|---|
| F | 1 | Power (ON/OFF), operation mode, temperature setpoint (℃), wind speed |
| F | 5 | Swing setting |
| R | a | Outdoor temperature (℃) |
| R | H | Indoor temperature (℃) |
| R | I | Refrigerant temperature (at the evaporator coil inlet) (℃) |
| R | X | Temperature setpoint (℃) |
For the temperature setpoint of F1, when operation mode = dry the temperature is how much the indoor temperature at start of dry operation is allowed to be warmed up/cooled down while removing moisture (see table below).
| Value | Description | Remark |
|---|---|---|
| 0x82 | +2℃ | Low dehumidification effect |
| 0x81 | +0.5~1.5℃ | |
| 0x80 | 0℃ | |
| 0x8F | -0.5 ~ -1.5℃ | |
| 0x8E | -2℃ | High dehumidification effect |
My air conditioner model can only move the louver up and down, so I wasn't able to find which command can fetch the louver horizontal angle setpoint and actual one (if existing).
I've just started to play with commands for setting values and so far I've confirmed D1 and D5 work.
ok this makes sense :) thanks a lot, i'm having some fun.. the only issue i see is that the more commands we send, the longer it takes for update, so we need to lower the refresh frequency
don't you have Rd working?
Yes, Rd is also working (forget to add it in the previous table of known and working commands).
any idea on the meaning of Rd response? mine is commonly 20 or 40, i see around talking about frequency but to me it seems more a percentage of load..
Regarding Rd response, I would agree with the idea that it is the inverter compressor frequency (Hz).
According to ChatGPT, the normal operating frequency range for the compressor in consumer-oriented air conditioners is around 20-30 Hz for minimal cooling, 40-80 Hz for moderate cooling and 90-120 Hz for maximum cooling.
In my case, with a temperature setpoint of 27℃ I've seen values like 26Hz in the morning when it's around 30℃ outside and around 65Hz in the afternoon when it's above 37℃ outside.
For so, I've defined Rd response as follow:
| Byte | Description | Value |
|---|---|---|
| Byte(0) | - | S |
| Byte(1) | - | d |
| Byte(2) | Frequency units | |
| Byte(3) | Frequency tens | |
| Byte(4) | Frequency hundreds |
But I wasn't able to confirm it's indeed the compressor frequency as the wired remote control I use for reverse engineering doesn't display neither poll this information from the air conditioner.
i can't find official values in the tech document of my external unit, but it makes sense to be frequency, i'll use it in that way :)
Ok on my system (old Perfera) i do not have additional responses than yours (so i assume i can't set horizzontal lid angle), but i have a lot of NAK where you get info. On R commands i only miss RW, but on F i have much more holes (F9 | FA | FB | FC | FG | FK | FL | FM | FN | FP | FQ | FR | FS | FT). I assume it's a matter of unit maturity and features..
sadly i get NAK for both DK and DM commands, so probably target fan speed and target angle can't be set :(
Hello guys!
I have recently ordered an old stock BRP069B41 online controller specifically for dissection, and after some fighting with geo-blocking i even managed to set it up to work with an A/C simulator, However, it currently sits in "ret=SERIAL IF FAILURE,err=252" state. I am assuming that this means "incompatible A/C model", because communication actually works fine. And if i stop the simulator, error code changes to 251 (and it stops responding to /aircon/* completely, only to /common/basic_info), so the A/C is indeed online.
It currently sends 4 queries in a loop:
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
I am thinking that F4 and F2 are responsible for A/C model identification. I hardcoded replies, which my FTXF20D sends. I was planning to play with these values and see how the controller reacts to changes. But first i need to get it fully running.
So hence my first request for help. Can any of you from EU share me replies of your A/C to F2 and F4 commands ? Especially wanted are replies from any model on this list: FTXM-M CTXM-M ATXM-M FTXTM-M BRP069A45 FTXG-LS FTXG-LW FTXJ-MW * FTXJ-MS *
These are listed on https://www.daikin.eu/en_us/product-group/control-systems/onecta/connectable-units.html as compatible with my parrticular box.
Please reply with data and your A/C model. Just in case if someone cares: these data can't be used to identify you personally.
Another interesting finding is 'FU' command. The controller sends it only once upon startup. My A/C doesn't know it, i checked. So, simulator currently replies with NAK, just like a real unit. I tried to modify the sim to reply with 4 zeroes. Controller status didn't change, but interestingly it responds with a byte of 0x15 instead of ACK before proceeding.
If anyone is interested, you can find my modified simulator here https://github.com/Sonic-Amiga/ESP8266-Faikin/tree/main/Tools/Simulators . I will upstream changes, of course, once i have some more interesting findings.
UPD: The controller appeared fully working with my another unit, ATX20K2V1B. The unit is older and runs BRP069A41; it was available here back then... Dam, that's an ealier revision of the same unit!
Need to Faikin-ize it to shake some info out of it.
| Model | F2 response | F4 response |
|---|---|---|
| CTXM60RVMA, CTXM35RVMA | 0247323D3B00807103 | 024734300080305B03 |
| CTXM25RVMA | 0247323D3B00807103 | 0247343000A0307B03 |
@Sonic-Amiga what responses do your units send?
Snip from the simulator, containing the answer:
case '2':
// BRP069B41 sends this as first command. If NAK is received, it keeps retrying
// and doesn't send anything else. Suggestion - query AC features
if (debug)
printf(" -> unknown ('F2')\n");
response[3] = 0x34; // No idea what this is, taken from my FTXF20D
response[4] = 0x3A;
response[5] = 0x00;
response[6] = 0x80;
s21_reply(p, response, buf, S21_PAYLOAD_LEN);
break;
case '3':
if (debug)
printf(" -> powerful ('F3') %d\n", powerful);
response[3] = 0x30; // No idea what this is, taken from my FTXF20D
response[4] = 0xFE;
response[5] = 0xFE;
response[6] = powerful ? 2 : 0;
s21_reply(p, response, buf, S21_PAYLOAD_LEN);
break;
case '4':
if (debug)
printf(" -> unknown ('F4')\n");
response[3] = 0x30; // No idea what this is, taken from my FTXF20D
response[4] = 0x00;
response[5] = 0xA0;
response[6] = 0x30;
s21_reply(p, response, buf, S21_PAYLOAD_LEN);
break;
As to my older ATX20 unit, i have no idea; and i am waiting for my connectors order to arrive so that i could make an adapter for some of ESP hardware i have on hands. So, it doesn't have Faikin currently, so i can't actively research it. Hope parts to arrive next week.
Thank you very much, we're moving. I started changing replies one by one. First i changed F4, the result was the same, error 252. Then i also changed F2, and controller moved on:
$ ./faikin-s21.exe -p COM3 -v
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: F8
-> Unknown command, sending NAK
Got command: F8
-> Unknown command, sending NAK
When it gets NAK, it resends the command in an infinite loop. So now i need to implement F8 and probably more. Stay tuned! BTW, you may also order some experiments with my BRP. I wonder if i could share it online...
Wooohooo, off we go, it's alive! Status OK, control works! The code pushed to my repo.
So, very interesting. This is the log when it worked:
$ ./faikin-s21.exe -p COM3 -v
Got command: F8
-> unknown ('F8')
Got command: F9
-> Unknown command, sending NAK
Got command: F6
-> powerful ('F6') 0
Got command: F7
-> eco 0
Got command: FB
-> Unknown command, sending NAK
Got command: FG
-> Unknown command, sending NAK
Got command: FK
-> Unknown command, sending NAK
Got command: FM
-> Unknown command, sending NAK
Got command: FN
-> Unknown command, sending NAK
Got command: FP
-> Unknown command, sending NAK
Got command: FQ
-> Unknown command, sending NAK
Got command: FS
-> Unknown command, sending NAK
Got command: FT
-> Unknown command, sending NAK
Got command: Rd
-> Unknown command, sending NAK
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: RL
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: RH
-> 'H' sensor = +245
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: RN
-> Unknown command, sending NAK
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: RI
-> 'I' sensor = +185
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: Ra
-> 'a' sensor = +205
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: RX
-> Unknown command, sending NAK
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
-> swing 0
Got command: F2
-> unknown ('F2')
Got command: F1
-> power 0 mode 3 temp 22.5
Got command: F3
-> powerful ('F3') 0
Got command: F4
-> unknown ('F4')
Got command: F5
So, it looped: F2 F1 F3 F4 F5; and every iteration it also queried one sensor ('R'). Majority of them aren't implemented in the simulator yet.
But i am unable to reproduce this. After i restarted the sim and controller, after F8 it started wanting F9. Then FB. Something is off; perhaps i unintentionally exploited some bug.
I reproduced my success following the algorithm: Every time we get F8, increment a counter. Drop it 15 times (do not respond), then reset the counter to zero and say NAK Eventually the controller gives up probing and goes online (see log above)
F8 response from my faikin-ized unit is 30 32 30 30, i. e. '0020' (we read it in reverse like other values) If i implement this response, the controller does not calm down and wants F9, then tons of other stuff (almost all english alphabet), then proceeds to 'Mx`, where x is more characters. I gave up on that, too many commands. Interestingly enough, my FTX20 knows all of them.
I have also just tried 30 30 30 30, and also 00 00 00 00. Different thing happens; the controller now wants MM
Conclusion: F8 is used to query for additional features.
Further confirmation to the theory is the log:
Got command: F8
-> unknown ('F8')
Got command: RH
-> 'H' sensor = +245
Got command: Ra
-> 'a' sensor = +205
So, it does not go for F9 (which, we know, reports home and outside temp in some 'new' form), but instead asks for RH and Ra. Protocol version maybe ?
Confirmed. F8 = "protocol version". Known responses are '0020' and '0010'. '0000' does the same as '0010'; i guess they do "if (version > '1')" sort of check.
Version 1 has interesting 'MM' command, it replies with 'MFFFF' (yes, just one command byte, 5 bytes total). No idea what that is, grabbed from my FTXF20. I tried different second chars (MM, MN, MA), they all seem to produce an identical response.
Hack with timeouting removed, the controller is online with simulated A/C.
Funny that Faikin mis-detected 'M' response as loopback, i'll fix it.
With my Japanese model, the command F8 returns: G 8 0 2 0x00 0x00.
Command F2 returns: G 2 4 : 0x00 0x80.
Command F4 returns: G 4 0 0x00 0xA0 the first time then always G 4 0 0x00 0x80
I've also tried to send different commands, like "A" or "HG" or "cd" and so on but only got responses from the following:
| Command | Response |
|---|---|
| A | STX C A ETX |
| B | ACK |
| G | 0xC5 |
| M | STX M F F F F e ETX |
| V | STX V 0 0 A 0 ' ETX |
@hedgepigdaniel So, i am currently simulating CTXM60RVMA (not exactly, however) . I can connect to this A/C using old "Online controller" app, and i can see:
- The unit has vertical, horizontal and 3D swing modes
- The unit does not have "night" fan speed. Is this correct or not ? If correct, does your second unit, CTXM25RVMA, have different set of these features ? Which one ?
@misterobotique The same question goes to you.
@misterobotique
Command F2 returns: G 2 4 : 0x00 0x80. Command F4 returns: G 4 0 0x00 0xA0 the first time
Sorry, couldn't understand how to interpret this. The payload (i. e. what follows response code: 'G2', 'G4') should be 4 bytes. Can you show raw dump ?
@hedgepigdaniel Lotta fun... If i respond '0247343000A0307B03' to F4, the controller says error 252, which is i am assuming "incompatible model". And that's the very same string my FTX20 reports, by the way.
@Sonic-Amiga
Mixing ASCII and hexadecimal was confusing, sorry.
F8 returns: 02 47 38 30 32 00 00 E1 03.
F2 returns: 02 47 32 34 3A 80 80 E7 03.
F4 returns: 02 47 34 30 00 A0 00 4B 03 the first time then always 02 47 34 30 00 80 00 2B 03
@hedgepigdaniel So, i am currently simulating CTXM60RVMA (not exactly, however) . I can connect to this A/C using old "Online controller" app, and i can see:
The unit has vertical, horizontal and 3D swing modes Correct The unit does not have "night" fan speed. Is this correct or not ? Incorrect. The IR remote has a "indoor unit quiet mode" with the night icon, and it clearly does reduce the fan speed compared to the auto mode. However, after setting night mode using the IR remote, Faikin sees it in auto mode. Setting it in night mode via Faikin seems to work correctly in that the fan is still low, and refreshing the UI shows it still in night mode.
If correct, does your second unit, CTXM25RVMA, have different set of these features ? Which one ?
As far as I can tell, the entire CTXM25RVMA, CTXM35RVMA, CTXM60RVMA have exactly the same set of features except that in the CTXM60RVMA there is only a single "intelligent eye" human presense sensor mode - on and off, whereas in the smaller units there are 3 settings - off, blow towards people, blow away from people. Same IR remote for all of them.
And for all of CTXM25RVMA, CTXM35RVMA, CTXM60RVMA, F8 response is 024738303230304103 or "0200"
@hedgepigdaniel So, i am currently simulating CTXM60RVMA (not exactly, however) . I can connect to this A/C using old "Online controller" app, and i can see:
- The unit has vertical, horizontal and 3D swing modes
- The unit does not have "night" fan speed. Is this correct or not ? If correct, does your second unit, CTXM25RVMA, have different set of these features ? Which one ?
@misterobotique The same question goes to you.
SxxWTES-W, SxxWTEP-W and SxxWTEV-W series only have the following features:
- vertical swing mode
- "night" fan speed
- "comfort" fan speed
I found out what FR reports: the louver vertical position setting.
| Bytes | Values | Description |
|---|---|---|
| Byte(0) | G | - |
| Byte(1) | R | - |
| Byte(2) | ?, 0, 1, 2, 3, 4, 5 | Swing, "Comfort" mode position, upper position, high middle position, middle position, low middle position, lower position |
| Byte(3) | 0 | |
| Byte(4) | 0 | |
| Byte(5) | 0 |
FS could be the louver horizontal position setting.
Also, I noticed F6 would returns 0 2 0 0 when "Night" mode is enabled (0 0 0 0 when disabled).
Also, I noticed F6 would returns 0 2 0 0 when "Night" mode is enabled (0 0 0 0 when disabled).
Thank you for this finding; i'll recheck on my unit. This is going to solve our night mode detection problem, if confirmed.
Now back to F8. I's confirmed to be a protocol version. Now my sim returns '0100', which stands for v1. aircon/get_model_info (http api) says this:
ret=OK,model=NOTSUPPORT,type=N,pv=1,cpv=0,mid=NA,s_fdir=3,en_scdltmr=1,en_onofftmr=1
Note "pv" number, which definitely stands for "protocol version". We can also recognize some optional features:
- s_fdir=3 - have horisontal + vertical swing ("fan direction")
- en_onofftmr=1 - have on/off timer
- en_scdltmr=1 - have scdl timer, whatever it is.
Let's compare this with my real ATXF unit, also running with BRP:
ret=OK,model=0000,type=N,pv=2,cpv=2,cpv_minor=00,mid=NA,humd=0,s_humd=0,acled=0,land=0,elec=0,temp=1,temp_rng=0,m_dtct=0,ac_dst=--,disp_dry=0,dmnd=0,en_scdltmr=1,en_frate=1,en_fdir=1,s_fdir=1,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_mompow=0
Note how much more flags we have; and also pv=2
The same number is displayed as "Indoor unit software" in Onecta: select unit -> Settings -> Daikin air-to-air heat pump -> Indoor unit
I tried playing with unknown values in the simulator, but i couldn't change s_fdir. Note also model=NOTSUPPORT. I think that BRP only has some rudimentary support for protocol v1 with some fallback options. In order to get the real picture, we need to implement protocol v2 and that's going to take me some time.