ESP32-Daikin icon indicating copy to clipboard operation
ESP32-Daikin copied to clipboard

New variation of CN_WIRED

Open Sonic-Amiga opened this issue 1 year ago • 8 comments

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:

  1. Could there be more than 8 bytes in the packet ? Have we checked ?
  2. 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 ?
  3. 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)
  4. @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.
  5. 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.

Sonic-Amiga avatar Feb 07 '24 21:02 Sonic-Amiga

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.

revk avatar Feb 08 '24 06:02 revk

set_val (swingv, (payload[5] & 0x20) ? 1 : 0);

I'm sure I read "bit 5", but OK, changed. Changed.

revk avatar Feb 08 '24 06:02 revk

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?

revk avatar Feb 08 '24 07:02 revk

I have updated my checksum code, and made these report as unknown message type.

revk avatar Feb 08 '24 08:02 revk

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 ?

Sonic-Amiga avatar Feb 09 '24 20:02 Sonic-Amiga

Sends the normal type 0 (and 1 on mode change) as well but also these 2 and 4 regularly.

revk avatar Feb 09 '24 20:02 revk

Do we know AC types ?

Sonic-Amiga avatar Feb 26 '24 20:02 Sonic-Amiga

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.

Sonic-Amiga avatar Jul 25 '24 21:07 Sonic-Amiga