FTXB50 - unknown protocol

[Sonic-Amiga]

Hello! One user of my 8266 port has FTXB50 , and it appeared not to work. At all. Faikin can't recognize the protocol.

We did some research. First of all, i have a spare russian Daichi controller (on which the port runs) to use as a devkit. I reverted it to stock firmware and set it up for this model. And connected to my PC. The controller implementation is quite dumb, it simply sends requests in a loop. No error checking, no ACK required, nothing. If no response, it simply times out and issues the next command. It's also possible to connect to the controller using original Android app, and give commands to the A/C. The controller will honestly issue them on the serial interface. So, it's possible to see what the controller sends for "query status" as well as for all control commands.

Next, i used RealTerm (https://sourceforge.net/projects/realterm/) to try to listen for comms. Using trial and error, and also looking at oscilloscope shots, provided by the user (we'll get to that), i was able to receive some bitstream without errors. Port settings are: 8 bits, no parity, 1 or 2 stop bits (both work).

The packet from the controller looks like this:

E0 5B 2B AB 5B 6B 5F 5B 2B 2B 6B 2B DB FF

I try to turn on the power using phone app. The packet changes:

E0 5B 2B AB 5B 6B 2B 2B 2B 2B 5F 2B DB

Note there's lots of B's and some F's Doesn't look like anything making sense at all. Unless it's not standard UART protocol on the physical level.

The guy is an electronics expert, but not a programmer at all. So he did some poking with a scope. Communication looks like this: From controller to A/C (supposedly): Response (supposedly):

The grid scale is set to 2ms, and we see approx. 6 pulses per mark. This indeed corresponds to 2400. But doesn't look like making a whole ton of sense.

The guy also pointed out that the trace looks very similar to some IR remote protocols, like philips RC5: https://www.pcbheaven.com/userpages/The_Philips_RC5_Protocol/

I wrote a python script to represent my bytes as string of bits as if it was sent over the wire, adding start (0) and stop (1) bits. Then i took a piece of paper and tried to decode it by hand; trying to interpret transitions between 1 and 0. And this failed. Because in my bitstring i appear to have more than two '1' bits in a row.

I also attempted to line up two bitstrings in a text editor, to spot some localized difference. The hypothesis is that i don't change anything but power on/off state, which is one bit. So, two packets are actually only different in one bit plus (possibly) checksum. To no avail, i didn't crack it.

My second suggestion is that i actually have long string of 1's; and packet length is always the same, but UART misses consequent 1's at bytes border. Because '1' is a stop bit value, then comes the idle state.

Unfortunately i don't have a logic analyzer laying around. But i have Arduino Nano, i know i can make one. This will take me some time.

We also tried to go down the second road. It deems very unlikely that Daikin is using some very custom bit-banged protocol, simply because developing it takes time (and costs money) with unclear return. So this simply must be something stock, even if it's not a conventional RS232. I asked the guy, if he wants, to try reversing it from A/C side; and he provided me with photos of all chips on the board. The hope was that we would able to identify the controller, find the datasheet, and see, which modes its USART can do.

To no avail. I failed to find any of these chip markings on google. Top side is interesting. Note that the port connector is called "CN_WIRED", no "S21" indeed. The service manual (i found it) simply says it's a connector for wired control panel, and provides part no of the panel. Nothing more.

For now that's all we have. I am posting it here, maybe you know some other A/Cs with the same feature; or maybe you can throw in some expertise and recognize what the comm looks like. As we say, "one head is good, two heads are better".

Hope this info is interesting, see ya. And thank you again for the great project!

[Sonic-Amiga]

Did some more searching on the internet. Found one more russian-made controller, which claims to use CN_WIRED connector, and be compatible with:

FTYNxxL, FTYNxxFXV, FTXB50/60A, FTXB50/60B, FTXB50/60C, FTXCxxA, FTXKxxA, FTXNxxL, FTXNxxM, FTXNxxN, ATYNxxL, ATXB50/60C, ATXNxxL, ATXNxxM, ATXNxxN, ATXNxxM6, FLQNxxEXV, FLQNxxCXV, FHQNxxEXV, FHQNxxCXV, FFQNxxCXV, FCQNxxEXV, FCQNxxCXV.

[revk]

Yes, CN_WIRED is not simple UART, as far as I know. I think it may also be P1/P2 on some boards as power and data on one pair, not sure if same protocol. But such protocols need to do some clever stuff.

I don't know what it is, but I do have a wired controller on my units that I could take a scope to, and see if similar.

And yes, it may be some old proprietary thing I guess.

Fun

[type-rke]

Hi, received my faikin board yesterday and i also wanted to connect it to my FTX50cv1b, i connected the wires as following:

1 5V 2 26 3 GND 4 27 5 12V

The board is starting-up. but the airco is stil offline

MQTT messgaes: Bericht 1280 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"X50¬Rx","timeout":true} QoS: 0 - Retain: false Bericht 1279 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"S21¬Tx","cmd":"F1","noack":true} QoS: 0 - Retain: false Bericht 1278 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"X50¬Tx","timeout":true} QoS: 0 - Retain: false Bericht 1277 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"S21","cmd":"F1","noack":true} QoS: 0 - Retain: false Bericht 1276 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"X50","timeout":true} QoS: 0 - Retain: false Bericht 1275 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"S21¬Rx¬Tx","cmd":"F1","noack":true} QoS: 0 - Retain: false Bericht 1274 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"X50¬Rx¬Tx","timeout":true} QoS: 0 - Retain: false Bericht 1273 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"S21¬Rx","cmd":"F1","noack":true} QoS: 0 - Retain: false Bericht 1272 ontvangen op error/aircoliving/comms om 21:44: {"protocol":"X50¬Rx","timeout":true} QoS: 0 - Retain: false Bericht 1271 ontvangen op state/aircoliving om 21:43: {"id":"308398D3BCDC","up":5,"mqtt-up":2,"mem":59784,"spi":2091392} QoS: 0 - Retain: true Bericht 1270 ontvangen op state/aircoliving om 21:43: {"id":"308398D3BCDC","up":5,"mqtt-up":2,"mem":59784,"spi":2091392} QoS: 0 - Retain: true

