okay i wasn’t losing my mind. this has been fixed in the latest esphome patch:
Edit: I am still seeing the behavior I reported above. I’m not really sure what to do at this point. The system randomly thinks the temp is 62 now and the only solution I’ve come up with is to cycle the esphome when this happens which is incredibly annoying.
Would you mind posting a full, working 0xC4 query message? I tried some of the simple ones from earlier posts, and my unit (Pioneer branded slim duct) did not like them. I tried:
[0xaa, 0xc4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3b, 0x01, 0x55]
and
[0xaa, 0xc4, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3b, 0x81, 0x55]
Hello,
just have gotten to decode the HAHB bus - which seems to be just XYE with a higher bitrate and a serial wire line driver that couples the signal with capacitors into the HAHB wires 
From my last capture, here is a packet:
AA C4 00 00 00 00 A5 5A 00 00 00 00 00 3B 02 55
AA C4 00 00 00 00 05 00 02 30 0E 00 00 00 00 00 84 80 57 BC D6 32 98 00 00 00 00 00 00 00 40 55
HVAC-shark-dumps/Midea-XtremeSaveBlue-display/Session 3 at master · fabcoded/HVAC-shark-dumps
With my wireshark plugin i try to decode a rough baseline of known packets, but i still have no explanation on the C4. My controller is a KJR-120M/BGEF
I can next time its plugged in. In the mean time just try changing the code to the above.
If you get the same issue as me sending 0 in the fields of mode and fan results in the unit obeying them (equivilent to a set). Other units ignore this but mine does not.
Been a little busy, sorry for the delay in response. Not really sure what the right behavior is honestly.
Yeah, if there was a wired controller it might beep. Not sure. Does nothing for me either.
Wow, I’ve never seen that one before. Maybe something to do with your module if it has auto CTS/RTS?
No, I have tried the one from Midea, and the ESP32 based board, the XYE protocol works better. Can’t do follow-me over the AC one without having the IR LED set up working…which I couldn’t get on either my wired controller or wifi adapter…
Fun times!
Interesting.
I see your follow-up. That’s fun.
More configuration switches is what this will result in hahaha, not just “use Fahrenheit”
I’ll refrain from updating ESPHome for now given the fun times going on.
As a recap, what does anyone need from me at this time? Still trying to keep on top of this, but I’ve got a lot of projects in the air at the moment.
-Matt
disregard the esphome upgrade issue; i was on an older version and i upgraded to 0.3.0 and the issues went away. classic user error, sorry for the confusion! @mdrobnak
Yeah. Different users have different needs. I fell onto this page when looking up for a way to retrieve defrost status from my wall unit. XYE was not possible on my unit as it required an additional expensive aftermarket board, and it seemed to involve a lot.
Then afterwards I discovered that the OEM USB dongle can provide a lot more than what is available on their own Midea app. That’s how I came to announce to other users like myself that XYE is not always needed to get additional data from a device.
Also, at some point I also thought “follow-me” mode was a necessity until I found out that I could extend the T1 sensor wire and move it outside of the unit, farther from the hot coil.
Something I’ve noticed is that my reported “follow-me” temperature isn’t correct in home assistant, but the actual temperature reached by the unit’s output is perfect.
When I’m using the unit for heating I see the temperature reported several degrees above the sensor that I set for follow-me. Maybe it’s showing the temperature of the internal sensor still, did I miss some config for this?
Ok, awesome.
Even with follow-me, ti’s 70% reported temperature, 30% internal temperature, or some blending, if I remember correctly…
Fair enough. I’ll definitely take a look at that repository you linked to at some point.
-Matt
If you have any ideas re C6 / follow me Id love them. I’m running out of ideas there.
I do intend to also try a different RS485 module in case its some kind of transmission format error. The extra character still weirds me out.
I suspect that configuration switches arent necessary, potentially other units will accept but ignore the format required for my unit. Needs someone to give the code patch a go to be sure though.
That’s great… even better than great.
I can’t get xye to give any data on 0xC4 and 0xC6. So was looking at the HAHB side of things. The voltage is 18v which is outside the band of standard rs485 circuits. I did try for a brief period to hookup the basic rs485 circuits and did see some data being interchanged, however started hearing clicking / buzzing sounds so removed it quickly.
So I’d be interested in what hardware you used to connect to the HA/HB ports and bit rate details.
Running a Senville 24k concealed duct / R454b which appears to be a midea V7 MTJ24HWFN10-M1 unit. There isn’t much in the way of connectors other than xye and HA/HB. There is a 5 pin cn19 that does show on the schematic.
John
Hi,
please never connect RS485 or XYE to HAHB! For my tests i just bypassed the entire high voltage circuit:
If somebody knows what you do, then you maybe just de-solder this RS485-Tranceiver chip and use the data input/output on a ttl-level (3.3 or 5v depending on the board) directly …
I am currently working on a circuit for my rasperry pi to directly inject packets on msmart-Dongle (uart) port and maybe on xye to have more directed dumps because many of the queries are known now.
(My goal is to get the last details out of the display-mainboard connection).
By the way, if someone has a logic analyzer and knows how to hook it up, i always am interested in dumps and will try to decode them/add decoders.
I’m terrified about the possibility of people soldering things to the wrong pins, solder balls, poor joints, etc. Stick to the connectors, work out the standard that is being used, both hardware and software, reverse engineer appropriately, and then replicate.
The photo isn’t clear enough to read the chip numbers. Check the chips surrounding the controller. Look up their specs. Are they RS485 standard converters? Something else? What value dropdown resistors are adjacent to the connectors? Optocouplers? Driver transistors? Buffer transceivers? RS485 or RS232? What does ENC3 select? Baud rate or channel number? Are the DIP switches for standard 120ohm RS485 terminating resistors?
Have you considered asking the vendor support area or checking service manuals and design documents? Circuit diagrams? Software data flows? Ladder logic diagrams? The information may be available for the asking, and will save you considerable grief and time, and any successful interface may open up the vendor to increased sales.
Hi, if midea would do so, these whole discussions here were obsolete. There is none! official information of any internal midea ports, so peolple modify their systems according to their own individual knowledge.
As an electronics engineer i know (most of the time) what i am doing - and this is why i decided to go this way. (Figured out the circuits, looked at the operation principle and then recorded data with a logic analyzer for getting more information on the bytestream - my work, my systems,my risk. I do not recommend this to anyone)
That’s was my thinking all along…. but my investigative side had to test it and end speculation that is prevalent in this forum on what HAHB is… so good on you for shutting this down.
I think there is definitely an opportunity for someone to reverse engineer the electronics on the tstat side and strip out the supply voltage. It’s a good approach/patent however I can’t see the benefit other that to get to 2 wires or to squash hackers, hobbyists, or people with nothing better to do. Whether it gets monetized or open sourced is their call. A patent may prevent some aspects of what’s next.
John
My guess from the protocol analysis is rather straight forward - re-build the circuit below and write an software-encoder/decoder (uart) as i did for my analyzer.
The required IC may be a MM1192
(see pictures below of the adapter that converts the R/T bidirectional pin UART of the AC display board to either HA/HB or XYE. This is how i found out that Bosch and Remko seem to brandlabel Midea)
Sketch from Patent:
(https://patentimages.storage.googleapis.com/8b/90/0e/3b615681d016d2/HDA0002826563330000011.png)
CN112556105B - 通信设备的控制方法、控制装置、通信系统和存储介质 - Google Patents
By the way i looked again onto my images - the HAHB data path is already present on the circuit board of the XYE adapter (these are population options but it seems fully populated … i have to measure this later …)
Comparted to the MFB X for HAHB
The XYE Data wires connect directly to an TTL-RS485 converter VP3082 IC:
I like your approach. Ive been working on a project sniffing the bus between the IDU and ODU. Maybe one day you can do the same and we can compare. I have outdoor temp at a temp precision of 0.165F that can update roughly every 200ms.
Let me know if you have your own project post so I can follow. This is mine.
Building a circuit that could level shift that would probably be required for anyone to safely do that.
I’ve wanted to take a look at the X1/X2 pins for example on my unit but I need to first figure out an appropriate level shifting circuit. For buses like this its important to take a look at the signal with a scope to see what the differential is during signalling and the common mode voltage.
If its <= 25v the THVD2450 from TI looks like it could potentially hande it.
