F1 no ACK on S21 protocol, d1mini with FTKS25DVM

[fusionstream]

Hi. I'm exploring my options to control my Daikin.

When flashing this to a d1 mini pro, system remains offline but commands can be sent to the aircon.

Specifically, based on MQTT debug the error is that F1 has no ACK.

Based on my own testing with the s21 protocol in esphome, it seems you can't use the same UART for tx and receive. https://github.com/joshbenner/esphome-daikin-s21/issues/25

I am wondering if this is the same issue. I had to use GPIO1(RX) as TX and GPIO13(D7) as RX.

Also, I had assumed this would appear in Home Assistant as is but maybe that's not the case?

[Sonic-Amiga]

Hugh... yet another protocol variation apparently. Please enable "debug" and "dump" and send me some logs. Let's have a look at what's going on. No, the same UART perfectly works in both directions; we've been doing that for ages, and i actually am successfully running Faikin at home on my S21 aircon.

[Sonic-Amiga]

BTW, what is the exact error message ?

[Sonic-Amiga]

I had to use GPIO1(RX) as TX and GPIO13(D7) as RX.

Just spotted this. You've messed up; RX is GPIO 3, not GPIO 13. You aren't receiving anything at all. 8266 only has one fully usable UART0. UART1 has no RX pin at all, only TX, so it's basically only usable for logging. So, you don't really have options.

[Sonic-Amiga]

And yes, Faikin-8266 currently doesn't work with UART1 as according to datasheet it only has TX pin. I'm surprised that may change.

[Sonic-Amiga]

Sorted out by googling. No, Faikin does not (and will not) use software UARTs. Too much overhead with too little profit. So, just change your RX to the proper one.

[fusionstream]

I had to use GPIO1(RX) as TX and GPIO13(D7) as RX.

Just spotted this. You've messed up; RX is GPIO 3, not GPIO 13. You aren't receiving anything at all. 8266 only has one fully usable UART0. UART1 has no RX pin at all, only TX, so it's basically only usable for logging. So, you don't really have options.

Nope. That's the point. It only works when using software RX and hardware TX (although in that thread I've replied to you mentioning I've just started using hardware RX and software TX to mitigate latency).

There's definitely something else going on with that implementation though because breaking out the UART to individual pins in code fails. The split only works if implemented as one UART, if that makes sense. There's a lot of things hidden in esphome.

Using the real hardware TX/RX on the faikin gets me an F1 no ACK error. Will send the dump+debug in approximately 12 hours. Will also give it a go on a normal d1mini instead of the 2x pros I've tried it on.

[Sonic-Amiga]

It only works when using software RX and hardware TX

Faikin does not have software RX.

Using the real hardware TX/RX on the faikin gets me an F1 no ACK error. Will send the dump+debug in approximately 12 hours.

Yes, that's what we should do first.

Will also give it a go on a normal d1mini instead of the 2x pros I've tried it on.

Shouldn't be any different. 8266 is 8266 anyways

[fusionstream]

Turns out one was a pro and one was a normal one already

state/< device > {"id":"< id/mac >","up":true,"uptime":3,"mqtt-up":1,"app":"Faikin","version":"aa12406","build-suffix":"-8266","build":"2024-07-12T00:19:02","flash":64,"rst":2,"mem":37892,"ssid":"< ssid >","bssid":"< bssid >","rssi":-25,"chan":1,"ipv4":"< ip >"}

state/< device >/status {"protocol":"S21","online":false,"autor":0.0,"autot":0.0,"auto0":"00:00","auto1":"00:00","autop":false}

error/< device >/comms {"protocol":"S21","cmd":"F1","noack":true}

info/< device >/tx {"protocol":"S21","dump":"0246317703","F1":""}

info/< device >/s21 {}

[fusionstream]

I can confirm that both that other esphome "library" (when running on an esp32) and revk's esp32 build work when running on UART2 (hardware UART); on an esp32.

[Sonic-Amiga]

and revk's esp32 build work when running on UART2 (hardware UART); on an esp32

So... Do you want to say it works with uart2 and does not work with uart1 ? That would be weird, as esp32 has gpio matrix switch; and it can internally connect any pin to any device. And uart's are fully identical.

From your log i can understand that Faikin is not getting any reply whatsoever. Are you sure tx/rx aren't swapped ?

After careful reading...

I had to use GPIO1(RX) as TX and GPIO13(D7) as RX.

GPIO1 is TX (from Faikin to A/C) and GPIO 3 is Rx (from A/C to Faikin). And on 8266 this is NOT reconfigurable!

Pins are normally named relative to the device they belong to. So, on A/C side these would seem swapped. Because what A/C sends, Faikin is gonna receive, and vice versa:

Faikin         A/C
1 TX ---------- RX
3 RX ---------- TX

Symptoms you're describing (doesn't work on the same UART) are weird. Such a limitation doesn't exist.

BTW, just trying to swap rx/tx should not be dangerous.

[fusionstream]

Just tried swapping again. No joy.

And yup, I'm saying UART0(not UART1) pin 1 and 3 on the esp32 with revk's esp32 build does not work. UART2 works and UART1 is untested.

Are you also using d1 minis for this 8266 build?

[Sonic-Amiga]

Stop stop stop... We are messing it all up. First of all, we are on 8266 turf. So, when i am talking about pin 1 and 3 with UART0, i mean 8266.

ESP32 is all different beast. It has what's called matrix switch. It also has 3 UARTs. So any pin can be connected to any UART (or whatever else) under software control.

ESP32-Faikin uses UART1 by default. And that can only be switched by a hidden setting, which is only accessible by json commands over mqtt. When you change pins in settings (rx/tx), you simply change which pins are connected to that UART. So, you must program there pins which you use for connecting to the A/C. Minus sign stands for inversion; that's there by default because Faikin board has inverting level shifters for simplicity.

And some pins are reserved on ESP32 for special internal functions (like interfacing EEPROM chip), so it's possible that you just can't use them.

UART0 is also (sort of) reserved because some debug logging is sent there. In order to use it for external comms, additional code is needed to turn off that logging. 8266 port has that code (because there's only one port available), ESP32 version doesn't have it because there's no need to. Actually having a separate debug UART makes development a lot easier.

Are you also using d1 minis for this 8266 build?

No, i am using russian-designed board called "Daichi". It's an import-substituted(tm) Yandex-friendly and nothing-else-friendly A/C controller, which is now sold here by installers instead of original stuff. I am using it because i already own it with my AC; and that's how this port started. You may see the schematics in Hardware/ folder, there's nothing special there.

[Sonic-Amiga]

Checked GPIO code in Faikin-ESP32; indeed, pins 1 and 3 are reserved for debug port. You can't use them for comms.

[fusionstream]

Solid copy on why the esp32 build not working UART0, and works any UART2 (or any other pin) is as such.

[Cees-tech]

Hi, I think I might have a similar problem. Please let me know if it's okay to ask this here or to start a new issue?

I'm trying to make ESP8266-Faikin work on an AZ-Delivery D1 Mini NodeMcu met ESP8266-12F WLAN-module

But I not able to get communication going between the AC and ESP. Now sure if it's software or hardware related.

I've used this ESPtool command to flash: esptool.py -b 460800 --after hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 8MB 0x8000 partition-table-8266.bin 0xd000 ota_data_initial-8266.bin 0x0 Faikin-8266-bootloader.bin 0x10000 Faikin-8266.bin

Not sure it the --flash_size 8MB 0x8000 is a problem because the chip has only 4Mb flash... But flashing succeeded and I'm able to load the web interface: Does this mean all bins are flashed correctly?

Then I've tried four different ways to connect the RX - TX and nothing works ('System is offline.'):

• With this logic level translator: see link
• With two 2N7000 FETs as in 'Faikin.kicad_sch' (ESP32-Faikin-main)
• With two 2N7000 FETs as 'Daichi_controller.kicad_sch' (ESP8266-Faikin-main) Used a FET instead of the opto coupler
• Direct connection without level translation

Error messages: state/485519F31AB2:

{
  "id": "485519F31AB2",
  "up": true,
  "uptime": 5,
  "mqtt-up": 1,
  "app": "Faikin",
  "version": "c8f49f5",
  "build-suffix": "-8266",
  "build": "2024-07-26T21:39:51",
  "flash": 64,
  "rst": 3,
  "mem": 36544,
  "ssid": "",
  "bssid": "",
  "rssi": -62,
  "chan": 4,
  "ipv4": "192.168.2.25",
  "online": false,
  "target": null
}

state/status: { "protocol": "S21", "online": false, "autor": 0, "autot": 0, "auto0": "00:00", "auto1": "00:00", "autop": false} info/s21: {} info/tx:

{ "protocol": "S21", "dump": "0246317703", "F1": ""}
{"protocol":"X50A","dump":"06AA0701000146"}
{"protocol":"X50A","cmd":"AA","payload":"01"}

error/comms:

{"protocol":"S21","cmd":"F1","noack":true}
{"protocol":"X50A","timeout":true}
{"protocol":"CN_WIRED","timeout":true}

At the moment I don't know if there is a problem in software or the RX-TX lines. Hopefully there are some ideas what I can do to get this working? Thanks in advance, Cees

[Sonic-Amiga]

Hello! Yes, it's okay to discuss it here. It is indeed most likely the same problem. And i think i know what doesn't work.

It's very unlikely software problem. But if you look carefully at Daichi schematic; and also at Faikin-ESP32 schematic (in revk's repo), you will see a  +5V generator. In Esp32 that's a poor man's resistor. According to S21 docs (also in the repo), the A/C may need a +5V reference from the controller. Perhaps this is what both of you lack. I am not at home, replying from mobile phone, so sorry for vague description. I will draw some diagrams when back at home

UPD: I MISTAKEN regarding +5V. It's generated by the AC. I was confused by +5V tap in Daichi.

On Aug 1, 2024, 21:08, at 21:08, Cees-tech @.***> wrote:

Hi, I think I might have a similar problem. Please let me know if it's okay to ask this here or to start a new issue?

I'm trying to make ESP8266-Faikin work on an AZ-Delivery D1 Mini NodeMcu met ESP8266-12F WLAN-module

But I not able to get communication going between the AC and ESP. Now sure if it's software or hardware related.

I've used this ESPtool command to flash: esptool.py -b 460800 --after hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 8MB 0x8000 partition-table-8266.bin 0xd000 ota_data_initial-8266.bin 0x0 Faikin-8266-bootloader.bin 0x10000 Faikin-8266.bin

Not sure it the --flash_size 8MB 0x8000 is a problem because the chip has only 4Mb flash... But flashing succeeded and I'm able to load the web interface: Does this mean all bins are flashed correctly?

Then I've tried four different ways to connect the RX - TX and nothing works ('System is offline.'):

• With this logic level translator: see link
• With two 2N7000 FETs as in 'Faikin.kicad_sch' (ESP32-Faikin-main)
• With two 2N7000 FETs as 'Daichi_controller.kicad_sch' (ESP8266-Faikin-main) Used a FET instead of the opto coupler
• Direct connection without level translation

Error messages: state/485519F31AB2:

{
 "id": "485519F31AB2",
 "up": true,
 "uptime": 5,
 "mqtt-up": 1,
 "app": "Faikin",
 "version": "c8f49f5",
 "build-suffix": "-8266",
 "build": "2024-07-26T21:39:51",
 "flash": 64,
 "rst": 3,
 "mem": 36544,
 "ssid": "",
 "bssid": "",
 "rssi": -62,
 "chan": 4,
 "ipv4": "192.168.2.25",
 "online": false,
 "target": null
}

state/status: { "protocol": "S21", "online": false, "autor": 0, "autot": 0, "auto0": "00:00", "auto1": "00:00", "autop": false} info/s21: {} info/tx:

{ "protocol": "S21", "dump": "0246317703", "F1": ""}
{"protocol":"X50A","dump":"06AA0701000146"}
{"protocol":"X50A","cmd":"AA","payload":"01"}

error/comms:

{"protocol":"S21","cmd":"F1","noack":true}
{"protocol":"X50A","timeout":true}
{"protocol":"CN_WIRED","timeout":true}

At the moment I don't know if there is a problem in software or the RX-TX lines. Hopefully there are some ideas what I can do to get this working? Thanks in advance, Cees

-- Reply to this email directly or view it on GitHub: https://github.com/Sonic-Amiga/ESP8266-Faikin/issues/20#issuecomment-2263665204 You are receiving this because you commented.

Message ID: @.***>

[Sonic-Amiga]

So far, to sum things up, you guys have no communication with the AC whatsoever.

{"protocol":"S21","cmd":"F1","noack":true}
{"protocol":"X50A","timeout":true}
{"protocol":"CN_WIRED","timeout":true}

This means Faikin is cycling through protocol it knows for auto-detection and keeps failing. No response. @Cees-tech You said you tried level converter. What did you use for 5V power ? How exactly did you connect it ?

