[Documentation] S21 protocol: new findings #408
Comments
|
Wow!!! Ok we have most of that, but there are a couple of ones we can add. |
|
this is a wonderful work, but i wonder why i use mostyle different commands 🤣 however, some of these commands get an answer also on my unit. Thanks! 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.
For the temperature setpoint of
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 |
|
ok this makes sense :) thanks a lot, i'm having some fun.. don't you have Rd working? |
|
Yes, |
|
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 For so, I've defined
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. |
|
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: 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: 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. |
@Sonic-Amiga what responses do your units send? |
|
Snip from the simulator, containing the answer: 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. When it gets NAK, it resends the command in an infinite loop. So now i need to implement F8 and probably more. Stay tuned! |
|
Wooohooo, off we go, it's alive! Status OK, control works! |
|
So, very interesting. This is the log when it worked: 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: F8 response from my faikin-ized unit is 30 32 30 30, i. e. '0020' (we read it in reverse like other values) 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: 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 I've also tried to send different commands, like "A" or "HG" or "cd" and so on but only got responses from the following:
|
Reverse-engineered from original Daikin BRP069B41 online controller, which is now able to work with this simulator. See revk#408 for some documented findings Signed-off-by: Pavel Fedin <[email protected]>
|
@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:
@misterobotique The same question goes to you. |
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 |
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 |
SxxWTES-W, SxxWTEP-W and SxxWTEV-W series only have the following features:
|
|
Does anyone here own BRP069C41 controller ? I'd like to ask to run it with simulator; i'll give detailed instructions. I am experiencing problems; and i'd like to distinguish simulation problems vs network problems. |
|
Ok, so I monitored Rz00-RzFF for a few hours, and it seems pretty clear to me that the "parameter" part is to be read in reverse, because most of the "floating" ones are in one large cluster from RzE3 to RzBE. The way in which most of these vary also tells me that the value needs to be interpreted in reverse, like everywhere else. I didn't include other R signals, which in retrospect would probably have been useful to compare if any of these vary together, but it at least gives a clearer idea of which ones are static, which ones are floating, and which ones naturally vary. This is what I gathered logged into a CSV file, with F1 included to show when I turned the unit on and changed the temperature. To cut down on the noise and make patterns easier to identify, values are only logged if they have changed. @Sonic-Amiga: Rz52 and Rz72 did not vary at all during the 4 hour period I was measuring. |
|
Ok, I ran it some more tests with extra R sensors for reference, and here's my interpretation of the results so far:
Rz02, Rz22, Rz32 and Rz61 will require further investigation Everything else in the Rz00-RzFF space is either floating (like the entire block from RzD4 to RzDC) or appears to be static values (like the initial Rz00 to RzB0 range). EDIT: D3 goes from "56" (0x65, 101) to "8C" (0xC8, 200) before it wraps around, oddly enough. |
|
Can anyone verify that the Rz behaviors I mentionned above at least appear to match the behavior on their units? By the looks of it, Rz looks like some kind of raw register access, and I can't verify that these are the same across models and/or protocol versions. |
|
Sorry, only after return from vacation (30th oct). No time, need to prepare myself. |
Yes, a cursory investigation shows that my V2 units report similar values.
Mine return different values amongst units on the same outdoor unit and the same temperature sensor - so I don't think so.
matches for each outdoor unit - makes sense
In all three cases, I don't see an obvious correlation based on the sensor setting or actual human presence. I wonder if 21/E1 is the "load" value that increases as the difference between actual and target temperatures change? B1 seems to be a hex number that is 0 when the unit is off. |
Huge bummer if you're right about this, because that would imply that the sensor is not exposed at all.
That would be RzA1 and Rz31, which both always seem to match and vary with Rb, which I've already established to correspond to ΔD, the indoor frequency command signal.
If you have multizone, can you also check RzC3? |
Hex values for each group of indoor units on the same outdoor:
Why - are you confident that we have already found and completely tested all possible commands? I'm not hopeful about the presence sensor, but I can't say with confidence that it's not available somehow. |
|
It has finally gotten cold enough over here for me to catch a defrost cycle (as evidenced by the fan stopping and the indoors liquid temp "RI" dropping in the single digits) while probing. While none of the "00"-"FF" Rz registers have been showing anything very interesting during said defrost cycle, I did notice that Rb (currently identified as the indoor frequency command signal) jumps to "900" ( EDIT: RzA1 and Rz31 are NOT the same. They are almost always in sync, but when Rb becomes "900" when switching to defrost mode, only RzA1 seems to follow (becoming "90"), while Rz31 stays the same (in my case it stayed at "00"). |
|
Ok, I really think I've cracked RzC3. Here's my current hypothesis for what the states mean (all bytes are in wire order): RzC3 (which resplies with "SzC3XX") is the compressor state
Reminder:
I've not observed other values so far, though I've not retested dry mode to look for RzC3 values. Could someone else confirm that RzC3 behaves the zame way on their unit? The last thing I'd want is for Rz to be some kind of raw memory dump and to actually be unique per model. EDIT: I initially figured that 2 meant heating and 0 meant cooling, but after doing some more targeted tests, it's become clear that this isn't the case. My current guess is that 0 means "no other unit is turned on" and 2 means "another unit could be using the compressor". Still not 100% clear whether it also changes based on master/slave roles. Will need to run some more tests to confirm that. Also, there's no signal for "Warming up for hot start" (which shows up as normal activity, so 4X/0X), even though I know P1P2 thermostats acknowledge that status and display it the same way they do with defrosting. EDIT2: Actually, it looks like the one signal I had stumbled on at the beginning by mistake would have been a clone of that one.
This would be in line with the hypothesis that this last character (the one flipping between 0 and 2) represents another unit being online. EDIT3: The exact value range has me think this could also be the hex representation of a bitfield, but that's probably going to be hard to verify if we can't find anymore states. |
|
Could someone with a Protocol v2 or v3.x unit confirm that RzB2 and RzC3 behave as documented in the wiki for them? I just want to make sure that the behavior is the same for everyone. |
It's not cold enough here so I can't check the defrost cycles. Here are my results from quickly querying the commands on a few active/not active units. RzB2 matched with the wiki. I could check unit on, unit on and idle, unit actively heating. RzC3 didn't completely match.
|
|
I was trying to find the command for the floor heating option of the new floor standing indoor units (Perfera). The units have protocol version 3.4. Unfortunately I wasn't very successful so far. The units come with the cloud based wifi modules (BRP069C4x, connected to S801).
So if the Faikin module would come with the correct connector, it could probably be a drop-in replacement for the original Wifi modules I think, without the need to buy/make a new cable or even open the PCB enclosure of the AC. But so far I've only attached it in snoop mode, with only the power supply lines (GND, 14V) and RX connected so far (hoping it's just S21 on another port). The data looked like this: "0232861222830222C302320602328612228C12220D023286162......" if someone has an idea. |
|
Hi! |
|
+14V is correct power value BTW. 5V pin is not used by these controllers. |
Ok, interesting, it seems like you have an extra bit on the ASCII bitfield for RzC3 that my unit doesn't, 0x40. From your table, I'd hazard a guess that maybe it means "Other units have their valve open", but you would have to do more tests on your end to isolate whether that's actually what it stands for. For reference, what's your unit model? |
|
@sam-m7 Testing RzC3 on my ATX20K2V1B (protocol v2): So all matches; bit '4' (1 << 2) isn't known. |
Very strange; most likely garbled data. 02 is a valid STX for S21, by the way... |
I don't know. I can't really make something of the last ASCII value. It seems like it's locked to 0, 2 or 4 depending on the indoor unit. For example there were two outdoor units, both compressors were on and on each one, one indoor unit was heating and the other was off. Still, one of the off indoor units showed Indoor units are FVXM-A (with different performance classes) |
No, it's on the same unit. FVXM-A has S21, where I have connected the Faikins so far. It works for most features, I'm only missing the Floor warming option (upper lid is closed), which the Faikin currently doesn't have. Since the official app has this option, I thought I would try to listen into the data of the original wifi module, which is connected on a different port (S801) and can even stay attached (and keeps working), when a Faikin is connected to S21. Yes, I've noticed a lot of It might be worth a try to compile Faikin with the baud-rate of X50A for S21 and see if it can do something of the messages, but I haven't set up the build environment/tried it so far. |
Yes, I have read this earlier in the thread. Interesting that the cloud controller works with X50 on your side, maybe Faikin is not detecting it correctly. |
|
Took a quick look at code; "snoop" option is handled in any way only for S21. I guess there's some clash. I advice to disable all protocols except S21; and also disable pins inversion (it's already programmed in GPIO). Perhaps snoop mode only works with hidden "protofix" option, which is only accessible over MQTT. Not sure. I guess nobody has tested it for some time. |
|
Hello everyone! |
I think I've done that already. Used protofix at first (it was an older Faikin controller, where this was still set to S21 and also no swap RX/TX was set I think). With protofix to S21 the Faikin has not received anything, the same was the case for protofix removed and only S21 activated and every other protocol deactivated. Only when I've selected X50A, Altherma_S or CN_Wired (always with every other protocol disabled), it has shown data. Which is why I assumed this had something to do with the baud-rate. But it has always shown erros for those protocols and it seamed like it would try, as the messages/errors look different for each protocol, but couldn't interpret it correctly. |
|
Some update. I haven't had time to update also S21 doc, but with my upgraded controller i've got new get_monitordata fields, which gave me all FU commands: https://github.com/revk/ESP32-Faikin/wiki/Daikin-online-controller-reverse-engineering#airconget_monitordata . These have to do with A/C identification. Yes, the unit can be fully tracked. The only Daikin's excuse is that they actually don't program the full data; on real A/C's i have seen these fields are empty, containing only zeroes or spaces. |
|
I'm curious because I haven't seen any doc on the matter yet: Is X50 only different from S21 at a physical level (pinout, baud rate, etc.) or are the commands different as well? |
|
The commands are totally different. |
|
I'm also starting to suspect that the A command is similar to Rz where it has a bad length check on my unit and interprets checksum and ETX as command payload. It's expecting a full command length of 4 characters (Axxx) like many others and returns 6 characters by repeating what it got as an argument, plus an ASCII hex value (CxxxFF). If it's anything like RzXX, there's going to be wraparound and floating values here as well, and we have no official controller messages to use as references. |
Long story short, I've also been reverse engineering S21 protocol and here are some of my findings.
Hardware
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 ETXChecksum 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.
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.)
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 -> RaI 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 ETXChecksum is the Modulo256 of the sum of Byte(0) to Byte(n)
2) Timer
Timer setting (hours) = (Value – 0x30) / 6.
3) Coarse indoor, outdoor temperature (℃)
Temperature = (Value – 0x80) / 2.
4) Total energy consumption (kWh)
Total energy consumption = Data[0~3] → Decimal / 10.
5) Compressor status (ON/OFF)
6) Power status (ON/OFF)
7) Operation mode
8) ON Timer setting
9) OFF Timer setting
10) Swing setting
Byte(3) is 0 when Byte(2) = Disabled, F otherwise.
11) Cross flow fan speed setpoint (rpm)
12) Cross flow fan speed (rpm)
13) Louver vertical angle setpoint (degree)
When the louver is in the closed position, the vertical angle is 120°.
14) Louver vertical angle (degree)
Hope this help.
The text was updated successfully, but these errors were encountered: