Control through USB

[Orneeman]

Hi Did you succeed to control the ac via the usb uart ?

[Links2004]

yes, the code can control it and read out the current status and some sensors.

here you find a simple code that enables the AC on bootup: https://github.com/Links2004/arduinoMideaAC/blob/master/examples/esp8266/enableAC/enableAC.ino#L39 https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.h#L71

I combined this lib with my websocket lib and connected the AC to the home automation I have to control it.

[Orneeman]

Cool thanks, What is the first transaction that I should send that the ac will think that a dongle is connected ?

On Sun, 5 Jul 2020 at 23:36 Markus notifications@github.com wrote:

yes, the code can control it and read out the current status and some sensors.

here you find a simple code that enables the AC on bootup:

https://github.com/Links2004/arduinoMideaAC/blob/master/examples/esp8266/enableAC/enableAC.ino#L39 https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.h#L71

I combined this lib with my websocket lib and connected the AC to the home automation I have to control it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Links2004/arduinoMideaAC/issues/1#issuecomment-653936003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJCIJ5GJ3OVQB3J4PBNYZH3R2DP4ZANCNFSM4ORAM3TA .

[Orneeman]

by the way can tell what is the parity settings oh the uart?

[Links2004]

https://github.com/Links2004/arduinoMideaAC/blob/master/examples/esp8266/enableAC/enableAC.ino#L33

if you want to control the WiFi LED indicator you can use https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.h#L68

[Orneeman]

thanks :) what about the uart setting I think I am reading gibberish

[Links2004]

the Arduino will use 9600 8N1 to communicate with the AC, and 115200 8N1 to the PC (in the examples) debug output is on Serial1 and AC is on Serial. the AC protocol is binary so no easy way to read it in ASCII, you most likely want to connect to the debug output of the Arduino ;)

[Orneeman]

Thanks :) it looks that in my case the serial data kind of dncrypted , for example turn ON command:

first time: AA23AC8F000000000303418100FF0000000200000000000000000000000000000057BEC4AA23AC8F 000000000302404346505000003000000000000000000000000000000014DF11AA1EACB200000000 030D0101020B00A8C0FF000100000000000000000000FDAA1EACB200000000030D0101030B00A8C0 FF000100000000000000000000FCAA23AC8F000000000303418100FF000000020000000000000000 0000000000000058FF82

and the second time:

AA23AC8F000000000303418100FF00000002000000000000000000000000000000636115AA23AC8F 000000000302404346505000003000000000000000000000000000000016DF0FAA1EACB200000000 030D0101040B00A8C0FF000100000000000000000000FBAA1EACB200000000030D0101030B00A8C0 FF000100000000000000000000FCAA1EACB200000000030D0101040B00A8C0FF0001000000000000 00000000FBAA23AC8F000000000303418100FF0000000200000000000000000000000000000064E2 93

I marked the common parts:

[Links2004]

I am not seeing the problem?

the

0302404346505000003000000000000...

is the beginning the on https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.cpp#L101

ACB2000000000....

is the status update for Wifi / APP connection https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.cpp#L29

I not see any encryption in your data, I only see the midra Serial protocol in HEX. not sure what you trying to do, but you may need to describe your setup an goal more. your serial messages are clearly direct from the AC "USB" port.

the basic massage encoding is:

header ( 1 byte ) - 0xAA message length x ( 1 byte ) including the header and length byte / payload / destination target ( 1 byte ) - 0xAC payload ( x bytes )
checksum (1 byte ) see https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.cpp#L194

[Orneeman]

Hi maybe I am too paranoid lol .. according to your answer I have few question(I captured this data from the tx pin of the usb dongle while I turned on the ac throw the app)

1. How did find the basic encoding struct?
2. why the "on" messages are not identical ? 3.in our example the msg len is 23 byte (46 hex letters) I see that the msg is much longer (what I am missing ?) 4.why there is app status update on the tx line of the dongle?
3. I sent this data to the AC and it did'n't work sorry for my English :)

[Links2004]

