Skip to content

Add map entities when home data arrives, not only at setup - #43

Open
paolostivanin wants to merge 1 commit into
Python-roborock:mainfrom
paolostivanin:add-map-entities-when-home-data-arrives
Open

Add map entities when home data arrives, not only at setup#43
paolostivanin wants to merge 1 commit into
Python-roborock:mainfrom
paolostivanin:add-map-entities-when-home-data-arrives

Conversation

@paolostivanin

Copy link
Copy Markdown

The problem

On a two-robot setup, one of my vacuums (Rocky) comes up with no map image entity and no rotation select after most Home Assistant restarts. The other one (Rocky Jr) is always fine. Reloading the config entry by hand fixes it every time, which is what pointed at a race rather than a config issue.

Both platforms build their entities exactly once, in async_setup_entry, and skip any coordinator whose home data has not landed yet:

for coord in config_entry.runtime_data:
    if coord.properties_api.home is not None:
        for map_info in (coord.properties_api.home.home_map_info or {}).values():
            ...

That is not None is treated as an invariant, but it is a race. The core Roborock coordinator calls discover_home() during its own setup, and a device that happens to be busy at that moment raises RoborockDeviceBusy, which the coordinator swallows with an _LOGGER.info. Home data then arrives a little later through the normal update cycle - but async_setup_entry has already returned, so that device is silently left with no entities.

There is no warning and no retry, so from the user side it just looks like the integration randomly drops a robot. image.py and select.py have the same guard, which is why the map and its rotation select always disappear together.

The fix

Keep a set of the (device, map_flag) pairs already added, and re-run the scan on every coordinator update instead of only at setup. Entities appear as soon as their home data does, and the dedupe set makes the repeated scan a no-op once everything is present.

As a side effect this also picks up maps created in the Roborock app while Home Assistant is running, which previously also required a manual reload.

Listeners are registered via config_entry.async_on_unload(coord.async_add_listener(...)) so they are torn down with the entry.

Notes

  • No config or entity-naming changes - unique_ids are built exactly as before, so existing entities are untouched on upgrade.
  • ruff check passes. ruff format wants to reformat two pre-existing lines (a stray blank line in image.py, the RoborockMapRotationSelect class signature); I left those alone to keep the diff to the actual change.
  • Tested on HA 2026.7.4 with two V1 robots (a117 + a159) that reproduce the race on nearly every boot. Both maps and both rotation selects now come up on their own, no manual reload.

🤖 Generated with Claude Code

Both platforms built their entities once, in async_setup_entry, and
skipped any coordinator whose properties_api.home was still None.

That is a race, not an invariant. The core Roborock coordinator calls
discover_home() during setup, and a device that happens to be busy at
that moment raises RoborockDeviceBusy, which the coordinator swallows
with an _LOGGER.info. Home data lands a little later via the normal
update cycle - but by then async_setup_entry has already returned, so
that device silently gets no map image and no rotation select. There is
no log line and no retry; the only cure is reloading the config entry by
hand, and on a two-robot setup one of them can lose the race on most
boots.

Keep a set of the (device, map_flag) pairs already added and re-run the
scan on every coordinator update, so entities appear as soon as their
home data does. As a side effect this also picks up maps created in the
Roborock app while Home Assistant is running, which previously needed a
reload too.

The listeners are registered through config_entry.async_on_unload so
they are torn down with the entry.
@paolostivanin
paolostivanin force-pushed the add-map-entities-when-home-data-arrives branch from 88f3c06 to 1d26979 Compare July 30, 2026 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant