CRC check failed.

[Taronaga]

Hello. I repeated your experience on the NodeMcuV3 board and on the TTL HW-519

Wiring diagram Red +5 => VCC MCU A+ >TTL A B => B TTL Black GND=GND MCU

From MCU to TTL 3v => vcc ttl gnd => gnd ttl TX => RX ttl RX => TX ttl

i tested with 2 models, the result is the same: AS-10uw45vetg107g (model 2019) AS-07uw4rydd800g (model 2022)

[01:53:27][I][app:102]: ESPHome version 2023.6.5 compiled on Jul 18 2023, 01:52:40

[01:53:27][C][wifi:379]: Local MAC: 7C:87:CE:BE:3B:7C [01:53:27][C][wifi:380]: SSID: [redacted] [01:53:27][C][wifi:381]: IP Address: 192.168.9.63 [01:53:27][C][wifi:382]: BSSID: [redacted]

[01:53:27][C][wifi:386]: Signal strength: -57 dB ▂▄▆█ [01:53:27][C][wifi:390]: Channel: 6 [01:53:27][C][wifi:391]: Subnet: 255.255.255.0 [01:53:27][C][wifi:392]: Gateway: 192.168.9.1 [01:53:27][C][wifi:393]: DNS1: 192.168.9.1 [01:53:27][C][wifi:394]: DNS2: 0.0.0.0

[01:53:27][C][logger:302]: Level: DEBUG [01:53:27][C][logger:303]: Log Baud Rate: 0 [01:53:27][C][logger:305]: Hardware UART: UART0 [01:53:27][C][uart.arduino_esp8266:102]: UART Bus: [01:53:27][C][uart.arduino_esp8266:103]: TX Pin: GPIO1 [01:53:27][C][uart.arduino_esp8266:104]: RX Pin: GPIO3 [01:53:27][C][uart.arduino_esp8266:106]: RX Buffer Size: 256 [01:53:27][C][uart.arduino_esp8266:108]: Baud Rate: 9600 baud [01:53:27][C][uart.arduino_esp8266:109]: Data Bits: 8 [01:53:27][C][uart.arduino_esp8266:110]: Parity: NONE [01:53:27][C][uart.arduino_esp8266:111]: Stop bits: 1 [01:53:27][C][uart.arduino_esp8266:113]: Using hardware serial interface. [01:53:27][C][captive_portal:088]: Captive Portal:

[01:53:27][C][mdns:113]: Hostname: garage_ac [01:53:27][C][ota:093]: Over-The-Air Updates: [01:53:27][C][ota:094]: Address: garage_ac.local:8266 [01:53:27][C][ota:097]: Using Password. [01:53:27][C][api:138]: API Server: [01:53:27][C][api:139]: Address: garage_ac.local:6053 [01:53:27][C][api:141]: Using noise encryption: YES [01:53:28][D][aircon:1145]: Received 0 bytes. [01:53:28][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[01:53:30][D][aircon:1145]: Received 0 bytes. [01:53:30][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[01:53:31][D][api:102]: Accepted 192.168.9.8 [01:53:31][D][api.connection:1030]: Home Assistant 2023.7.2 (192.168.9.8): Connected successfully [01:53:32][D][aircon:1145]: Received 0 bytes. [01:53:32][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[01:53:34][D][aircon:1145]: Received 0 bytes. [01:53:34][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[01:53:36][D][aircon:1145]: Received 0 bytes. [01:53:36][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[01:53:38][D][aircon:1145]: Received 0 bytes. [01:53:38][D][aircon:1160]: CRC check failed. Computed: 0 Received: 26453 Bytes Not Read: 0

[pslawinski]

I see you are receiving a lot of bytes there. Probably as many as the buffer can hold. Maybe the baud rate is incorrect for your unit? Do you have an oscilloscope you can check with?

I'm not able to find any reference to the model numbers you listed online. Are these units from "Aircon Interntational" or from HiSense, or are they branded at something else?

Several others have posted up message structures used with hi-sense branded units, I found that I needed to modify the response structures for my AirCon branded unit. I had to do this based on trial and error, but if I recall correctly all I had to do was add some byte padding in the header section.

[Taronaga]

Hello! Marked as hisense international, model smart dc inverter, they work fine with standard modules. There is no oscilloscope, but if necessary I can buy it, I have long wanted to. If you need any action from me, please let me know, I'm very interested.

[pslawinski]

The hisense unit uses a slightly different protocol than what I've included here. If you look at the references you can see that protocol. Unfortunately I don't have a hisense unit to test on. Please let me know if you have any luck.

[Taronaga]

Hello, unfortunately, I'm not a programmer, I can only solder and test. if you could compile hicence firmware it would be very cool! Your solution with esp is very convenient!

[BenJamesAndo]

@Taronaga I managed to get it to partially work. Discussion at https://community.home-assistant.io/t/aircon-international-hisense-mini-split-control/551716/10

However as stated the responses don't work as they're designed for Aircon International. Just wondering if @pslawinski you would know how to remove the bytes padding you added? Perhaps if it's removed then it'd work properly.

I have a Hisense HAWJ9KR. This is the log when turning it on.

[13:48:32][D][uart_debug:114]: <<< FF,7F,3F,DF,77,FF,DF,FF,FF,FF,FF,FF,FF,FF,DD,77,FF,BF,F7,FF,FF,55,FF,D5,FF,F7,FF,F7,FF,FF,EF,DF,D5,FF,F3,77,FF,FF,D3,FF,FF,FF,DF,D5,FF,FD,77,F7,BB,77,FF,E7,D7,FF,FF,BB,D5,D7,D5,F7,3B,F7,FB,FF,BF,FF,FF,D7,FF,FF,77,B3,FF,55,FF,DF,FB,FF,FF,7F,F7,FF,F7,DD,FF,FF,FF,53,FF,F3,FF,7D,D5,FF,9D,BF,DF,FF,D5,FF,D3,7F,FF,FF,BB,FF,FF,DF,FF,FF,F7,7B,FB,FF,FF,FD,F3,FF,D7,BF
[13:48:32][D][climate:011]: 'Aircon Climate' - Setting
[13:48:32][D][climate:015]:   Mode: FAN_ONLY
[13:48:32][D][climate:396]: 'Aircon Climate' - Sending state:
[13:48:32][D][climate:399]:   Mode: FAN_ONLY
[13:48:32][D][climate:401]:   Action: OFF
[13:48:32][D][climate:416]:   Swing Mode: UNKNOWN
[13:48:32][D][climate:419]:   Current Temperature: nan°C
[13:48:32][D][climate:425]:   Target Temperature: nan°C
[13:48:32][V][json:038]: Attempting to allocate 512 bytes for JSON serialization
[13:48:32][V][json:058]: Size after shrink 216 bytes
[13:48:32][W][component:232]: Component web_server took a long time for an operation (101 ms).
[13:48:32][W][component:233]: Components should block for at most 30 ms.
[13:48:32][D][uart_debug:114]: >>> F4,F5,00,40,29,00,00,01,01,FE,01,00,00,65,00,00,00,00,0C,00,00,00,00,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,01,DF,F4,FB
[13:48:32][D][uart_debug:114]: <<< FF,BF,F7,57,FF,E7,D3,F7,BD,17,F7,FF,FF,FF,FF,FF,EF,99,FF,FF,A0,B1,00,40,29,00,00,01,01,FE,41,00,00,65,00,00,00,00,0C,00,00,00,00,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,01,DB,F4,FB,FF,FF,BF,7F,BF,41,41,7F,09,FD,FF,03,7F,7F,7F,7F,35,FF,FD,DB,FF,EB,CF,C5,C5,FF,FE,FD,FD,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,7D,FF,FF,FF,FF,D1,D3,CF,FF,FF,FF

[pslawinski]

@BenJamesAndo

I believe you can delete uint8_t extra[6]; from Device_Status. I also added extra bytes to pad out the header section. I can't remember exactly how many bytes I added.

I suggest using the request status message: uint8_t req_stat[] = { 0xF4, 0xF5, 0x00, 0x40, 0x0C, 0x00, 0x00, 0x01, 0x01, 0xFE, 0x01, 0x00, 0x00, 0x66, 0x00, 0x00, 0x00, 0x01, 0xB3, 0xF4, 0xFB};

Query the unit and see how long it's response is. On my unit I get back 82 bytes, I determined experimentally that I needed to pad the headers out to get data to line up with the struct. You could try removing bytes from the "header" array until the data lines up.

That said, your response data above looks odd to me. The responses I get back from the unit all start with F4F5

[BenJamesAndo]

Hey, thanks so much for your help. Yes it is kinda weird that a lot of the responses don't start with F4F5. My unit is querying that exact request status message regularly. These are two of the responses I get back.

[11:21:42][D][uart_debug:114]: >>> F4,F5,00,40,0C,00,00,01,01,FE,01,00,00,66,00,00,00,01,B3,F4,FB
[11:21:42][D][uart_debug:114]: <<< F4,F5,00,40,0C,00,00,01,01,FE,01,00,00,66,00,00,00,01,B3,F4,FB
[11:21:42][D][uart_debug:114]: <<< 41,41,7F,E5,7F,03,7F,7F,7F,7F,33,FF,FD,FF,FF,BB,CB,CB,CB,FF,FE,FD,BD,FF,FF,FF,FF,FF,FF,FF,FF,FF,F5,FF,FF,FF,FF,FF,C7,CB,C7,FF,FF,FF,37,FF,FF,FF,FF,6F,FF,FF,FB,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,6F,F1,D1,41,E0
[11:21:42][W][component:232]: Component <unknown> took a long time for an operation (59 ms).
[11:21:42][W][component:233]: Components should block for at most 30 ms.

[11:39:17][D][uart_debug:114]: >>> F4,F5,00,40,0C,00,00,01,01,FE,01,00,00,66,00,00,00,01,B3,F4,FB
[11:39:17][D][uart_debug:114]: <<< F4,F5,00,40,0C,00,00,01,01,FE,01,00,00,66,00,00,00,01,B3,F4,FB,41,41,7F,E5,7F,03,7F,7F,7F,7F,33,FF,FD,FF,FF,BB,CB,C9,CB,FF,FE,FD,BD,FF,FF,FF,FF,FF,FF,FF,FF,FF,F5,FF,FF,FF,FF,FF,C7,CB,C7,FF,FF,FF,37,FF,FF,FF,FF,6F,FF,FF,FB,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF
[11:39:17][W][component:232]: Component <unknown> took a long time for an operation (59 ms).
[11:39:17][W][component:233]: Components should block for at most 30 ms.

The first example is quite common. I always get the same response back, followed by a second response that usually starts with 41 or 17. In the second example it returns the response code plus attaching 41... to the end. Is it 300 bytes? I'm guessing I modify this bit of code uint8_t header[16]; Do I also modify this line? msg_size = input + 9; // add header and footer bytes + this byte

[pslawinski]

The messages I get are 82 bytes and appear to have quite different formatting to what you're getting. I think you're going to have to modify the code structure quite a bit to get this to work for you.

When I wrote this I used a serial adapter for the computer to send messages and capture the replies. By changing the temperature, fan speed, etc, I was able to discern what the different fields in the response messages meant. Just look for the bytes that change from reply to reply and see if they correspond to the temperature etc...