[Cees-tech]

Thanks for helping out! Yes, I've used the 5V from the AC on all configurations that I tested. I've made some photos of these circuits on the bread board.

First, can you check if this is the correct port: S21

I modified a JST PH connector and extended the wires 0,75meter: 1 5V Orange 2 TX Green 3 RX White-Blue 4 14V Brown 5 GND Blue

Below the photos of the circuits I tried: With this logic level translator:

With two 2N7000 FETs as in 'Faikin.kicad_sch' (ESP32-Faikin-main)

With two 2N7000 FETs as 'Daichi_controller.kicad_sch' (ESP8266-Faikin-main) Used a FET instead of the opto coupler

Direct connection without level translation No pic, Green wire (TX) directly on ESP RX and White-Blue wire (RX) directly on ESP TX

FETs are 2N7000, not 2N7002 Hopefully this info helps!

[Sonic-Amiga]

I see, it all looks correct. S21 connector is the one marked as such, 5 pins. Hmmmm... Sorry i am busy this evening, but let's go back to the basics. We need one of:

1. Connect S21 to a PC running hex terminal using e. g. USB<>Serial adaptor. I'll tell you what to send, the A/C should reply.
2. Take two such adaptors and connect two RX lines in parallel to S21 tx/rx. Let's see what goes wrong.

I'll tell you what to send tomorrow, need some time for that.

[Sonic-Amiga]

Ah sorry, it's right in this thread. The hex data to send is: 0246317703 The response should start with 0602. Parameters are 2400 8E2

[Sonic-Amiga]

UPD: nothing really wrong with your connections. And i actually don't know what FETs Daichi uses; they have no markings; i simply chose something with proper pinout from kicad library.

[Sonic-Amiga]

Suddenly found some new info. https://github.com/revk/ESP32-Faikin/wiki . He says:

the older boards with 3.3V Tx which works with most, but not all, S21 interfaces

Since 8266 is 3.3v, you might be experiencing the same problem. Apparently level shifters are highly recommended. @Cees-tech Have you actually checked that AC really provides 5V reference ? RevK's S21 doc mentions that sometines that pin may be just unused.

Try the same approach as Daichi does: generate intermediate 5V reference for yourself.

[Cees-tech]

@Cees-tech Have you actually checked that AC really provides 5V reference ? RevK's S21 doc mentions that sometines that pin may be just unused.

Try the same approach as Daichi does: generate intermediate 5V reference for yourself.

Yes, my AC does provide the 5V ref and I used it with 10K pull up on the RX side of the AC. Do you also think it's better to use this 5V reference instead of the 5V generated to power the ESP?

1. Connect S21 to a PC running hex terminal using e. g. USB<>Serial adaptor. I'll tell you what to send, the A/C should reply.
2. Take two such adaptors and connect two RX lines in parallel to S21 tx/rx. Let's see what goes wrong.

I don't have a USB-serial adapter here, tried it with another ESP using ESPlink but no succes. I will buy an FTDI FT232RL Adapter and a logic analyzer this week so I can take a closer look!

[Sonic-Amiga]

I don't have a USB-serial adapter here

I successfully used this: https://www.waveshare.com/pl2303-usb-uart-board-mini.htm . Yes, i did some experiments on my A/C with it on early stages. Just set it to 5V I/O and it works.

tried it with another ESP using ESPlink but no success.

It's definitely some HW issue.

AC does provide the 5V ref and I used it with 10K pull up on the RX side of the AC. Do you also think it's better to use this 5V reference instead of the 5V generated to power the ESP?

This reference is most likely weak.

I will buy an FTDI FT232RL Adapter

Should work.

and a logic analyzer this week so I can take a closer look!

Oscilloscope would be better, it would be able to see if voltage is too low; or signal is corrupt, etc.

[Sonic-Amiga]

In order to assist the troubleshooting, i made another release, where i fixed loopback indication. Faikin has a built-in smoke test. If you power it up with rx and tx connected together; it will notice that and display "System is in loopback test" message

If this message doesn't come up, something is wrong with tx/rx. You can use it to verify your level shifters.

[Sonic-Amiga]

The update has been released to both OTA servers.

[Cees-tech]

Thanks for your great support! I've tested on new release with RX-TX looped directly at the ESP and then looped at the 5V side of the Logic Level Converter (Sparkfun BOB-12009).

