2026.9.4

What the two betas were building towards. The headline fix only shows up with the optional Service Data option on; the rest applies to every install.

Changes made at the unit are no longer undone

With Service Data on, anything changed at the unit itself — IR remote or the Smart M-Air app — could be silently written back about a minute later. A self-clean cycle started from the remote turned into an ordinary fan run within minutes. Found by @c-scoot in #241 and #250.

The protocol offers no way to ask for the operation data on its own, so the request rode on a write carrying the unit's complete state — taken from the previous poll, which is why anything changed in between was overwritten. It now carries none of the bits that apply a setting. Measured on both of my indoor units, running and switched off: the full operation data comes back, and power, mode, fan speed, setpoint and both vane axes stay untouched. This closes the known issue listed under 2026.9.3.

New: what the indoor coil is doing

Two new sensors with Service Data on, Indoor Coil Temperature and Indoor Coil Outlet Temperature (MHI's THI-R1 and THI-R3). Unlike compressor frequency, which is an outdoor-unit value shared across a multi-split, these are per indoor unit: in cooling the coil temperature drops as the coil gets cold and returns to room temperature once the compressor stops, and the gap between the two while it runs is the evaporator superheat.

The conversion is not a lookup table. The sensor is a ~5 kΩ NTC in a divider, and inverting that covers the whole byte range — heating included, where the coil runs past 45 °C. It is anchored against a thermometer through a heating run, RMS 0.25 K between 23 and 46 °C. Two limits are documented rather than hidden: above byte 170 the curve is extrapolation, and at the cold end it reads a few degrees above the manual's frost cut-off. @alexnikgr supplied the sensor's part data in #223, which is what made the curve checkable in the first place.

The log only speaks up when something changed

Two things used to warn about once an hour per unit, neither with any consequence: a poll landing in the module's hourly WiFi restart, and a refused operation-data request. Both are debug lines now. A warning is written when the integration's state actually changes — a unit crossing the availability threshold, operation data expiring to unknown — and once more when it recovers. On a healthy system that should mean a quiet log.

Also in here

• Offline handling and automatic recovery, contributed by @SoftwareSchmied: the last working protocol is remembered and tried first, so a unit that only answers one of the two can recover on its own. He also found that the per-request and per-poll timeouts left room for only one attempt where discovery needs two.
• A command the unit accepts but refuses is now visible. Every response carries a result field that nothing read, so HTTP 200 plus "operation prohibited" passed as success — a candidate for the "nothing happens, and nothing in the log" reports. result: 2 names both of its causes: a full account table, or an expired registration.
• Translations caught up — Dutch, Japanese, Lithuanian and both Chinese variants were missing everything added since the home-leave controls. Corrections from native speakers are welcome.
• The energy counter's resolution is documented. The unit reports in 0.25 kWh steps, so short runs round away; the README now says so instead of leaving it to be discovered. Raised by @bert-58 in #214.

If you ran the betas

The raw byte sensors are gone from this release — indoor and outdoor coil, discharge superheat, protection number. The two indoor-coil ones did their job: the curve above is what they were for. The other three carry bytes with no established conversion, and a unitless number in a temperature's place is only useful to someone decoding the protocol, so a stable release is the wrong place for them.

They return in the next beta, which is where working them out belongs. The outdoor coil is the same thermistor as the indoor one behind a different resistor, and the first defrost cycle of the winter pins its curve for free — the coil sits at 0 °C then. The protection number is answered by every module I have seen but has read 0 on all of them, including units that have been throttled by their own overload protection, so what is still missing is one reading taken inside a protective state (#225). Discharge superheat has read a constant 0 on three units, and I would like to know whether any model reports it at all.

The parser keeps requesting all of it either way, so nothing is lost from the polls in the meantime.

There's a sponsor button in the sidebar now, in case this saved you an afternoon.