haier-esphome icon indicating copy to clipboard operation
haier-esphome copied to clipboard

Haier smartAir2 not responding after power outage

Open ssrsmart opened this issue 9 months ago • 3 comments

I Have 6 GE split units " rebranded haier ac smartAir2", controlled by NodeMCU and esphome haier integration, the ac units responding so fast and reliable until a power outage accrue, after the power back some ac units not responding and the problem accur with different ac randomly, the only way to solve the issue is by turning off/on the power to the ac.

Screenshot_2024-05-03-23-21-26-97_c3a231c25ed346e59462e84656a70e50

ssrsmart avatar May 03 '24 20:05 ssrsmart

Hi @ssrsmart , I need logs. Can you please get logs from the devices when they can't communicate with AC?

paveldn avatar May 04 '24 13:05 paveldn

Hi @ssrsmart , I need logs. Can you please get logs from the devices when they can't communicate with AC?

Hi, I can't get logs becouse devices run haier integration remains in offline in esphome, the devices connected to the network and responding from home assistance

Uploading Screen_Recording_20240504_192206_Home Assistant.mp4…

ssrsmart avatar May 04 '24 16:05 ssrsmart

OK. Got it. I need more details. What kind of board are you using? What version of my ESPHome and my Haier component (from ESPHome, from my repo master branch, dev branch, experimental branch)? I saw this kind of behavior in the past. The problem was that when there was no communication with AC ESP was trying to establish a connection by sending requests at a high rate (every couple of seconds) and this was somehow interfering with the WiFi component. But I think I fixed it months ago. So my hypothesis there 2 problems:

  1. For some reason after the outage your AC is not answering ESP (probably because ESP is aggressively trying to communicate before AC is initialized)
  2. This is causing problems with WiFi communication.

That is why I need all the details to try to reproduce the problem.

paveldn avatar May 04 '24 18:05 paveldn

OK. Got it. I need more details. What kind of board are you using? What version of my ESPHome and my Haier component (from ESPHome, from my repo master branch, dev branch, experimental branch)? I saw this kind of behavior in the past. The problem was that when there was no communication with AC ESP was trying to establish a connection by sending requests at a high rate (every couple of seconds) and this was somehow interfering with the WiFi component. But I think I fixed it months ago. So my hypothesis there 2 problems:

  1. For some reason after the outage your AC is not answering ESP (probably because ESP is aggressively trying to communicate before AC is initialized)
  2. This is causing problems with WiFi communication.

That is why I need all the details to try to reproduce the problem.

I am so sorry for my late, I didn't notice your reply,
I got the logs from the device by connecting to the device ip directly from the browser

This is the logs during the fault

Time level Tag Message 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:03 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:03 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:04 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:05 [I] [haier.climate:095] Answer timeout for command 01, phase SENDING_FIRST_STATUS_REQUEST 01:08:10 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:12 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:14 [D] [haier.protocol:019] Sending frame: type 61, data: 00 07 01:08:14 [I] [haier.climate:095] Answer timeout for command 61, phase SENDING_INIT_1 01:08:15 [D] [haier.protocol:019] Sending frame: type 01, data: 4D 01 01:08:17 [D] [haier.protocol:019]

My esp board is nodemcu ch340 Esphome version : 2023:12:19

Screenshot_20240703_011102_Chrome

ssrsmart avatar Jul 02 '24 22:07 ssrsmart

Hi @ssrsmart It looks like your climate is not ready to start communication after the power outage and because of this, it gets into the wrong state when ESP starts talking and shuts down all communication at all. You can try to do this:

esphome:
   ...
  on_boot:
    priority: 200
    then:
      - lambda: |-        
          delay(15000);

This code will block your complete board for 15 seconds after boot which presumably will give your AC enough time to wake up. This is a dirty trick but it will allow us to check if I am right about the problem's root cause. If it helps I will implement different solution for your situation.

paveldn avatar Jul 08 '24 05:07 paveldn

I suppose issue can be closed

paveldn avatar Jul 29 '24 10:07 paveldn