[revk]

As this thread says, CN WIRED is not the same as S21 so won't work with the Faikin.

[type-rke]

OK, so no further development wil be taken for this ?

[revk]

I can't rule it out, but CN WIRED is not, as we understand it, a UART connection. It will mean either finding a specification or reverse engineering one, which will take some time.

If you know differently, or have any details of the protocol, that would help.

[type-rke]

Im not so technical,, or else i would be glad to help.

im keeping the faikin on the shel, and hopefully it will be working in the future.

[revk]

Other people have contributed to this project as well, and even if I don't have time to look at this connection/protocol, it may that others do, so that is possible. It is improving all the time.

[Sonic-Amiga]

Isn't it too early to close ? I've done some research in the meanwhile using sigrok and makeshift logic analyzer made of Arduino Nano. The data look like this: All the low level periods are 300 usec long. Except the first one, which is, i suppose, sync. There are two kinds of high level pulses: 1 ms long and 400 us long. I suppose these are actual 1s and 0s of the data; low level are just spaces.

So far i have a 3rd party proprietary controller, which knows this protocol, and i have two captures from it. One capture is for "power off" command, another is for "power on". Both captures are exactly 65 bits long. The difference is in the middle; i suppose the extra "1" bit is either start or stop.

There's not enough material. I am leaving for vacation next week; after i come back, i'll try to make a transceiver on Arduino and together with my user we'll attempt using it to talk to the AC. It's expected to power on and off; and send some replies. Then, after i replay them to my existing proprietary controller, i'll hopefully be able to get the rest of command (temp set, mode set, etc).

[Sonic-Amiga]

Here are two sigrok captures in an archive, for those who are interested: FTXB50-Reverse.zip

[Sonic-Amiga]

Another way to go would be to reverse engineer original ESP8266 firmware. Unfortunately toolset for disassembling esp8266 binaries doesn't look very rich. I don't have any success so far.

[revk]

I'll reopen it...

That really does look like typical IR remote.

I wonder if the actual IR remote uses the same signalling. I'll have to look in to that.

Silly question, is this two way signalling or just one way to the Daikin?

[Sonic-Amiga]

This is definitely two way. The connector has TX and RX. Plus, the controller definitely expects some reply, because it sends nothing except on/off state. Attempts to set temperature from the cloud app don't change anything, so the temperature isn't sent. I think that the controller would do it after it gets a reply. Packets in "off" vs "on" state differ in two bits total. I suppose one bit is part of byte, specifying state; and another bit is part of some sort of checksum.

Would be nice if you identify it as RC protocol. However it's unlikely famous Philips RC5. They encode 1's and 0's as level transitions within specified time slots; this results in both marks and spaces in the signal having different length. This doesn't correspond to my captures.

[Sonic-Amiga]

I exported sigrok data as "01" text file and tried to write a python script which decodes the signal into what i think. Long "mark" is treated as 1, short as 0:

D:\Projects\FTXB50-Reverse>python decode.py PowerOff-01.txt
1 11000100 00000000 11000100 01001000 10000000 00000000 00001000 00001111
[1, 196, 0, 196, 72, 128, 0, 8, 15]

D:\Projects\FTXB50-Reverse>python decode.py PowerOn-01.txt
1 11000100 00000000 11000100 01000000 10000000 00000000 00001000 00000111
[1, 196, 0, 196, 64, 128, 0, 8, 7]

You see the difference here. I tried checksumming, no, doesn't work. Apparently i am getting bytes (3rd line) wrong. I hope after i can reply to the controller, and it starts sending the rest of parameters (especially temperature setting) i'll be able to correlate numbers with the packet data and find out more.

[revk]

Likely to be two short or one long as the 1 and 0 (or 0 and 1), ie same time taken for each. That's just a guess.

[Sonic-Amiga]

If so, on vs off signals would contain different number of spaces. They don't.

[revk]

Ah, not what I would have expected. Ok. Good luck.

[dzungpv]

@Sonic-Amiga From my experience you may want more advance logic analyzer. But the price is expensive like Rigol DHO804, It will decode UART signal easy. But may be your analyzer will work, You can check signal when power on/off and check it it the same, may be it have CRC byte. Other parameter is parity check and stop bit, you can try to change every combine and send the capture data to the air-con. FYI, the official adapter support is: AWM61A01

[dremugit]

I've been playing with the CN_WIRED connection (mostly unsuccessfully), but I can say a few things for sure.

First, I'm in the US with Daikin 17 series, RXB18AXVJU+ and FTXB18AXVJU.

Since they don't sell them here, I had to get an SLM8 wall control from Malaysia. It works, save that it doesn't have a heat button and is in Celsius and not "freedom units" =))

CN_WIRED has five pins on a JST connector.

+5V (red on my wire) TX (from wall ctrl to minisplit, white on my wired) GND (black over bare shield on my wire) RX (to wall ctrl from minisplit, yellow on my wire) +12V (not used AFAIK, blue on my wire)

The wall control has screw terminals on the back for 5V, Gnd, Tx, Rx that go straight through to the JST.

The Rx and Tx signals are 5V logic. As mentioned above, they're variable-length pulses, what some folks call pulse-width modulation.

My 'scope says the packet starts with a 2500uS low pulse. Each pulse is separated by 300uS high.

"High" bits are indicated by a 1000uS low followed the 300uS high. "Low" is instead 500uS low followed by the 300uS high. Finally, there's a 2000uS low stop bit, returning to high when done.

The data packet is indeed 65 bits, the first always being 1, and then 64 data bits. I think.

The minisplit sends a packet once a second, whether or not anything is connected, and the wall ctrl replies to that.

