[endoftheline818]

Some vacuums show "NO MAP" even though a saved map is already selected. Selecting that same map again restores the image. This change performs that recovery automatically when the vacuum is idle or charging, without interrupting cleaning or a return to the dock.

The fix belongs in HomeTrait, as requested in home-assistant/core#186678:

• Load the known selected map before fetching its image during single-map discovery and normal refresh. Reuse the existing map-loading delay, and avoid loading a map twice during multi-map discovery.
• Read status again after the map-loading delay. The immediate status read inside set_current_map() can still report map_present == 0 while the map is loading, causing another load command on the next refresh.
• Defer discovery while the device is busy, or while a cached home needs rediscovery and the device reports no current map. Translate a refused reload into RoborockDeviceBusy and let refresh read the current map without repeating the rejected command.
• Keep "NO MAP" placeholders out of the saved map cache and preserve the last good map during a temporary empty response. Placeholders cached by older versions are excluded from memory and replaced after discovery successfully runs again. While discovery is blocked (device busy or no current map), it stays pending and the saved cache is left unchanged, so the missing map is rediscovered on the first later refresh that can run it.
• During discovery, copy cached map metadata and filter parsed content into separate dictionaries, leaving the saved cache unchanged while rediscovery is pending.

Fixes #985. Related: home-assistant/core#185133 and home-assistant/core#186678.

Validation:

• The added recovery, rediscovery and status tests reproduce the failures before their fixes and pass afterward.
• Full Linux test suite on Python 3.11: 1,650 passed, 53 expected failures, 11 real-broker tests excluded by the default configuration; 99 snapshots passed.
• Full Linux test suite on Python 3.14: 1,650 passed, 53 expected failures, 11 real-broker tests excluded by the default configuration; 99 snapshots passed.
• On Python 3.11, all pre-commit checks passed, including Ruff, mypy and codespell, and the wheel and source distribution builds passed.

Tests use simulated device responses. A physical Q5 Pro has not been tested with this change.

AI assistance: OpenAI Codex and Anthropic Claude Code helped prepare, review, and test this change under the contributor's direction.

[swastiktawate]

This is a thorough fix. The recovery path is properly guarded — idle/charging states only, never while cleaning or returning — and the fallback to recover_missing=False on a busy device means a locked action degrades gracefully instead of failing the whole refresh. Filtering placeholder 'NO MAP' images out of both the in-memory and persisted cache is the right call, and the guard matrix plus the exactly-once reload assertion in the tests show the edge cases were thought through.

[Lash-L]

Automated code review by Gemini 4 Argon in Antigravity using our /review (/code-review) skill (.agents/skills/code-review/SKILL.md / AGENTS.md).

Summary

Well-structured fix for #985 that keeps missing-map recovery and placeholder filtering encapsulated within HomeTrait, avoids redundant LOAD_MULTI_MAP calls during multi-map discovery, and degrades gracefully when map switching is locked (RoborockInvalidStatus -> RoborockDeviceBusy).

• Layer 1 — Public Trait APIs & Consumer Contracts: Preserves the public HomeTrait API (discover_home(), refresh(), home_map_info, home_map_content) while broadening RoborockDeviceBusy handling when the vacuum cannot switch maps.
• Layer 2 — Data Lifecycle & State Management: Filters empty placeholder maps (_has_map_image) before updating both in-memory _home_map_content and persistent DeviceCache, preserving the last known good map across transient empty responses.
• Layer 5 — Tests & Fixtures: Comprehensive parameterized coverage in tests/devices/traits/v1/test_home.py covering state/flag guards, action-locked fallback, placeholder eviction, and single- vs. multi-map discovery.

A few lifecycle and state-handling items noted inline:

