v3.2.0

Roomba+ v3.2.0 — Twelve New Features, Self-Calibrated Throughout

Config entry version: 24 (unchanged — no migration required)
Minimum Home Assistant: 2025.5.0
Breaking changes: none for end users

Overview

The largest feature release since v3.0.0: twelve new capabilities spanning maintenance diagnostics, room-level intelligence, anomaly explanation, and layout-change detection — plus a systematic multi-round code review that caught and fixed several real bugs before they reached anyone's install. Every self-calibrating feature in this release follows the same principle already established for L9-BATTERY and L8's health score: judge a robot against its own learned normal, not a fixed number that's wrong for half the fleet.

New features

Twelve new capabilities, split below by how quickly they become useful — several of the most interesting ones are genuinely worth the wait, but it's worth knowing upfront which is which.

Useful right away

• Anomaly explanation (roomba_plus.explain_mission service + REST) — turns a flagged anomaly into a plain-language reason (obstacle/blockage, excessive recharge, dirt spike, incomplete coverage) with a matching recommended action. Works on any past mission immediately — and the result is also folded straight into every roomba_plus_mission_completed event payload, so a notification automation gets the reason for free without knowing this service exists.
• Reset diagnostics (sensor.*_reset_diagnostics) — surfaces the robot's own reset-cause breakdown, previously entirely unread. Shows real data from the moment it's created, if your robot has any reset history at all.
• Mission path replay (REST) — room-granular post-hoc reconstruction of a mission's path. Works on any archived mission immediately.
• Stuck context event (roomba_plus_stuck) — fires with an actionable payload the next time the MQTT watchdog trips. No history needed.
• Child lock & eco charge switches, dock firmware version — plain controls/readouts, active immediately on models that report the preference.
• Team clean indicator (disabled by default) — shows on the very next mission if it happens to be an Imprint Link team clean.

Builds up over the following weeks

These are self-calibrating — each one learns this specific robot's normal behaviour rather than using a fixed threshold, which is what makes them useful, but it does mean a real wait before they show anything besides "learning" on a fresh install or update. New readiness attributes added in this release now make that wait visible on the entity itself rather than a silent, unexplained blank state:

• Health score trend — 44 days of history needed; days_until_ready is exposed as an attribute from day one so you can watch it count down.
• Layout change detection — 23 missions of per-cell coverage history needed; missions_until_first_ready (and cells_tracked) are now shown even before any candidate is found, so "still learning" no longer looks identical to "nothing to report."
• Room accessibility scores — appears per-room as soon as that room has any signal at all (score null until then); a handful of missions with stuck events or timing data.
• Cleaning cadence health — needs at least 3 recorded intervals between cleans of a given room (so, at minimum, 4 cleans of that specific room) before it can judge "overdue" against that room's own rhythm.
• Stuck hotspot clusters — needs at least 2 adjacent grid cells to each independently reach the stuck-event threshold before a cluster forms; a real (if unwelcome) obstacle typically produces this within a handful of missions.
• Room type suggestion — depends on iRobot's cloud having already computed a room-type suggestion for that region; timing is outside this integration's control.

Notable fixes found during development

Several of these features went through real design corrections during development, and a following multi-round code review caught issues that wouldn't have surfaced from normal testing alone:

• Health score trend reference-window contamination. The original design excluded only the most recent 14 days from the historical reference used to judge a decline — meaning a decline lasting longer than 14 days started pulling its own older days back into the reference set, silently masking the exact decline it was meant to detect (reproduced directly: a 25-day decline was misclassified "stable"). Fixed with a wider, independently-sized exclusion buffer.
• Layout-change dismiss suppression never actually worked. Confirmed against Home Assistant's own Issue Registry source: re-creating a previously-dismissed issue does not reset its dismissed state, so after the intended 30-day suppression window, the issue would have stayed permanently hidden instead of resurfacing. Fixed by deleting the stale issue before recreating it.
• Orphaned Repair Issues for stuck hotspots and cleaning cadence. Both could leave stale issues behind — stuck hotspots when a cluster's membership shifted, cleaning cadence when a room was renamed in the iRobot app. Both now clean up automatically.
• Import endpoint accepted type-malformed records. A history-import record only needed an id to be accepted — a record with, say, a numeric timestamp instead of an ISO string was persisted as-is and then permanently crashed the cleaning-cadence computation on every cloud-refresh cycle, surviving restarts. Found during a full-codebase review; fixed with type validation at the import gate plus defensive guards at both consumer sites, so even a store poisoned before this release degrades gracefully instead of crashing.
• Explicit-null firmware fields could crash the map, vacuum, and select platforms. iRobot firmware occasionally reports fields as explicit null rather than omitting them. A v2.8.0 fix addressed this class of bug in the MQTT callback path — but three other files with the same vulnerable pattern were missed at the time and stayed latent for years. The same full-codebase review found and fixed all 9 remaining sites (image.py, vacuum.py, select.py).
• Two independent instances of a pre-existing "hardcoded test date drifts out of a rolling query window" issue were found and fixed along the way (unrelated to this release's new features, but caught while working in the same test files).

Test suite

3,253 tests, 0 failures (baseline before this release: 2,993).

Upgrade notes

No config entry migration — all persisted data is additive; existing GridStore, MissionStore, and RobotProfileStore data loads unchanged. See "Builds up over the following weeks" above for which new features need mission history before they show a real value — that's expected self-calibration, not a bug, and it's now visible directly on the affected entities: sensor.*_health_score_trend exposes a days_until_ready attribute, and binary_sensor.*_layout_change_detected exposes missions_until_first_ready even before any candidate is found, so the learning period no longer looks identical to "already checked, nothing to report."