Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New variation of CN_WIRED #231

Open
Sonic-Amiga opened this issue Feb 7, 2024 · 8 comments
Open

New variation of CN_WIRED #231

Sonic-Amiga opened this issue Feb 7, 2024 · 8 comments
Assignees

Comments

@Sonic-Amiga
Copy link
Contributor

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:
#126 (comment)
#126 (comment)

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.

@revk
Copy link
Owner

revk commented Feb 8, 2024

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
Copy link
Owner

revk commented Feb 8, 2024

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

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

@revk
Copy link
Owner

revk commented Feb 8, 2024

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
Copy link
Owner

revk commented Feb 8, 2024

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

@Sonic-Amiga
Copy link
Contributor Author

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 ?

@revk
Copy link
Owner

revk commented Feb 9, 2024

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

@Sonic-Amiga
Copy link
Contributor Author

Do we know AC types ?

@Sonic-Amiga
Copy link
Contributor Author

FTV35PBV1MF and FTKG50 send type 2 and type 4: Sonic-Amiga#19

	•	“dump”:“1E7D0000000000A2”
	•	“dump”:“00E20000000000B4”
	•	“dump”:“1E7D000000001092”

There's a suggestion that byte[0] in type 2 stands for outside temperature. Unable to verify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants