Timeout errors and after "fixing", 'no ACK' errors. SOLVED :D:D:D:D:D Works with FTKS25DVM and esp8266 d1 mini

[fusionstream]

Indoor unit: FTKS25DVM
Board: esp8266 Wemos d1 mini

When using the default sample configuration with GPIO1 and GPIO 3 (TX and RX), I get timeout errors in the exact same manner as this issue #15 . Although I didn't use level shifters, I did try out the 10k 5V pull up resistor without joy. I also tried the inverted pin sample configuration.

When changing pins to use the 2nd UART for RX (GPIO13/D7 for RX) and using the inverted sample configuration, I got no ACK errors ala this issue #17

However, when reverting to the original sample configuration (no inverted pin I guess) but changing the RX pin to the 2nd UART, it works beautifully. As I understand it, one of these UARTs is running on software serial which is probably why I keep getting the warning:
Component daikin_s21 took a long time for an operation (557 ms). I also removed the 10k 5V pullup and it still works.

It might be worth swapping the TX and RX UARTs to see if we can force the RX on hardware serial.

So. To recap.

• On a d1 mini, the pinout of the S21 connector is exactly as documented on the Faikin wiki,
• No level shifters are required (though it should be noted on the 8266, this is never officially guaranteed)

Pinout is

• GND->GND
• AC TX to d1 mini GPIO13 (D7) as RX
• AC RX to d1 mini GPIO1 (TX) as TX

All are wired directly. I'm using a powerbank to power the d1 mini right now (with common ground) so the next step is to power it from the measured 14V pin via a step down.

Hope this helps!

[fusionstream]

Would be cool to add the icon mdi:air-conditioner by default and logger level to warn

[Sonic-Amiga]

Hello!
I am from a different project, but got a stupid question. How do you reconfigure pin13 to become rx1 ?
The datasheet says:
GPIO13; HSPI_MOSI; UART0_CTS
Regarding UART1, only TXD is mentioned on GPIO2

Is there some 8266 API i am not aware of ?

[Sonic-Amiga]

By the way, FYI, our (with RevK) project works successfully on just one UART. From his git log i see that some ACs just don't send ACK, starting straight with response.
Welcome to my (or RevK) repo for all the quirks.

[Sonic-Amiga]

After some googling: https://esphome.io/components/uart.html
I see, you're using software UART1 and you don't use hardware one, which is indeed TX-only.

[fusionstream]

As I understand it, I'm using software RX and hardware TX but have just changed it to hardware RX and software TX

[fusionstream]

Running this on a d1 mini-esp32, using UART2 with GPIO17 as TX and GPIO16 as RX also works so all hardware here. I'm testing this out because running this with separate UARTs (hardware + serial) seems to cause frequent rebooting.

Update:
And it seems to solve the issue. Full hardware UART and seemingly no reboots so far with this component when running on an esp32.

[Sonic-Amiga]

Again, that's totally weird. There are no such limitations in nature :) Rx and Tx lines of a serial port are completely independent and asynchronous; that's called "full duplex".

My simplest explanation would be you're messing up pins. The phenomena you're describing simply doesn't exist. Or, extraordinary claims require extraordinary proof - by snooping the line, prove me wrong please.

[fusionstream]

Simply not possible to mess up pins here. There's basically 4 lines. If the power is wrong, it won't turn on; and if the TX/RX is wrong TX wouldn't have worked.

I'll try and get a snoop going. I tried it before opening this issue but I think my PL2303 is dead (not the driver). Waiting on parts