1. reverse engineering and experiences (I am a full time senior software engineer)
2. the on messages include many informations and based what is selected on the APP the messages are different, most likely there is also a time encoded there but I never reverse engineered that part since its not needed for controlling the AC. And I use my home automation system for time and event bases control anyway no need for the AC internal timer.
3. you serial messages did not show the init / reset that is at the beginning, that is most likely the problem.
4. you not only seeing one messages you are seeing many messages you need to decode the "Transport Layer" first to see where a message starts and where its ending (a simple an mostly working way is to check for 0xAA) https://github.com/Links2004/arduinoMideaAC/blob/master/src/mideaAC.cpp#L17-L20
5. the dongle tells the AC that its connected to WiFi to enable the status LED wifi symbol (if the AC is on)

with a ATmega 2560 you can build a sniffer. when using the AC_DEBUG_RAW define you get the message basics decoded.

[Orneeman]

Got it thanks :) how did you find the checksum algorithm is it a common one? here : https://github.com/Links2004/arduinoMideaAC/blob/c7d7e0a9c4704df5c7dae271f25ffae04ab4afd6/src/mideaAC.cpp#L99 this method send conf to the AC or to the APP, because if its to the AC why the target is "AC" and not "FF" in my case when I want to send a cmd to the AC I should use FF like this: Turn-On AC at 21C Cold: 0xAA 0x23 0xFF 0xDC 0x00 0x00 0x16 0x00 0x00 0x02 0x40 0x43 0x45 0x50 0x50 0x00 0x00 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x8A 0xC5

[Links2004]

the checksum basically is a sum of all bytes inverted and + 1 at least the sum part is very common. when you have recorded many massages you will star to see patterns for example the different between to message is only the first bit in on byte and you checksum changes only in the last bit too you get the first hint for a sum of a kinde, if the same happens for the second bit a well its a very high changes, so its basically a analytic mind set mixed with experiences. but in the end it comes down to a bit try and error the more messages you have recorded the better since you can run your checksum implementation against it and in the end you code needs to generate the same checksum then you have in the recorded messages ;)

its possible that there is more then version of the midra protocol all my 3 split ACs where running fine with the code I wrote.

the payload data seams to be the same encoding as what I have found but in you case its send to 0xFF

you can try to send it as is, and if its not working you can changing the code to send to 0xFF https://github.com/Links2004/arduinoMideaAC/blob/c7d7e0a9c4704df5c7dae271f25ffae04ab4afd6/src/mideaAC.cpp#L99-L117

// 0     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15    16    17    18    19    20    21    22    23    24    25    26
0x03, 0x02, 0x40, 0x42, 0x00, 0x00, 0x7F, 0x7F, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1E, 0x00, 0x00, 0x00, 0x04, 0xC0

0x00, 0x02, 0x40, 0x43, 0x45, 0x50, 0x50, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x8A

[Orneeman]

Thank you very much , you helped me and I learned a lot !! 💯

btw, do you have experience with the chip that on the dongle (RTL8710BN) , I want try to read the keys from his memory via the second uart channels (log uart)

[Links2004]

the log UART on my stick is TX only I never have found the for it RX on the stick. but you can dump the SPI flash memory besides the chip via a SPI flash programmer, have done this myself but you get a big binary blob.

I never really looked in to the dump since I deside for my use case its easier and cheaper to replace the stick with a ESP8266 with the Serial protocol implemented. I only have one midra stick and 3 ACs, but all of them have a ESP8266 connected to the "USB" uart.

The encrypted key is only needed when you what to emulate the Midra cloud since the Stick to cloud and stick to APP connection is encrypted. for that case its may easier to decompile and debug the APP to get the key ;) since the APP is a smaller code / binary base then the blob dumped from the SPI flash chip.

[Orneeman]

in my case the app is just a web view so nothing interesting there, and I found that there 2 clouds one for the APP server<-> phone communication and one for AC<->cloud (mqtt server) so I want to read the key or the certificate of the MQTT server

[Orneeman]

I found that it doesn't matter if I put FF or AC when I send cmd to the AC both ways work 👍