Another screenshot where I've scaled up the blue probe:
Your MRCOOL unit uses Midea's single-wire communication bus on the "S" terminal, which is different from the two-wire S1/S2 communication bus that this project monitors.
Because of that, a Waveshare RS485 adapter won't be able to communicate with your system. The communication method used by your unit is fundamentally different from what this project was built for, so the hardware and software aren't compatible.
I think part of the confusion may be my fault. Earlier in the project I referred to the S1/S2 bus as "SComms," but that's just a name I came up with and isn't an official term. Ive been trying to change all SComms references since learning about your "S" wire communication.
edit: I've been unable to edit the title of this thread but I flagged my first post and asked if maybe a moderator can change it.
I see. Completely spaced that the wire I probed with the blue probe is the neutral.
ty
Finally got XYE EEV, t2, and t2a added to Home Assistant. Its not perfect but its added. Pics of what I'm decoding. All images should line up with time. 4:30 starts a cycle and stayed in low load with 2 oil return spikes, 6:00 the Room Temp jumped so the system went into steps looking for best high load position. Then around 7:30 unit turned off after Room Temp went below Target Setpoint.
First 3 are XYE sensors. I have T2 with S1S2 but I figured since XYE has T2 and T2B ill add both for validation. The rest are S1S2 sensors. I do have a hand full of other sensors Ive excluded.
Outdoor EXV and Indoor EEV
The temps. I really need to buy some temp probes to fix some decoding.
Yellow line is the actual thermostat outdoor temp reading which is rounded to get to .5°. Blue is the S1S2 single byte outdoor temp not rounded. Green is the outdoor temp byte with a second 4 step 1/4° modifier. They like there outdoor temp precision.
This gets confusing especially with those steps. All 3 are from byte 17 on 3 different frames. The byte that I believe doesn't belong in the payload.
Then there's these. Blue, brown and red are raw numbers. Green and yellow are decoded to go negative when the bytes rolls back to 255 down.
I'm now wondering whats in the HAHB line vs the XYE...
Where are you getting EEV from the XYE? I have been following your thread and replicated your setup but EEV position has always been reading zero for me. Senville 24k BTU r410a.
@Machinist
I consider in my setup that the EEV is in the indoor unit. Im getting the step position with XYE frame C0 or C3, specifically the 2 bytes before the CRC.
Ive seen the byte position labeled differently so go to https://codeberg.org/xye/xye and within the "Answer/Status Report to Master:" section, byte column 0x1B (low) and 0x1C (high).
Just a note. I also have a EXV on the outdoor Heat pump. I have them labeled this way because this is what my manuals consider them. If you are looking for the outdoor EXV its in a different location.
Hi, does this work with A-Coil controller interface board: 17122000072181 that comes with heatpump pair of MAAHE-H36B-BA and MO1SE-H36B-2A?
This indoor / outdoor pair is supposed to regulate the refrigerant temperature by talking to each other using S1/S2 and will drop or raise the temp of the refrigerants based on static pressure and temperature of the coil to stop it from freezing. I want to see those data and more.
I have a Amica NodeMCU board and MAX485 TTL to RS-485. Should I connected this two wires from the TTL to RS485 converter to S1 and S2? S1 and S2 already have wires from outdoor unit and thermostat to them I think. I have not looked carefully yet but maybe there is a bypass for this sniffer?
Is your project a script for ESP HomeBuilder?
Outdoor unit:
Indoor unit controller interface board with box closed:
Indoor unit controller interface board with box opened:
Thanks.
Ill start with, I have no clue if your S1S2 is the same as mine. I can say that in the second image it looks like you have a 5V S1S2 bus. I would never trust that. Please get this tested before doing anything. So many of these systems use high voltages between the IDU and ODU.
If by chance you have a 5V S1S2 bus then heres the ESP32 code I’m using is here:
The ESP32 doesn’t decode anything—it simply listens to the bus and forwards the raw data over the network. A separate computer runs the Python application, which logs, decodes, and can publish the data to Home Assistant over MQTT.
I wouldn’t start by trying to integrate it into Home Assistant. First, I’d just confirm that you can safely capture raw data from the bus. Once you know what the bus looks like, you’ll have a much better idea whether the Python application can decode it or if it needs additional reverse engineering.
If you can get a capture of the data feed post it. I cant find anything online related to this protocol so hopefully S1S2 is the same for everyone.
Thanks.
1- So I understood that you are saying the pictures I posted seem to be like your hardware in terms of being 5VDC and S1/S2 and your program may work for this but I have to put a voltmeter somewhere (where?) to test it is for sure 5VDC and then connect the TTL-RS4785 to it which in turn connects to ESP32. Did I get this right?
2- Why not put the whole python program or its equivalent ESPHome code onto the esp32 board? That way, there is no need for another computer and it can directly mqtt to HaOS its refined data.
3- I am interested to see if the Heatpump is running in intermediate mode or full capacity mode and also if it regulates the refrigerant (by ramping up or down the outside condenser) when it senses different static pressure or coil temp going down to freezing point. This particular model apparently has automatic regulation for that sort of thing which is very neat and useful as I use an older single stage furnace with a PSC motor which may ramp up or down etc.
Thanks again.
Im not an electrician but I connect my voltmeter directly to both the S1 and S2 lines. The voltmeter fluctuates but always stays below 5V.
This could be fully put on a ESP32 board and I’m sure it wouldn’t be to hard. Maybe there’s an AI that could just do it. Ill look into doing this and merging my current code with whats on Github.
I finally figured out why the Senville app reports Idle as “System Power” = EXV High + 1 .
After correlating captures from both buses, it appears that the S1/S2 0001_50 through 0001_53 frames are being translated almost directly onto the HAHB bus as 20 04 XX frames (20 04 01 , 02 , 03 , 04 , 05 , 06 , 07 , 08 , and 10 ).
These frames are transmitted immediately after the XYE traffic, which initially made them look like invalid or unrelated data.
My current theory is that the outdoor unit’s EXV information is forwarded through the thermostat onto the HAHB bus, and somewhere along that path the Senville app is interpreting one of those values as “System Power.” I don’t have proof of that last part yet, but the timing and correlations are strong enough that I think it’s a reasonable hypothesis. Hopefully someone can prove me wrong—or confirm it.
Although this thread is about the S1/S2 bus, the HAHB interface appears to expose much of the same information, plus quite a bit more.
AA D0 Frame
One frame that had already been identified by @Pentops is the AA D0 frame. He was right—it turns out to be fairly boring.
It contains:
- CRC-8/MAXIM over bytes
[0..28](byte 29) - Midea additive checksum
255 - sum(data) % 256 + 1(byte 30)
Example:
AA D0 20 01 00 88 80 D2 00 00 00 00 00 00 00 06 18 00 34 21 00 00 00 00 00 00 00 00 00 40 82
From what I’ve decoded so far, this frame contains the controller clock and the thermostat setpoint with 0.5°C precision.
AA AC Frames
The AA AC frame appears in two different formats.
One is roughly the same length as the familiar XYE frames.
The second is approximately 46 bytes long. I don’t yet know its purpose, but it may be carrying gateway information, an identifier, or some other static configuration.
Unlike the standard XYE traffic, this frame contains three separate checksum/CRC calculations .
AA AC 00 00 00 00 A5 5E XX XX XX XX XX 30 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 86 38 DD 55
AA AC ... 86 38 CRC-8/MAXIM
AC ... 86 38 DD Midea XYE additive checksum
...30...86 CRC-8/MAXIM
S1/S2 ↔ HAHB Correlation
Most of the HAHB 20 04 XX frames appear to map almost directly from the outdoor S1/S2 telemetry.
Current correlations:
0001_50 → 20 04 04
0001_51 → 20 04 06 and 20 04 07
0001_52 → 20 04 07
0001_53 → 20 04 08
There are also several values that correlate between the primary S1/S2 telemetry frames (0100_20 and 0001_20 ) and the HAHB 20 04 frames, including compressor frequency (Hz) and other operating data. I haven’t finished mapping those relationships yet.
At this point I’m thinking the HAHB bus probably deserves its own thread. There’s far more going on than I originally expected, and it seems to be carrying S1S2, XYE, and possibly USB UART.
Do you know what types of units have an HAHB bus? The second to the last screenshot above shows a “Non Polarity Wired Controller” being connected to HA/HB.
The wiring diagram for Midea IDUs also mentions a “Non Polarity Programmable Wired Controller”: https://s3.eu-west-1.amazonaws.com/static.fw1.biz/Templates/32505/myimages/d5fsha19-01pd_1747133380839.pdf
See: Fig. 6 – Wiring Diagram Sizes 6K - 36K (115V and 208/230V)
Is there a chance that CN44 == HA/HB?
If CN44 is only 2 16-20V wires and only connecting the IDU to a wall controller then possibly.
I’m unsure what all types of units use the HAHB bus but I have a 3ton central air 36000 BTU Central Air Conditioner Heat Pump System - SENDC-36HF - Senville.com
@MidATRIX have you been able to confirm – possibly through correlation or EEV from byte 28 and 29 of the XYE – that the EEV percentage from Byte 17 of 0001_50 is truly the open percentage?
Unfortunately on my 24K BTU Senville central ducted no telemetry is being broadcasted on byte 28 and 29, but I do get byte 17 on S1S2, so I cannot confirm this myself.
I’ve been trying to track down an issue where My coil B Temperature plummets below Coil A, and then it causes my evaporator to ice up. It doesn’t always occur, and my hypothesis that there’s some firmware bug that causes the EEV not to open up enough when the compressor ramps up under certain conditions. I use home assistant to monitor this and an automation turns off the compressor when it detects this happening, avoiding ice.
I think I can see this issue happening via the telemetry but I was wondering if you could confirm that the EEV percentage is in fact a percentage. At low load, I noticed that the EEV percentage doesn’t just hover at a low level, which gave me some doubt.
Unfortunately Ive found that 0001_50 byte 17 on my S1S2 is most likely a play on frequency. If your S1S2 bus is like mine then take 0001_50 byte 16 + 0001_50 byte 17 / 100. Its another form of Hz at an average. This seems to align on this bus and also the Testport buses on the outdoor unit. If you do not see any movement on your XYE for 0xC0 [28] and [29] then I’m unsure how to help without contacting a HVAC company.
Bottom chart blue is 0001_50 [17]. This byte add details to 0001_50[16].
Top chart is both bytes added and divided by 100.
Have you had any non moving bytes change specifically in the 20 frames? Do you have any codes on your outdoor unit diagnostics screen? Just curious because I haven’t seen any codes thrown on my unit.
@MidATRIX
Hey I was looking to do this on my unit it’s exactly the same as yours. I was curious do you have a picture or a wiring diagram how you did the passive tap of the s1 and s2 lines? I have already verified my s1 and s2 line are 5 volt like yours.
My original connection was with a Waveshare to eth that connected directly to the S1S2 bus. I have since change to using a ESP32 and rs485 to TTL board. What kind of setup are you planning to use?
If you are planning to use a ESP32 and rs485 to TTL then do this. You may have to switch A and B around on the rs485 side and depending on your devices you may need to enable auto-switching. This is sniffing only so no need for the TX2 line.
Let me know if you have the same frames I have or maybe post some of that “nc” command I have in the GIT recommendations. I’m assuming this bus has multiple different protocols.
All good I have it set up as you previous had it works great. The waveshare connected to the S1/S2 bus. Out of curiosity why did you change to the esp32 to rs485 to ttl? I also do get all the same frames as you too.
That sounds great! I switch to ESP32 because its more familiar and similar to other project. You can also technically use it without a 3rd device / computer. The Waveshare to me was the easy way to get this bus figured out and other reasons. Glad to hear its working for you
Ill update the list of sensors I’ve decoded because some will be surprising. EXV is, well absolutely unexpected but what’s labeled EXV I think is Total Power Watts.
Ill be glad to compare notes or answer any questions because there’s still way more to this bus that can be figured out.
I updated the list of sensors on the repo. I also added the matching Home Assistant discovery. Let me know if something doesn’t work since I’m now 100% using a ESP32.
I’m going to update the repo soon that will be for the ESP32. This allows the ESP32 to send data straight to Home Assistant and it will also have MQTT feed that allows any device on the network to subscribe to. This will be for whatever you want the feed for. Im capturing and pushing all data frames raw sensor data to InfluxDB and will also include that in the repo.