I'd have to review my code, but I think they're reversed, i.e lowest bit first. The high-order byte, then, usually contains a temperature in BCD, that is, the wall ctrl sends 0x16 if set to 16C (~61F). As to what the rest means, this is where I am stymied at the moment. The wall ctrl does seem to set specific bits to specific modes and choices, ie the power is in the fourth byte, bit 4.

The minisplit, on the other hand, sends far more complicated stuff. The first byte does seem to be a temperature, also BCD, but could perhaps be the sensed temperature vs the set temp, depending on whether it's turned on or off. The rest seems to be a passed command packet. Maybe it's sending S21 data back, maybe it's a shortened version of the IR protocol used by the remote, I really don't know. I haven't found anything in https://github.com/crankyoldgit/IRremoteESP8266/ that seems to relate.

While I'd guess that the last byte is at least partially a checksum, I am unable to determine how it's calculated.

Finally, if I send a command from the IR remote to the minisplit, it sends multiple packets over the CN_WIRED to the wall ctrl, so that says to me that the minisplit -> wall ctrl packet is not a single packet containing all details, but only that which has changed. However, since sometimes multiple modes change (ie temperature goes away and quiet/powerful, which are actually fan speeds) when you switch from heat to cool to just fan, it's very difficult to isolate any single variable. Even just turning power on and off sends multiple packets.

Anyway, hope this helps somebody, and if I find anything else I'll follow up.

[revk]

OK, this is good work.

The Faikin can talk to 5V signals for the S21. With the 5V pin connected as well, that should allow sending 5V to the Daikin Rx line, and we can definitely handle 5V Tx signals. So I suspect we are properly hardware compatible.

Also, the ESP32 has an internal RMT controller which means it can generate and decode sequences like this precisely.

The problem is development of code for this. If I had one of these here it would indeed be easy.

On possibility would be to add code that handles the RMT signals both ways and passes data to/from MQTT, without trying to work out what they do. That would then allow much more debugging, generating signals and testing what they do, etc.

I could then add more logic for actually processing them as part of the Faikin code.

[Sonic-Amiga]

Hello, i am back from vacation. @dremugit Thank you for your very nice contribution; this will help us a lot.

[Sonic-Amiga]

@revk No HW changes required for sure, because on my side the same ESP8266 hardware works both with S21 and with CN_WIRED with no changes. It looks like high precision isn't required. 8266 doesn't have RMT, i guess the protocol implementation is bit-banged on the same pins.

[Sonic-Amiga]

"High" bits are indicated by a 1000uS low followed the 300uS high. "Low" is instead 500uS low followed by the 300uS high.

Are you sure you made no mistake here ? Because that's exact opposite on my side.

Finally, there's a 2000uS low stop bit, returning to high when done

I don't have this part at all.

Does this mean CN_WIRED has many implementations?..

[dremugit]

"High" bits are indicated by a 1000uS low followed the 300uS high. "Low" is instead 500uS low followed by the 300uS high.

Are you sure you made no mistake here ? Because that's exact opposite on my side.

I have never made a mistake in my life =))

Seriously, I'm sure you're right, as I arbitrarily set my code to call one length "high" and the other "low".

Finally, there's a 2000uS low stop bit, returning to high when done

I don't have this part at all.

Does this mean CN_WIRED has many implementations?..

Ugh. Wouldn't surprised me, as from my Googling it seems like Daikin has many different remote control options, none of which they want to open up to the world.

In my case, I wait for the start bit (2500uS low pulse ... err, I think it's low, now I'm starting to question myself :) ), then just consider everything else coming in as data until it goes over 2000uS or so, at which point I assume it's the stop bit. But we know what happens when we assume.

Also, I was totally unable to get the unit to respond to sent packets, ones I just captured and parroted back, without understanding what they contain.

Oh, and finally, I'm using the Arduino IDE, because that's what I know, and using interrupts to grab the incoming data, so it's entirely possible I'm missing some data somewhere. I don't think that's happening as the data coming from the wall control is certainly repeatable and sensible, what of I understand. The data from the mini-split is the part that stumps me the most.

[Sonic-Amiga]

Hello everyone! During last week i've hacked up an Arduino transciever for experiments. The code is available in https://github.com/Sonic-Amiga/ESP8266-Faikin ; you'll see a CN_WIRED_bridge.ino folder

FTXB50 protocol is (currently) interpreted as follows:

1. Idle state - high
2. Sync pulse - low 2500 microseconds
3. Start bit - high 1000 microseconds (we take this as data bit "1")
4. Space - low 300 microseconds
5. Data bits, represented as high level pulses. We take 1000 usec for "1" and 400 usec for "0".
6. Each data bit is followed by 300 usecs low (space)
7. 64 data bits total. We assume LSB first.
8. After the last space the line goes back to idle high state. No stop bits etc.

As we see, this is modified from FTXB18AX by @dremugit

Using this representation, two sequences have been decoded from my 3rd party cloud controller:

23 00 23 12 01 00 10 F0 power off 23 00 23 02 01 00 10 E0 power on

We see one data bit difference (12 vs 02); and formation of the last byte isn't currently understood

I have sent the firmware to my user, FTXB50 owner, waiting for response from him. If successful, we'll know AC's responses and i'll be able to simulate the AC by parroting known responses back to my controller, hopefully getting more commands and understanding their structure.

[Sonic-Amiga]

Just thought, by looking at hex dump, that perhaps nibbles are reversed. Because it we swap them, we'd get most of bytes as ASCII, and we know Daikin likes ASCII. And also checksum of whatever sort of 0x0E vs 0x0F would also differ by one bit, which makes slightly more sense

[revk]

A few more complete messages will make the check byte easier to work out, possibly a simple parity of some sore. Generating and decoding such a sequence in an ESP32 would not be hard.

[dzungpv]

Hello everyone! During last week i've hacked up an Arduino transciever for experiments. The code is available in https://github.com/Sonic-Amiga/ESP8266-Faikin ; you'll see a CN_WIRED_bridge.ino folder

FTXB50 protocol is (currently) interpreted as follows:

1. Idle state - high

2. Sync pulse - low 2500 microseconds

3. Start bit - high 1000 microseconds (we take this as data bit "1")

4. Space - low 300 microseconds

5. Data bits, represented as high level pulses. We take 1000 usec for "1" and 400 usec for "0".

6. Each data bit is followed by 300 usecs low (space)

7. 64 data bits total. We assume LSB first.

8. After the last space the line goes back to idle high state. No stop bits etc.

As we see, this is modified from FTXB18AX by @dremugit

Using this representation, two sequences have been decoded from my 3rd party cloud controller:

23 00 23 12 01 00 10 F0 power off 23 00 23 02 01 00 10 E0 power on

We see one data bit difference (12 vs 02); and formation of the last byte isn't currently understood

I have sent the firmware to my user, FTXB50 owner, waiting for response from him. If successful, we'll know AC's responses and i'll be able to simulate the AC by parroting known responses back to my controller, hopefully getting more commands and understanding their structure.

The last E0 and F0 must be checksum byte, like revk said, you can provide more message so we can decode it, the hard part is the checksum.

[Sonic-Amiga]

Of course i will provide more data as soon as my user replies. I don't own an FTXB50 myself; my two Daikin units are all S21. I only do my analysis with my "Daichi" cloud controller, which i am using as a devboard, reverted to a stock firmware, set up to talk to FTXB50. So i only have one side of the conversation. And these two messages is all i currently have. The controller just sends one of these repetitively once per second. In order to get more, i believe, i need to respond.

And i haven't made any progress yet in reverse engineering the firmware. ESP8266 reverse tooling appears quite poor :(

[Sonic-Amiga]

