Closed Lastik-Lastikov closed 1 year ago
Feeling that it's does not respond to requests at all. It could be assumed that there are problems with the physical connection. But with ESPHome "Haier Climate" standard integration, the air conditioner makes a beep when it is turned off. ANdt thats' all.
Hi @Lastik-Lastikov , Yes, you are right. For smarthair2 WAITING_FIRST_STATUS_ANSWER means that there is no answer to the first request so actually nobody is answering from the AC side. It can be any hardware or configuration problems: wrong pins for UART, problems with wires, wrong protocol etc. Beeping for standard integration can be a signal that you have a problem with noise (interference).
I have a similar problem with AS25NHPHRA which uses Haier Smart Air2 (production date 03/2021).
My device is NodeMCU V3 LoLin (board: nodemcuv2). Connection wires are from UTP Cat5e cable. They are not twisted.
Standard integration always says that AC is off.
This integration in smartAir2 mode shows the following error:
[12:28:32][D][haier.protocol:019]: Sending frame: type 01, data: 4D 01
[12:28:32][W][haier.climate:170]: Answer timeout for command 01, phase WAITING_FIRST_STATUS_ANSWER
This integration in hOn mode says that it gets an invalid answer:
[12:30:03][D][haier.protocol:019]: Sending frame: type 61, data: 00 07
[12:30:03][W][haier.climate:170]: Answer timeout for command 61, phase WAITING_ANSWER_INIT_1
[12:30:03][D][haier.protocol:019]: Frame found: type 62, data: 45 2B 2B 32 2E 31 38 00 31 39 30 38 31 39 30 30 F1 00 00 31 37 30 35 32 36 30 30 01 55 2D 41 43 00 00 00 00 00 04
[12:30:03][W][haier.protocol:013]: Unsupported message received: type 62 data: 45 2B 2B 32 2E 31 38 00 31 39 30 38 31 39 30 30 F1 00 00 31 37 30 35 32 36 30 30 01 55 2D 41 43 00 00 00 00 00 04
[12:30:03][W][haier.protocol:013]: Message handler error, msg=62, err=1
I've already checked all lines from USB connector to ESP directly - they are OK. Also I've tried using both the UART interfaces - no luck.
What else should I check?
Update I've found this post saying that logic level converter could help. I will comment more in few days when the ordered item arrives.
@evgenyvolferts SmartAir protocol just doesn't get an answer to the first request, but the funny thing is that your AC is answering the hOn protocol init message. The answer arrives late which is why it is considered not as an answer but as a new message and this message is not supported. I saw that the original smartAir2 USB dongle has a little bit different startup sequence in comparison to what all smartAir2 integrations use (including mine). It can of course can be levels but actually, it shouldn't. For most people, it works without any conversion. So you try logic level converter and meanwhile, I will try to implement a different smartAir2 initialization sequence, anyway, I had it in my backlog. I will let you know when I will have something to test (it could take a while)
First of all thanks a lot for your quick answer.
I've remembered I have ESP32-CAM board, found and flashed it, but no luck again. AC behaviour is absolutely the same :( Seems like my only hope is the new init sequence (or levels converter).
@evgenyvolferts Checked today your AC's answer and it hits me that it looks exactly like it should for hOn AC not for smartAir2. It says AC support protocol version 2.18 and CRC (which is not supported by smartAir2 ACs). So are you sure your AC is smartAir2? So my recommendations:
answer_timeout: "300ms"
, It should look like this:climate:
- platform: haier
...
answer_timeout: "300ms"
....
If this doesn't help try to increase timeout up to 1000ms should be safe. The default answer timeout is 150 ms (which is already 3x longer than in the protocol description)
@paveldn Official Haier website in my country says the model AS25NHPHRA uses Haier Smart Air2 application - this is why I used smartAir2 mode first. I've tried the experimental branch with hOn mode and it finally worked. 300 ms timeout fixed my issue. That's great! Thanks a lot.
@evgenyvolferts you are welcome. Glad I could help!
Hi @Lastik-Lastikov , Yes, you are right. For smarthair2 WAITING_FIRST_STATUS_ANSWER means that there is no answer to the first request so actually nobody is answering from the AC side. It can be any hardware or configuration problems: wrong pins for UART, problems with wires, wrong protocol etc. Beeping for standard integration can be a signal that you have a problem with noise (interference).
I still have not been able to get answers from AC. What was done:
So far I see only 2 problems: 1) RX line failure on ESP 2) some differences in the protocol on my model
Here is a photo and config:
device_name: Haier AC
device_id: haier_climate
uart_id: ac_port
send_wifi: "true"
esphome:
name: haier
name_add_mac_suffix: true
esp8266:
board: d1_mini
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
use_address: 10.0.3.39
uart:
- id: ${uart_id}
baud_rate: 9600
# You can also use pins 15 (TX) and 13 (RX)
tx_pin: GPIO3
rx_pin: GPIO1
logger:
level: DEBUG
baud_rate: 0
web_server:
#<<: !include .haier-hon-base.yaml
<<: !include .haier-smartair2-base.yaml
upd: i try to use GPIO13 and GPIO 15 and its work! so its hardware problem with my esp
Hello! can't connect AS12NS6ERA-B judging by the documentation, this is the smartair protocol, but in the logs it gives out this and is not controlled in any way:: [W][haier.climate:165]: Answer timeout for command 01, phase WAITING_FIRST_STATUS_ANSWER