In both cases the result is positive, so it looks like the UART and level shifter are okay. I extended the S21 port with 5 single wires of 1 meter each to reach my bread board. Perhaps this is too long?

[Sonic-Amiga]

Speed s 2400, so wire length is very unlikely the culprit. So, next step would be to understand one of two:

1. A/C does not get the data
2. Faikin does not get the response. You may figure that out by listening on PC via a usb-serial adaptor. Just hook up rx to the line and see if anything is coming. Or by probing with oscilloscope, which you don't have.

Sorry for being little of help here; but that's not going to be software issue. Because serial port is just a serial port, and S21 is just S21. We know that it all works on original Faikin; and it also works great on my "Daichi" board, so there are definitely some fine details about the hardware.

By the way, make sure your level shifters are noninverting. Because if they are inverting, that's a known issue and we are working on it in https://github.com/Sonic-Amiga/ESP8266-Faikin/issues/21

[Sonic-Amiga]

Sparkfun BOB-12009

I checked, those are non-inverting. Short answer: i don't know why it doesn't work. It should. You'll have to do some advanced troubleshooting, i gave you directions.

[Cees-tech]

Hi Pavel, I solved the problem by reducing the wire length from 1mtr to 10cm. With shorter wires and the Sparkfun BOB-12009 it connects without problems. So wire length/impedance is important. I've my final circuit with thicker and bundled wires. FYI I made the final version with ESP32 so I will be using the software of the main ESP project. For me this issue is solved and might be closed. Thank you very much for your help!

[Sonic-Amiga]

Wow, congratulations and thank you very much for time spent and sharing results! I'd appreciate if you document your final working design, diagram and a prototype photo maybe; i'll include it into Hardware/ . Looks like the interface is sensitive as f*ck. Maybe pull-ups need some fine tuning... Well, done is done.

I can only say that in my early experiment i connected a PL2303, inserted into my laptop, directly to my AC using an old USB cable, which is 1.5m long (however it's well shielded and quite thick). The connection worked, i was able to send and receive some data.

Another interesting thing happened to my first user, Glinka65. One of his ACs also refused to work reliably, it was losing link often. It turned out that he had an earlier revision of Daichi board, which had simplified level shifters using zener diodes or something like that. And it produced lots of noise on Rx line. He modded his Daichi and installed mosfet instead of zener diode to fix that.

So, physical level can be quirky.

[Cees-tech]

No problem, see schematic with used components in the symbol properties below: Faikin ESP8266.kicad_sch.zip

Sorry I have no photo of the final board because I switched to the ESP32.

[Sonic-Amiga]

Thank you very much for contribution anyways! How did you obtain 5V in the end ? Using a regulator or 5V pin on the A/C ?

[Sonic-Amiga]

Sorry, the answer is on the sheet, i should really look up sometimes :) I guess, the problem is done. Thank you very much for sharing what you've done.

[Cees-tech]

Your Welcome! Yes, I've used 5V from the regulator for the level shifter. +5V from AC is not connected.

[CPtje]

Hello, I am not sure if I should ask this in this thread or open a new one. I have a couple of Wemos D1 mini V4.0.0. These are 4Mb. After programming them I find them online and can alter settings.

However, if I simply connect TX (GPIO1) and RX(GPIO3), there is no message indicating a loop. I tested this with both boards and they both fail the loop test. I also tested one of the boards on the Aircon (S21), using level shifters, and it failed (obviously).

I have programmed and tested both the current release and current beta-release. Unfortunately the same result.

Anything else that I can try?

[Sonic-Amiga]

Hm, that's weird... First of all, what i see could be extremely flaky. I'd suggest you to solder on a connector; because it could be that these pins are not making a proper contact if just inserted like this.

Next, i see USB port connected to something. Keep in mind that there is a USB<>Serial adaptor, sitting on the same UART. And some interference is possible.

[CPtje]

Thank you, Pavel, for helping me to figure this out. To be honest, things are getting weirder and I am just really puzzled about what is happening. Here are some things I tested.

First of all, what am I using: Wemos D1 mini V4.0.0 4Mb Detecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi Crystal is 26MHz Detecting Flash Size FlashId: 0x164068 Flash Manufacturer: 68 Flash Device: 4016 Auto-detected Flash size: 4MB

At this moment I have programmed the following betarelease according to "Faikin-8266.desc": Faikin 18:05:46 Aug 10 2024 v3.4-108-g90991a0c The Faikin home screen displays:

What seems to be running properly:

• Faikin
• MQTT
• Settings can be changed and are remembered even when programming everything new.

Now for the crazy things: When connecting TX to RX no loopback is detected!

When connecting a USB to TTL device I get the following issues: TX and RX are NOT inverted!

Settings: Result in SerialTool: Every 5 seconds receiving HEX: 41 82

Result in SerialTool: Every 5 seconds receiving HEX: 41 82

Result in SerialTool: NOTHING ????? NO DATA !!

Both my D1 mini boards behave exactly the same and in a stable way.

I am completely puzzled here.

[CPtje]

Hello Pavel, Decided to test an older Wemos D1 pro 16Mb board from an existing project. And guess what.... it works with backloop without issues.

For now I would say that the wemos D1 V4.0.0 4Mb is causing the problems.

Although I would certainly like to know how and why, I don't know if we should invest the time and effort. If you like we can test further, but I can also go on with using the older versions.

[Sonic-Amiga]

Interesting. Definitely looks like an electronic issue

In your test what are SerialTool port settings ? 41 82 could be corrupted version of X50A handshake, those are actually 0xAA 0x01 0xBA 0xBB.

X50A is 9600 8e1; S21 is 2400 8e2

You know; i am experiencing compatibility issues with cheap chinese Arduinos using ch340 usb-serial bridge on Windows OS, Simply no communication. Your issue could be of similar nature.

Are there any differences in main 8266 module?

[CPtje]

It seems indeed that I am receiving data from X50A and not from S21.

In the meantime, I have added level shifters to the old Wemos D1 16Mb board and connected it to my Daiking Perfera floor standing unit. Everything is running fine, as expected.

It might be that there is somehow something going wrong with programming a 4Mb board. I don't know. Next week I will try the 4Mb board for serial communication with programming ESPeasy. In that why we know if the hardware is working or not.

[CPtje]

Found some time to test the new Wemos D1 v4.0.0 4Mb with ESPeasy and there are no problems with the serial com hardware. ESPeasy dumps all log-data over the serial port with 115kbaud and this is received flawlessly by SerialTool.

I guess something goes wrong when programming the Wemos D1 v4.0.0 4Mb board with the existing release. I do not know if someone else has been able to program a 4Mb board and get it running?

Just to be sure I ran over the whole procedure again with the V4.0.0 board and at first there was definitely no S21 data at all with 2400-8-E-2. Strange enough, when setting to X50A with 9600 8e1, I get continuously following HEX data: 06 AA 07 01 00 01 46

After that I set the Faikin to Dump=off, Debug=off, Snoop=off. Then I set it to S21 only. Now I get continuously following HEX data: 02 46 31 77 03, which is ASCII: F1w.. Loopback is still not recognised.

The puzzle goes on.

My old Wemos D1 16Mb runs fine!

[contik0]

Hello! I just tried to reflash original DW22-B WiFi module in my Daichi Air50AVQS1R. I can use web interface but device in "System is offline"-status. Before reflashing original Daichi Comfort Application works without problem. Which way i have to dig it?

[Sonic-Amiga]

Hello! Most likely the problem happens because Daichi isn't Daikin; and this A/C doesn't speak any of 3 known Daikin protocols. The Faikin firmware targets Daikin aircons explicitly.

Together we can try reverse-engineering it; i already have an experience of reversing a CN_WIRED Daikin protocol without having the actual A/C. This will take time, however.

For the time being, if you didn't save your stock firmware, i can send an image to you (i did, and sometimes use it for experiments).

No, you won't find any other project working with Daichi because that's russian-only brand (albeit of course it's gonna be compatible with some chinese noname, but we don't know which one)

[Sonic-Amiga]

I'll have some time tomorrow to play with this. I'll flash my backed up Daichi firmware and see how this thing talks.

[Sonic-Amiga]

Brothers in mind are here (russian language): https://4pda.to/forum/index.php?showtopic=1028652&st=2200

[contik0]

Hi again! =) I don't know is it possible here or not, but - i try to find your email at yandex, but found only old email at rambler - its doesn't work. Could you write me at "contik at biker.ru". I have two pcs of Daichi A/C: one with original firmware and another one with Faikin firmware. I ready to make a some tests with commands and etc ... =) BTW, i read the link you gave me - doesn't help =(