1. Include RoborockStateCode.charger_disconnected (and check in_fresh_state / is_locating) in _MAP_LOADING_STATES (roborock/devices/traits/v1/home.py#L39): State 2 (charger_disconnected) is the V1 sleeping / idle-off-dock state when the robot is not on the charger and no task is active (in_fresh_state == 1). Excluding it causes discover_home() and missing-map recovery to treat a sleeping/idle off-dock robot as busy.
2. set_current_map() Refreshes StatusTrait Before MAP_SLEEP (roborock/devices/traits/v1/home.py#L178-L181): MapsTrait.set_current_map() sends LOAD_MULTI_MAP and immediately calls self._status_trait.refresh() before await asyncio.sleep(MAP_SLEEP). If the vacuum does not flip map_present to 1 until the MAP_SLEEP delay completes, self._status_trait.map_present remains 0 in memory and can trigger another reload on the next HomeTrait.refresh() if StatusTrait is not refreshed again.
3. Evicting Cached Placeholders in discover_home() Without Re-Discovering (roborock/devices/traits/v1/home.py#L112-L122): Stripping placeholder entries from home_map_content_base64 and returning early with self._discovery_completed = True leaves non-active maps on multi-map devices permanently unpopulated (since refresh() only refreshes the active map once _discovery_completed is True). Also, setting self._discovery_completed = True before the cache-parsing try block leaks _discovery_completed = True if cache parsing fails and the subsequent busy check raises RoborockDeviceBusy.

[Lash-L]

Include Off-Dock Idle / Sleeping State (RoborockStateCode.charger_disconnected) and Guard Against is_locating

On V1 devices, state 2 (RoborockStateCode.charger_disconnected) represents the sleeping / idle-off-dock state when the vacuum is stationary off the dock with no task running (in_fresh_state == 1, in_cleaning == 0, in_returning == 0). Excluding RoborockStateCode.charger_disconnected from _MAP_LOADING_STATES means a vacuum sitting idle/sleeping off the charger will raise RoborockDeviceBusy during discover_home() and never recover a missing map.

Additionally, in _refresh_map_content() / discover_home(), this should also avoid loading a map when self._status_trait.is_locating == 1 (or when self._status_trait.in_fresh_state is not None and self._status_trait.in_fresh_state != 1), as the robot invalidates the current map ID while locating.

Suggested change

	_MAP_LOADING_STATES = (RoborockStateCode.idle, RoborockStateCode.charging, RoborockStateCode.charging_complete)
	_MAP_LOADING_STATES = (
	RoborockStateCode.charger_disconnected,
	RoborockStateCode.idle,
	RoborockStateCode.charging,
	RoborockStateCode.charging_complete,
	)

[endoftheline818]

Thanks for reviewing. I’ve left state 2 and the additional status guards unchanged for now. Could you share device diagnostics or protocol references supporting state 2 as safe for map loading and clarify the expected in_fresh_state and is_locating values

[Lash-L]

Cached Placeholder Cleanup Skips Re-Discovery for Missing Maps & Sets _discovery_completed Too Early

Two subtle lifecycle issues here:

1. self._discovery_completed = True is set on line 102 before the try block. If async_parse_map_content raises (ValueError, RoborockException) and the fallback discovery then raises RoborockDeviceBusy at line 129, self._discovery_completed remains True even though discovery failed and self._home_map_content is {}.
2. When an older version cached a "NO MAP" placeholder for a non-active floor on a multi-map device, filtering it out of self._home_map_content and device_cache_data.home_map_content_base64 and returning early with self._discovery_completed = True means that floor's map will never be fetched (since subsequent refresh() calls only update current_map_info). Similarly, for a single-map device, discover_home() returns with self._home_map_content == {} until a separate refresh() is called.

Consider only returning early when all maps in self._home_map_info still have valid map content (or re-running discovery when cached entries had to be evicted), and moving self._discovery_completed = True into the else: branch after cache validation succeeds.

[endoftheline818]

Addressed in fdc71a8 and ed7b28e. Cached placeholders now trigger rediscovery while good cached images remain available. Discovery stays pending if the robot is busy or no current map is available, and the saved cache remains unchanged until discovery completes. Regression tests cover busy-to-idle recovery and recovery after a current map becomes available.

[Lash-L]

StatusTrait.refresh() Inside set_current_map() Runs Before MAP_SLEEP

self._maps_trait.set_current_map(...) sends LOAD_MULTI_MAP and immediately calls await self._status_trait.refresh() before await asyncio.sleep(MAP_SLEEP) here. As modeled in test_multi_map_discovery_does_not_reload_twice, the immediate GET_STATUS response right after LOAD_MULTI_MAP can still report map_present == 0 while the vacuum is loading the map over MAP_SLEEP.

If a caller runs home_trait.refresh() again without an intervening status_trait.refresh(), self._status_trait.map_present will still be 0 and _refresh_map_content() will issue LOAD_MULTI_MAP + sleep(MAP_SLEEP) again even though the map is now loaded. Refreshing self._status_trait after await asyncio.sleep(MAP_SLEEP) (or skipping recovery when self._home_map_content already holds a valid image for current_map_info.map_flag unless map_present == 0 was freshly observed) avoids redundant reloads.

[endoftheline818]

Addressed in fdc71a8. Both single-map recovery and multi-map discovery now refresh status again after the map-loading delay. Tests model the immediate status reporting map_present == 0, the later read reporting 1, and a subsequent refresh sending no additional load command.

[endoftheline818]

Updated the PR description with the follow-up fixes and final Linux validation results. I've also replied to all three review threads. Hosted CI for ed7b28e is awaiting maintainer approval. Could you approve the workflow run when convenient?