F1 no ACK on S21 protocol, d1mini with FTKS25DVM #20
Comments
|
Hugh... yet another protocol variation apparently. |
|
BTW, what is the exact error message ? |
Just spotted this. You've messed up; RX is GPIO 3, not GPIO 13. You aren't receiving anything at all. |
|
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. |
|
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. |
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. |
Faikin does not have software RX.
Yes, that's what we should do first.
Shouldn't be any different. 8266 is 8266 anyways |
|
Turns out one was a pro and one was a normal one already state/< device > state/< device >/status error/< device >/comms info/< device >/tx info/< device >/s21 |
|
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. |
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...
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: 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. |
|
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? |
|
Stop stop stop... We are messing it all up. 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.
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. |
|
Checked GPIO code in Faikin-ESP32; indeed, pins 1 and 3 are reserved for debug port. You can't use them for comms. |
|
Solid copy on why the esp32 build not working UART0, and works any UART2 (or any other pin) is as such. |
|
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: Not sure it the Then I've tried four different ways to connect the RX - TX and nothing works ('System is offline.'):
Error messages: state/status: error/comms: At the moment I don't know if there is a problem in software or the RX-TX lines. |
|
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](https://cdn.sparkfun.com/datasheets/BreakoutBoards/Logic_Level_Bidirectional.pdf)
- 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:
#20 (comment)
You are receiving this because you commented.
Message ID:
***@***.***>
|
|
So far, to sum things up, you guys have no communication with the AC whatsoever. This means Faikin is cycling through protocol it knows for auto-detection and keeps failing. No response. |
|
Thanks for helping out! First, can you check if this is the correct port: S21 I modified a JST PH connector and extended the wires 0,75meter: Below the photos of the circuits I tried: 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 FETs are 2N7000, not 2N7002 |
|
I see, it all looks correct. S21 connector is the one marked as such, 5 pins.
I'll tell you what to send tomorrow, need some time for that. |
|
Ah sorry, it's right in this thread. The hex data to send is: |
|
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. |
|
Suddenly found some new info. https://github.com/revk/ESP32-Faikin/wiki . He says:
Since 8266 is 3.3v, you might be experiencing the same problem. Apparently level shifters are highly recommended. 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?
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! |
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.
It's definitely some HW issue.
This reference is most likely weak.
Should work.
Oscilloscope would be better, it would be able to see if voltage is too low; or signal is corrupt, etc. |
|
In order to assist the troubleshooting, i made another release, where i fixed loopback indication. If this message doesn't come up, something is wrong with tx/rx. You can use it to verify your level shifters. |
|
The update has been released to both OTA servers. |
|
Thanks for your great support! 
In both cases the result is positive, so it looks like the UART and level shifter are okay. |
|
Speed s 2400, so wire length is very unlikely the culprit.
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 #21 |
I checked, those are non-inverting. |
|
Hi Pavel, |
|
Wow, congratulations and thank you very much for time spent and sharing results! 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. |
|
No problem, see schematic with used components in the symbol properties below: Sorry I have no photo of the final board because I switched to the ESP32. |
|
Thank you very much for contribution anyways! |
|
Sorry, the answer is on the sheet, i should really look up sometimes :) |
|
Your Welcome! |
|
Hello, I am not sure if I should ask this in this thread or open a new one. 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? |
|
Hm, that's weird... 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. |
|
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: 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 What seems to be running properly:
Now for the crazy things: When connecting a USB to TTL device I get the following issues: Settings:
Both my D1 mini boards behave exactly the same and in a stable way. I am completely puzzled here. |
|
Hello Pavel, 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. |
|
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? |
|
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. |
|
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. 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.. The puzzle goes on. My old Wemos D1 16Mb runs fine! |
|
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? |
|
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) |
|
I'll have some time tomorrow to play with this. I'll flash my backed up Daichi firmware and see how this thing talks. |
|
Brothers in mind are here (russian language): https://4pda.to/forum/index.php?showtopic=1028652&st=2200 |
|
Hi again! =) |
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.
joshbenner/esphome-daikin-s21#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?
The text was updated successfully, but these errors were encountered: