Light doesn’t change here. It stays on. When I turn it off on the remote nothing happens within HA.
Not much luck on the older protocol documentation, but at least I got statement from the Haier person, that they will not provide it to me, so that is still heaps better then how these things usually go.
I will need to order stuff for uart sniffing again as it got lost, should have just bought on ali 
I would probably postpone my development with smartAir2 protocol for now 
There is no way for me to experiment. And fixing it in this mode consumes too much time. Too bad, there is no documentation available. When there will be results of sniffing protocol from @evlo with reliable values I will give it another try.
No luck
But the documents for the new protocol are amazing. You saved me weeks, maybe months of reverscoding. There are still some areas unclear, also not always a correct translation from Google Translate. But it is readable and explains a lot of questions I had. I am already rewriting the communication part based on this knowledge.
You can let me know if you need help translating something and i can ask Mandaring native relatives, but maybe it will be even worse translation for technical stuff like this then deepl one
1 Like
Thanks, I will. But for now, Google Translation is OK.
I tried to cobble together sniffer both the haier MK-QTWIFI-08 and wemos d1 connected to the same usb power source from AC and the wemos did wakeUp bt the MK-QTWIFI-08 did not, i tried without my sniffer and was able to pair with it (what an ordeal)
Without wemos it does light up, so maybe it just needs external power supply.
…
at least it is not sketchy 
Maybe it can be useful, but honestly it seems to me that maybe we will be able to fix the light setting not working.
Maybe i did capture only part of the traffic. ie. one direction because of my jankyass soldering job, …
This is what I get when I do not send any commands to AC but wifi module is connected
I would have hoped for some traffic in other direction, as i set up dummy receiver to true.
Maybe I should connect TX from the haier wifi thing to the RX of the wemos I use to capture traffic. Then again there is even less options in smartair2 app then there is with the remote.
Please let me know if i could try something more as to me it seems that i did not intercept the commands when using app to control the ac, altrought it probably does not really matter.
Even what you have done now is better then smartAir2 in stability and in functions it is pretty much the same, maybe “health” is missing, but other then that smartAir2 app can’t do much.
1 Like
this is for the light, i do not know how to turn off the beeper 
AC beeps when using smartAir2 APP to set anything
complete log of my attempts is in the excel file in previous post
This
FF:FF:08:00:00:00:00:00:00:05:0D:FF:FF:08:00:00:00:00:00:00:05:0D:FF:FF:22:00:00:00:00:00:01:02:6D:01:00:19:00:2A:00:7F:00:00:00:00:00:01:00:02:00:00:00:11:00:00:00:00:00:0D:76 is the reply AC sends on successful connection of the wifi module - it is only very different “packet” than all the others.
I still think I should have switched TX and RX lines on the wmos, who know what the wifi module sends.
When switching rx and tx lines like this (i ended up making it nicer)
I do get this kind of traffic
… I get it now, I need to have both RX from AC “usb” stick linked to UART RX port and TX from AC “usb” stick also linked to another UART RX - Finally used my brain 
. Anyways, not really useful as the app can’t do much.
Maybe all the advanced functions on all these older protocol ACs need to be done by IR and beeper will just always beep.
If I would go crazy with the implementation I would capture the uart communication of the IR interface and maybe even the beeper or just add relay for the beeper, but for the time being i don’t feel like hacking the AC so much.
2 Likes
Hi, evlo!
First of all great job Thanks for the logs, it will take me some time to analyze them. It looks like you are right, the functionality of the smartAir2 app really poor so it will be useless to sniff protocol deeper. If there is no such function in the app you wouldn’t be able to sniff it.
You saw only part of the traffic because AC and the USB module use different wires to talk. So to hear both of them you will need two ports. You will need to connect the white wire RX of one port and the green wire to the RX of another port to listen to both of them. But also you will need a common ground (1 wire communication will not work).
I think esp8266 has only one serial so you will need two Wmos D1 mini or one ESP32-based board (ESP32 has three serial ports). Probably it is possible to use the software serial port on Wemos D1 but I never tried it before.
P.S. Oh missed it you already figured it out yourself 
1 Like
wemos D1 mini has second uart RX on D07 it is not hardware uart, but they specify to use D08 and D07 pins for second uart, so I did that, also in the end i managed to make all the sniffing work without the external power source and without any noise introduced. Turns out having good soldering iron really reflects in solder quality
1 Like
@paveldn i have read trough the discussion but could not find the answer.
Is it correct that i can use your project on paveldn/ESP32-S0WD-Haier (github.com) -for instance- on a wemos D1 mini with esphome and use it in a hOn AC ? Or do i need to reflash the existing ESP-for-Haier module (which i prefer not to)
Tnx for all your work!
You are welcome!
Yes, but YAML configuration file included will work only for the ESP Haier ESP32 module. For Wemos D1 you should make a new one. It should be quite easy. Let me know if you need help with this
In the latest dev version, thanks to protocol document I implemented proper parsing of hardware info provided by AC during initialization phase, it should look like this
[16:22:48][C][haier.climate:247]: Haier hOn Climate 'test ac'
[16:22:48][C][haier.climate:251]: Device protocol version: E++2.18
[16:22:48][C][haier.climate:253]: Device software version: 17062600
[16:22:48][C][haier.climate:255]: Device hardware version: 17052600
[16:22:48][C][haier.climate:257]: Device name: U-AC
[16:22:48][C][haier.climate:261]: Device features: crc
These log lines (among others) should be printed every time you start remote logs. It looks like my AC doesn’t support most of the functionality in the protocol. Also, my AC’s firmware is from 2017 and the version is 2.18, and the latest protocol document we have is 2.19. There is a good chance that there are even newer versions of protocols. People who are using the latest dev can you check yours? It is interesting if there is somebody who has a different protocol version. Also if there is anybody who has something more than CRC in Device features
nodemcu (clone) with ESP8266 does not come up, it does build and upload firmware, device connects to wifi, but nothing in log. Even after reset. I will try with ESP32 later, hopefully today. And after that maybe run uart log to see what it does not like.
This is why I actually like esp riscV soc, in my experience it either works and it just works or it just does not work at all.
I think
framework:
type: esp-idf
sdkconfig_options:
CONFIG_FREERTOS_UNICORE: y
Might be the cause
Mine is arduino as I think esp-idf does not have webui. I don’t think esp-idf works with 8266 even
Strange 
I was sure it should work. I tried with my Wemos D1 mini (without connection to AC) and the code is running OK. Can you try it with this file: haier_esp8266.yaml - Google Drive ? Just check if the pins are all correct.
When NOT connected to the AC it works OK.
OK. Will try to connect my Wemos to AC. Thanks.
But in general, I would not recommend using ESP8266. There are no mutexes in the arduino framework for ESP8266 and I just skip all locking for 8266. Code is written in a way that it shouldn’t be a problem but I still fill uncomfortable without them.
I agree, it is just what I have connected at the moment and I’m too lazy to clean up workshop and solder usb to esp32.
IMO no point in supporting both, especially if the the price of each is marginal.
update: i soldered usb onto the esp32 board, but then found out i did not have usb in the ac so now i need to create other side of the usb cable
update2: both ESP32 and ESP32s3 working ok, even when using arduino framework
super weird, if I add
esp32_ble_tracker:
scan_parameters:
active: true
bluetooth_proxy:
active: true
to the esphome config, connection starts dropping
but looks more like esphome issue
Hello @paveldn i got the yaml and files installed on the esp8266 and all seems fine. But when i connect the esp to the AC it crashes. I did try the pin 1/3 and 15/13 gpio both gave same effect. See the log below:
[22:53:23][D][haier.climate:625]: Message sent: FF FF 0A 00 00 00 00 00 00 61 00 07 72
[22:53:28][D][haier.climate:625]: Message sent: FF FF 0A 00 00 00 00 00 00 61 00 07 72
[22:53:33][D][haier.climate:625]: Message sent: FF FF 0A 00 00 00 00 00 00 61 00 07 72
[22:53:33][D][haier.climate:577]: Received Init1 command answer message during phase 1, size: 49, content: FF FF 2E 40 00 00 00 00 00 62 45 2B 2B 32 2E 31 38 00 31 37 30 36 32 36 30 30 F1 00 00 31 37 30 35 32 36 30 30 01 55 2D 41 43 00 00 00 00 00 04 5B 8A AB
[22:53:33][D][haier.climate:625]: Message sent: FF FF 08 40 00 00 00 00 00 70 B8 86 41
[22:53:33][D][haier.climate:577]: Received Init2 command answer message during phase 3, size: 43, content: FF FF 28 40 00 00 00 00 00 71 20 08 61 08 00 82 03 24 02 12 00 11 80 09 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 0A 2F 79
[22:53:33][D][haier.climate:625]: Message sent: FF FF 0A 40 00 00 00 00 00 01 4D 01 99 B3 B4
INFO airco.local: Ping timed out!
INFO Disconnected from ESPHome API for airco.local
WARNING Disconnected from API
WARNING Can't connect to ESPHome API for airco.local: Timeout while connecting to ('192.168.1.64', 6053)
INFO Trying to reconnect to airco.local in the background
INFO Successfully connected to airco.local
Have no idea, never tried BT with esphome. Did you consider overheating? Or you are right and it can be esphome issue.
Yes, after your message and @evlo comment that it is not working with his ESP8266 I tried it myself. So it crashes because of some alignment issues. I will try to fix it but it will take some time. I would recommend you try using ESP32. Not necessarily Haier ESP32 just any esp32.