--- title: "The Mitsubishi heat pump telemetry hunt" description: "I scanned all 256 CN105 info codes and found nothing, then swept all nine heads and found energy and runtime counters on four of them." url: "https://michael.zazon.us/notes/the-mitsubishi-heat-pump-telemetry-hunt" published: "2026-10-07T12:00:00-04:00" kind: "build-log" subject: "home-automation" tags: ["esp32","heat-pumps"] series: "CN105" part: 2 --- I was hoping to aggregate as much data as possible from the compressors to be proactive, estimate energy, and to help build smarter automations around. The native Mitsubishi ecosystem seems to be able to estimate energy and generate statistics so I was hoping to be able to get these from CN105 with my new setup. At minimum I was hoping to be able to get outdoor temperature from the outdoor compressor units to help build automations and logic around (ie don't heat if it's warmer than X degrees right now, or in the last 12 hrs, plus using a forecast integration, would be very helpful for what I'm trying to accomplish). It turns out most of the data was there, it was just not being emitted from the heads that we tested initially. ## A whole lot of zeros The [MitsubishiCN105ESPHome](https://github.com/echavet/MitsubishiCN105ESPHome) component I built the firmware on in [part 1](https://michael.zazon.us/notes/nine-mitsubishi-mini-splits-in-home-assistant-for-15-per-head) has optional sensors for compressor frequency and energy, and I turned them on. On the first two heads I tried (a kid's room and the guest bedroom) they all read 0 even while the head was blowing cold air. The component already logs every frame it receives at debug level, so I could look at the raw bytes without the UART debug option (that one crash-loops the firmware before Wi-Fi comes up, so it's banned in this project). The status reply with the unit running had operating set to 1 and every measurement byte at 0: ``` 06 00 00 00 01 00 00 00 00 ``` ## 256 codes, five answers I believed they send data after talking to a tech, so I didn't want to take the zeros at face value. Mitsubishi's own apps weren't much help either: Kumo has no energy fields at all, and MELCloud labels its numbers "calculated values". CN105 is a request/reply serial protocol the community worked out in [SwiCago/HeatPump](https://github.com/SwiCago/HeatPump), where the controller sends a request with an info code and the head answers with a frame for that code (the status reply's first byte above, 0x06, is its code). The component only asks for codes people already know about, so the question was whether the data lived behind a code nobody was asking for. On a throwaway branch I had the guest bedroom head send one read-only request every 4 seconds for all 256 info codes. Only the five known codes ever answered. The unit stayed healthy the whole time, and the few dozen collisions with the normal polling cycle were harmless. I also did a load test (in case the numbers only show up when the compressor is working hard): the head in a kid's room at 61°F with the fan on high for 10+ minutes. The room temp dropped about 4°F and all 186 status replies were identical zeros. So the conclusion was "MSZ-GL doesn't report any of it" and I removed the six sensors from the firmware. ## Confidently wrong When we tried to analyze the serial data streams and didn't have any luck, I went looking for others who'd seen the same and also looked into research we did prior to the project. I found that some users thought the model we were running didn't emit this telemetry, some users said maybe only certain production batches emitted it, and other guesses. Looking back, every byte we captured was real. The mistake I made was jumping to a conclusion after seeing two heads - both on the same outdoor unit. These are multi-split systems (East feeds five heads, West feeds four), and the research said only a "lead" head on each outdoor unit might carry outdoor data. Lesson learned: sweep every head before deleting a sensor. ## The master head hunch My hunch about the master head ("Which one is the master head.. this might be the one that sends extra values!") turned out to be a good instinct to chase down, and I'm glad we went down that rabbit hole. When I fitted the last head, its room-temperature reply had bytes nobody had seen before. We swept all nine and found that 4 of 9 report a lifetime energy counter and runtime minutes: the kitchen, master bedroom, master closet and playroom. The living room reports outside air temperature only. The heads we tested first were exactly the zero kind. It's not a lead head thing, since there are two reporting heads on each outdoor unit, and it's not size either: all three GL09s report but only one of the three GL06s does. My best guess is a board revision or production batch (the GL06 serials split between 23E and 28E) but that's still unconfirmed. [Diagram: Diagram: the nine heads grouped by outdoor unit. On East, the master bedroom and kitchen report energy and runtime while the guest bedroom, a kid's room and the dining room report nothing extra. On West, the playroom and master closet report energy and runtime, the living room reports outside temperature only, and a kid's room reports nothing extra](https://michael.zazon.us/notes/the-mitsubishi-heat-pump-telemetry-hunt) ## Counting what, exactly? Runtime is easy - ticks once per minute of run (11 ticks in an 11 min run) and lifetime is in the 8800-11000 hour range across the heads. Energy is weird - the 4 heads read between 67 and 106 "kWh" lifetime, ticks in 0.1kWh steps, but 106kWh / ~10279 run hours is like 10W average which is obviously wrong. It also didn't tick once in 11 mins at full load. So either the scale is off, or it's measuring something other than what the name says (or it wraps?) - I'm treating it as relative only until I can get it on a meter. Still no live power or compressor frequency on any of the 9 heads. [Image: Home Assistant history for the kitchen head's Energy sensor: it reads 106.6 kWh, flat at 106.5 for most of a day and then stepping up 0.1 kWh in a single jump in the evening](https://michael.zazon.us/notes/the-mitsubishi-heat-pump-telemetry-hunt) ## Don't cool when it's 61 outside The outside temperature is the piece I'm putting to work right now. My climate coordinator in Home Assistant has a weather gate: in Auto, a room may cool only while it's at least 58 °F outside now and for the next 3 hours (the coldest of the current temperature and the next three hourly forecasts from the [weather integration](https://www.home-assistant.io/integrations/weather/)), and heat only on days whose forecast high is 75 °F or less. Both thresholds are settings. The cool gate originally used the day's forecast high, but lows here sit in the 40s on 70-degree days, so Auto cooled all night: on Oct 5 the head in a kid's room cooled at 61 °F outside and the room fell to 67.6 °F. Since Oct 6 the cool gate reads the outdoor units' own temperature from CN105 when it's live, and the same readings will feed the boiler's balance point (5 °F by default, since both outdoor units are Hyper-Heat). [Image: Home Assistant history for the kitchen head's Outside Air Temperature sensor over about ten minutes, rising from 63 to 65 °F and easing back to about 62 °F](https://michael.zazon.us/notes/the-mitsubishi-heat-pump-telemetry-hunt) Like I mentioned, we're building automations around the outdoor temp currently, and I'd like to get into energy estimations in the future but that will probably require some AC clamps on each unit to do what I really want to do. I'll be doing a thermostat in the doorway next in this series, and then the coordinator itself (set a zone temp and have the system figure it out).