2026.9.3

This release is about the operation-data sensors and the log noise around them. Reported in #230 by @alexnikgr and @hunter-nl, who both ran the betas: the operation data now arrives far more reliably, and the refusals that remain mostly recover on their own.

Operation data (the optional "Service Data" sensors)

• The request carrying the operation-data codes went out about a second behind the status poll, and modules refuse a second request that soon with HTTP 501 Not supported this command — roughly one poll in seven on one of the reported units. It now lands in the quiet middle of the cycle and is retried once after five seconds. (#233)
• The rate limit guarding that request was measured against the full poll interval but compared against the time a poll finished, so a poll that answered a few milliseconds faster than the one before it dropped the whole cycle — 6 of 36 cycles in one log, every one short by under 100 ms. (#239)
• Values are no longer carried forward for ever. After three missed cycles the sensors fall back to unknown instead of reporting a frozen number that looks live. (#233)

Connection handling

• A command the unit declines no longer counts as a dead connection, so the next request doesn't pay for a protocol rediscovery. (#231)
• These modules restart their WiFi roughly once an hour on their own. A poll landing in that window is now a single line in the log instead of an aiohttp traceback plus a second warning from the account re-registration behind it. (#231)
• The per-request timeout is 25 s and the poll timeout is derived from it (55 s), so one poll has room for both legs of protocol discovery. A unit that accepts a plaintext connection without answering it used to consume the whole window on the first leg and could never recover on its own. Found by @SoftwareSchmied. (#237)
• A poll that runs past its timeout now names the device and the wait, instead of appearing as Error fetching … data: with nothing after the colon.

Error codes

• Protective stop codes (M…) resolve through the same table as the displayed fault codes, taken from the MHI databooks, and are prefixed so a stop the unit recovered from stays distinguishable from a fault it is displaying. Seven codes added, three corrected. Raised by @mungojam in #225. (#235)

Known issue

With "Service Data" switched on, a change made at the unit itself — IR remote or the Smart M-Air app — can be written back from the last poll about a minute later. The option is off by default; see #241 for the detail and the fix under consideration.