I have just made a breakthrough. My controller appears tricky. For some reason it refuses to set temperature below some level. Some built-in logic. But it appears to react on mode changes, fan speed controls, etc. Here is the decoded protocol with examples:

Byte 0 - temperature setting (BCD):
|
32 00 23 04 01 00 10 00 Set 32 degrees
31 00 23 04 01 00 10 F0 Set 31 degrees
30 00 23 04 01 00 10 E0 Set 30 degrees

byte 3 - mode. 0x10 is a power off bit
          |
31 00 23 02 01 00 10 D0 Cool
31 00 23 04 01 00 10 F0 Heat
31 00 23 08 01 00 10 30 Auto
31 00 23 20 01 00 10 D0 Dry
31 00 23 01 01 00 10 C0 Fan
31 00 23 11 01 00 10 D0 Power off (fan)

Byte 4 - fan speed and special modes
             |
30 00 23 02 08 00 10 30 Cool quet mode
30 00 23 02 01 00 10 C0 Cool fan 1
30 00 23 02 04 00 10 F0 Cool fan 2
30 00 23 02 02 00 10 D0 Cool fan 3
30 00 23 02 01 00 10 C0 Cool fan auto
30 00 23 02 03 00 10 E0 Cool fan powerful
30 00 23 02 09 00 10 40 Cool Eco

Byte 5: vertical swing (0x0F: on, 0x00: off)
               |
30 00 23 02 01 F0 11 C0 OK
30 00 23 02 01 00 10 C0 OK

Byte 7 high nibble - CRC - sum of all nibbles (including low nibble!)
30 00 23 02 01 00 10 C0 Cool fan 1 3+2+3+2+1+1 + 0=C
30 00 23 02 03 00 10 E0 Cool fan powerful 3+2+3+2+3+1+ 0=E

At the moment i only have a single example of a message from the AC. This is the first thing my user reported. Even with no intervention it reports once per second:

27 04 00 00 00 00 10 E0

Probably '27' is current indoors temperature. '04' could be outdoors; he lives far to the south from me and it's winter here.

[dremugit]

Wrt temperature set, that's probably the case. My wall control has a DIP jumper to set a range of 16-30 C or 20-30 C (again, sold in Malaysia as cool-only because the last thing they need is more heat!)

[Sonic-Amiga]

Well, minimum of +30 feels strange anyways. But, whatever, we need the protocol, not the 3rd party controller's custom logic. Perhaps Malaysian ACs don't even have reversal.

[dremugit]

Sorry, wasn't clear. I meant the controller has a range of setpoints from 16 min to 30 max or from 20 min to 30 max. And it's a Daikin controller, for whatever that's worth. And I don't know "reversal"; is that what we'd call "heat pump" in the US? The controller doesn't have a heat mode, that's for sure, just Cool, Dry, Fan.

[Sonic-Amiga]

"Reversal" - yes, i mean heating mode. Because the AC effectively works in reverse, having swapped hot and cold ends. It needs additional HW for the purpose to be able to reverse the coolant flow.

[dremugit]

Okay, cool (err, "okay, good" :) As in all things, the US has to be different and calls it something else. Anyway, glad you're getting somewhere with this!

[Sonic-Amiga]

In fact i thought that a "heat pump" is just a technical name for the air conditioner, because... Well, that's what it is. It pumps the heat from one place to another.

Well, end offtopic :)

[revk]

Ok that is amazing. Do you want me to try and code that in the Faikin module? I.e. will you be able to do tests when I have?

We may have to work out sub zero outside temp reporting.

I would really hope it reports current mode and settings.

But code to create and report these messages should be pretty easy, probably a setting to know it is working in CN_WIRED mode, though I may be able to automatically detect it...

I wonder if my model has CN_WIRED, I'll have to have a look.

[Sonic-Amiga]

@revk You're welcome to experiment with this; but unfortunately my user and i are unable to help with testing. Because we live on another side of the New Iron Curtain; and i believe we cannot order your Faikin-ESP32 board. So we're stuck with our stock 8266-based controllers, which don't have RMT. So bit-bang is our cholice. But, stock firmware happily does it; so can we.

But @type-rke told here that he owns FTXB50 and a Faikin-ESP32 board. Are you here following us ? Please come back to the party; you're the one to help development and testing.

@dremugit Are you interested in a version of Arduino sniffer for your variation of protocol ? Let's call it "inverted CN_WIRED"

though I may be able to automatically detect it

Easy-peasy. Just sit around for several seconds and wait for a single valid packet. If received, the protocol confirmed. Known ACs send one packet per second even if the other side is completely idle

Sorry for delayed replies, i don't have password remembered on my mobile phone. Plus that dreaded two-factor auth...

[Sonic-Amiga]

In the meanwhile my user, using the dual-channel Arduino sniffer i wrote, took complete dumps of two sessons:

1. Issue commands from the cloud app: controlled_by_controller.txt
2. Issue commands from the AC's own remote; controller is only monitoring: controlled_by_remote.txt

I don't have time for much reviwing today, it's too late here, i am sharing these materials as they are. Yet they are totally great; they allow us to complete the specification.

I only have one problem left: i can receive data but i can't transmit anything. I tried known packets, i expected the controller's app to update modes and/or indoors temperature reading; but no success. My user also tried using my Arduno firmware to send commands to his AC with the same result.

Potential problems are:

1. My timings are off. The fact that receiver works very well; and the fact that the protocol is bit-banged, says against this version.
2. Perhaps you cannot transmit at arbitrary time, but within some time window, when opposite side is not sending anything. Or after the remote side has finished transmitting.

I know you may eliminate (1) by using RMT

[type-rke]

Hi, I would like to help, but i'm not technical, in programming and stuf, i can hookup the module again but you guys should tell me what to do.

[Sonic-Amiga]

@type-rke Great to see you back. Now, i believe, you'll cooperate with @revk directly on this case, We now have enough material and testbed so he can implement it. As i said, i don't have this exact hardware; so i am at this point only helpful with information.

[revk]

I'll have a look at making output using RMT and checking on a scope.

Hopefully today...

Update: I have managed to generate a sequence with the RMT, and am working on Rx side.

I cannot get the RMT rx working, so will need to do more work, but I'll make an issue shortly that will allow you to force it to send CN_WIRED format messages.

[revk]

Your "BAD" checksum ignores the 1 on the end, which if you add it makes the checksum nibble correct. Surely? Being LSB that means the checksum is the last 4 bits sent, so makes sense to include the 4 bits before it.

[revk]

Issuing code now - use setting/Faikin/protocol 11 to force to a CN_WIRED mode, which sends (hopefully) valid messages.

It only does temp, mode and power for now, but once we have working, fixing the rest will be easy.

Receive is not working at all yet.

[revk]

Ooooh, I may have something!!!

I am receiving and dumping the data now. Actual decoding it will be later, but please do test.

Send setting/Faikin/dump 1 to dump the tx and rx strings.

I'll issue new code now, please feed back on this stage. If it works we can progress to more useful actual controls and status over this protocol. And thanks for all your work.

[Sonic-Amiga]

Your "BAD" checksum ignores the 1 on the end,

Thank you, i know. Isn't that what i wrote in "note" below ?

[revk]

Sorry, Ok.

[Sonic-Amiga]

@revk I still could not succeed in replying to my controller and simulating an AC.

I suppose RMT samples edges and measures intervals. Since you can receive data now, can you verify that my timings are correct ? I have rewritten my send() to a highly optimized version; and it now runs with interrupts disabled. To no avail :(

[revk]

I don't have a CN_WIRED on my units (as far as I know) so only receiving what I am sending from another test Faikin. This needs testing on a device with CN_WIRED.

[Sonic-Amiga]

@type-rke Please react on https://github.com/revk/ESP32-Faikin/issues/126#issuecomment-1834044782 . You're currently the only one who can test,

Do you know how to send and read data over mqtt ?