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.

[type-rke]

With the latest update received the app only see what you do with the remote, but if ytou set press a button nothing happens

also power off will not work

[revk]

We are still unclear on the way this works, and it stops working apparently.

[type-rke]

Ah ok, because yesterday moreless it was working, even in home assitant it went quite well
BTW, this is the remote i have:

[revk]

We are still working on it

[Sonic-Amiga]

Frankly speaking i don't know what this particular AC does. Glinka also sent me a pic of the same remote. Well, Daikin calls it Quiet, let's call it Quiet and make equivalent to "Night" speed. I don't mind. After all, Daichi is a 3rd party controller, quite buggy BTW. I will make the change in my port later, i have higher priority tasks. BTW, i am sure you mentioned it somewhere, can't find... "Bit 5" in the doc, regarding swing, is a typo. Should be "bit 4". I will correct the doc, thanks for spotting. @dremugit thanks for LED function, we will note.

…

On Feb 8, 2024, 10:03, at 10:03, RevK ***@***.***> wrote: My understanding is *quiet* and *econo* are different things, *quiet* being a very low fan, and *econo* being less noisy outside unit. Is that not the case? -- Reply to this email directly or view it on GitHub: #126 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[err53]

Hey, I have an FTXB12AXVJU that I believe uses the same connector and protocol, and a Faikin board, is there a beta version of the firmware I can flash to help test?

[revk]

The latest beta has the CN_WIRED that we have so far.

At present it needs protocol set to 8 to talk it. Once all working well I'll make it just auto discover it.

[type-rke]

@revk c

The latest beta has the CN_WIRED that we have so far.

At present it needs protocol set to 8 to talk it. Once all working well I'll make it just auto discover it.

But am i correct that the control is not working atm ?

I can only see status changes trough the remote.
For example when i switch the remote to heat the app also updates to heat.
When i change a setting in the app, there is no response anymore.

[revk]

My understanding is that sometimes it works...

[Sonic-Amiga]

Hello there! Sad to see all the activity is gone. Are we stuck ?
The only thing i discovered is that apparently CN_WIRED is ve-e-e-ry sensitive to timings. I had a timer-interrupt-based transmitter, which could only achieve +-20us precision, and that didn't work.

I have changed to very stupid implementation, the same as Arduino bridge uses. Completely unrolled, with busyloop delays. Got 8us precision:

1524519032 Rx1 T 2608 1004 304 404 304 400 308 404 304 400 304 404 304 904 304 400 304 404 308 404 304 400 304 404 304 404 304 400 304 408 304 404 304 400 304 904 304 904 304 400 304 408 304 404 304 900 304 404 304 404 304 900 304 408 304 404 304 400 304 404 304 400 304 404 304 408 304 904 304 400 304 404 304 400 304 404 304 408 304 400 304 404 304 404 304 400 304 404 308 404 304 400 304 404 304 404 304 400 304 404 308 404 304 400 304 404 304 404 304 400 304 404 308 404 304 400 304 404 304 404 304 400 304 904 308 400 304 404 304 904 300

That's it, nothing more to play with, really. Just in case, i changed bytes [1] and [2] to 0x04 0x50, those bytes have been known to work in tests with Arduino.

Waiting for new feedback from @Glinka65 now...

[revk]

I am sure we have very exact timing. I think we are stuck at protocol level somehow. There are extra unknown messages on some models as well and unknown bytes in messages still.

[Sonic-Amiga]

Hi everyone! Very sad to see everything stopped. We've spent so much effort, and we are so close...
So far, this is what we have: We can receive data but not send. According to @type-rke we actually had it working (but unstable) at some point, then it broke.

I suggest to take a deep breath and start from scratch. Summing up what we know:

1. We know all the timings and we know they are correct.
2. When we experimented with @Glinka65 we discovered that there's really no synchronization between tx and rx. He tried disconnecting rx on original Daichi controller, leaving only tx, and it all worked just fine. One way of course.
3. We know from two people that Tx code in Arduino bridge works. The AC recognized the packet.
4. That was only ONE packet. No repeats. So sending 4 times in a row is unnecessary overcomplication at this point.
5. Here comes an interesting part. All documented successful packets look like this:
   From Glinka:

18 04 50 00 00 00 00 20_ power on
18 04 50 11 00 00 00 20_ power off

From @dremugit

23 23 00 01 01 0a 10 00_ -  power on, fan mode, Auto speed
23 23 00 11 01 0a 10 00_ - power off

Note underscore in the end. This tells the Arduino bridge to wait 16 ms HIGH and then send 2 ms LOW pulse, just like AC does. I intentionally made this an option for research purposes.
7. The code that successfully accomplishes bit-banged tx is here: https://github.com/Sonic-Amiga/ESP8266-Faikin/blob/main/Tools/Simulators/CN_WIRED/bridge/bridge.ino#L179 . Very straightforward, optimized and unrolled.

I'd suggest to remove/disable all the complex logic and just try to send one packet. There aren't very many variables to adjust here. It must work, because it has already worked.

@dremugit How is your project ? You said you want to write it from scratch to be simple, that's okay, but we need more hands and brains. Our testers are too slow to respond; and they don't have experience to make adjustments and try things on the go.

Some more stuff to think about. My ESP8266 implementation (which also fails to send), does exactly the following:

1. Receives a packet. A packet is considered received right after 64th bit is read. No waiting for 2ms pulse.
2. Delays 20 ms - this is supposed to skip over 16ms pause + 2ms LOW pulse.
3. Sends control packet (if something changed)

So this is implicitly synchronized. What if my fault is 20 ms pause ? What if i need to actually "reply" within that pause ? This is in fact the only thing that theoretically may vary. If you study really-really well, Arduino in fact does have some synchronization. It won't let you "talk over". So, if you queue a packet for tx, and rx is in progress, the packet will be held and sent right after rx is over (criteria is: last LOW space after last bit is complete). A live AC sends own packets once per second. If the user enters his packet to send in a terminal at random moment, what are chances the packet will be held, and sent right after the rx ends ?

I made some more adjustments to my code. If fails, i will try changing this "response delay". As soon as @Glinka65 responds again. I don't have anybody else to test 8266 implementation.

[type-rke]

is it possible to put back firmware from #126 (comment)

here it was working , not the best but i maybe this is a good that we test this for a longer period

[Sonic-Amiga]

It is possible to find old versions in git history. Unfortunately dear Adrian doesn't like writing commit messages, so date is all you have. You'll also have to set up your own web server and switch update URL to flash it. But that's not difficult, default Apache install works great for me. Just make "ota" folder and drop the file there.

By the way, @revk, i have spotted a (possibly major) error. CN_WIRED_1 should be 900 usecs, not 1000.

[dremugit]

Hey now, you're the one whose code says "A very simple self-explanatory data send routine" as a comment =)) I assure you that as a hardware guy who only pretends to be a coder that it is neither simpler nor self-explanatory to me. (I did work through it eventually.) I'm recovering from illness, but should have my stuff together in a day or two and be able to tell you things. I'm most interested in (1) if the trailing stuff (you use the underscore to indicate) is required, at least on my particular mini-split, and (2), what codes do what so I can give y'all a bunch of examples to play with. -- A On Tuesday, February 13, 2024 at 02:18:01 PM PST, Pavel Fedin ***@***.***> wrote: It is possible to find old versions in git history. Unfortunately dear Adrian doesn't like writing commit messages, so date is all you have. You'll also have to set up your own web server and switch update URL to flash it. But that's not difficult, default Apache install works great for me. Just make "ota" folder and drop the file there. By the way, @revk, i have spotted a (possibly major) error. CN_WIRED_1 should be 900 usecs, not 1000. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[revk]

Morning.

Happy to try any changes you suggest.
It is very easy now to create a few extra settings just for this for testing, to appear in the advanced settings tab. Eg sending that extra pulse, sending multiple times, changing bytes 1 and 2, etc, etc. suggestions welcome.

What I honestly think we need is two sided snooping on proper communications with a proper controller. Sequences of messages. So we can understand what happens with those extra bytes. I'm not in a position to do that. The Faikin does have a snoop mode, so two of them logging to MQTT can get messages both ways.

As for my commits, what can I say apart from "no comment". Sorry.

[revk]

I may make a few of these "pass through" monitoring boards...

[dremugit]

I'm not using a Faikin proper, just a regular Node32S with level shifters because it's what I had on hand. Would two of those do for your sniffing? Also, I'll need hand-holding to set up the software as I use the Arduino IDE and I *really* don't like the ESP IDF (waaaaay too complicated IMO), unless I can do it from the command-line with esptool_py and such that come with the Arduino side. Or do you want to send me one of those two sided Faikin boards ..shrug.. -- A On Tuesday, February 13, 2024 at 11:06:44 PM PST, RevK ***@***.***> wrote: Morning. Happy to try any changes you suggest. It is very easy now to create a few extra settings just for this for testing, to appear in the advanced settings tab. Eg sending that extra pulse, sending multiple times, changing bytes 1 and 2, etc, etc. suggestions welcome. What I honestly think we need is two sided snooping on proper communications with a proper controller. Sequences of messages. So we can understand what happens with those extra bytes. I'm not in a position to do that. The Faikin does have a snoop mode, so two of them logging to MQTT can get messages both ways. As for my commits, what can I say apart from "no comment". Sorry. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[revk]

Ah, I don't use Arduino IDE so no clue how to build on that (if possible). Someone else may be able to help with that.

The snoop mode is simply the Rx line tapped on to the signal, and logging what it sees. So anything than can connect to each direction can do that.

[Sonic-Amiga]

What I honestly think we need is two sided snooping on proper communications with a proper controller. Sequences of messages. So we can understand what happens with those extra bytes.

You have them: #126 (comment)

That's "daichi" 3rd party controller; but it doesn't matter because it works.
As i said, one could entirely disconnect rx and still be able to control the AC.
I also added ability to change those two bytes in my simulator and looked how Daichi responds to that. It doesn't. Completely ignores them. I change values, the same thing keeps coming from the controller.

So there should be something really-really simple we're too blind to see. The protocol is in fact simpler than you think.

I'd suggest to start with simply fixing '1' bit length. 1000 vs 900 is a big difference, the AC may reject that.

@dremugit

I'm most interested in (1) if the trailing stuff (you use the underscore to indicate) is required, at least on my particular mini-split,

You can test it. Connect Arduino and try sending power on/off with and without '_' and see when the AC reacts and when doesn't.

and (2), what codes do what so I can give y'all a bunch of examples to play with.

I think i have you a link to the documentation, where everything is described. No ? Or is the doc badly written ? In the latter case please feel free to compland and ask questions.

"A very simple self-explanatory data send routine"

Will explain by email in order not to turn the thread into coding lessons :)

Yes, being sick sucks. Been there, done that, 2 weeks ago. Get better!

[adamsguitar]

I have a unit with a CN_WIRED port that I've connected to my faikin--anything that I can do to help with testing? I don't have any additional hardware or expertise here but I can connect to another MQTT server and follow any instructions provided.

My unit is a FTXB12AXVJU

[revk]

I'll issue a beta in a bit with a lot more controls for more testing.

[revk]

... I'd suggest to start with simply fixing '1' bit length. 1000 vs 900 is a big difference, the AC may reject that.

The received timings are average 1000, well, I see 996, 1002, 1008, etc, as average for whole received sequences.

That is why I set 1000.

[revk]

@adamsguitar Latest beta, and then go to settings, unset nocnwired and set nos21 and nox50a and noswaptx and noswaprx.

[revk]

@akifrabbani I updated yours and it looks like it is crashing. I can't see why. I'll see what I can find out.

I can't change settings as password protected. I only get a few seconds between crashes.

Ah, maybe not crashing, just not seeing the CN_WIRED any more, so probably down to settings I have changed. But I can't fix if settings are locked. Can you remove the password for now?

[akifrabbani]

Hi @revk , sorry I have been busy. The password is aircon1234. I tried removing it but it does not let me to do so.

[revk]

Sorted the CN-WIRED stuff.

OK issuing beta now with working password stuff as well.

Thanks for your help.

[revk]

I am thinking this is better as a new issue #240