ESP32-Daikin
ESP32-Daikin copied to clipboard
New variation of CN_WIRED
We are testing CN_WIRED protocol implementation; and we found some AC models, which don't conform to current documentation: https://github.com/Sonic-Amiga/ESP8266-Faikin/blob/main/Tools/Simulators/CN_WIRED/README.md
Symptoms are: physical format seems to be correct, but data encoding appears totally different. Examples are: https://github.com/revk/ESP32-Faikin/issues/126#issuecomment-1931784397 https://github.com/revk/ESP32-Faikin/issues/126#issuecomment-1932417630
I tried calculating checksum by hands and indeed i can't see any pattern here. Some questions:
- Could there be more than 8 bytes in the packet ? Have we checked ?
- We know that A/C sends room temperature every second. Does it maybe have some display, so that we know what value we're looking for ?
- We can try capturing what the A/C sends when remote control is used. That will give us set point value, we can look for it, this could eliminate (2)
- @akirafrabbani: which A/C model is that ? So that we know. Also i could check whether it's on support list of my Daichi. If so, i could assist figuring out controller side.
- Do you have any known control unit, that connects to this A/C ? Like wall panel, or maybe some 3rd party controller which supports it ? Again, we need both sides of communication.
We mostly have to restart the research (mostly) from scratch with this A/C.
We get 66 symbols, but I have rx set to allow for 128 (I'll reduce that to save memory). So yes, we are checking for longer messages. This is exactly the right length and all timings match the protocol.
set_val (swingv, (payload[5] & 0x20) ? 1 : 0);
I'm sure I read "bit 5", but OK, changed. Changed.
More examples... I'll keep the log going to try and find more.
1E1F2000005A10A4
1F202000005A1074
1E202000005A1084
1E202000005A0094
1D780400000010B2
1C780400000010C2
All nibbles, including checksum, add up to F. Simples.
The first 2 values on message type 4 look like temps, maybe min/max range and current?
I have updated my checksum code, and made these report as unknown message type.
I'm sure I read "bit 5", but OK, changed
My bad, Hit the wrong key. Or maybe counted from 1 like a n00b. Just pushed fix for the doc.
I wonder, does this AC also transmit messages we know, or this is all it sends ?
Sends the normal type 0 (and 1 on mode change) as well but also these 2 and 4 regularly.
Do we know AC types ?
FTV35PBV1MF and FTKG50 send type 2 and type 4: https://github.com/Sonic-Amiga/ESP8266-Faikin/issues/19
• “dump”:“1E7D0000000000A2”
• “dump”:“00E20000000000B4”
• “dump”:“1E7D000000001092”
There's a suggestion that byte[0] in type 2 stands for outside temperature. Unable to verify.