Fix rotation conflicts between multiple Roborock devices#40
Open
TheHangMan97 wants to merge 11 commits into
Open
Fix rotation conflicts between multiple Roborock devices#40TheHangMan97 wants to merge 11 commits into
TheHangMan97 wants to merge 11 commits into
Conversation
Introduce rotation configuration constants for map image handling. Adds rotation options (0, 90, 180, 270) and dispatcher signal name.
Add SelectEntity to control map rotation per map_flag. Rotation value is persisted via RestoreEntity and stored in hass.data. Dispatcher signal notifies image entities when rotation changes.
Register SELECT platform and initialize rotation storage in hass.data. Add proper unload cleanup and reload behavior.
Implement backend image rotation using Pillow. Rotation is applied in async_add_executor_job to avoid blocking the event loop. Includes defensive validation and fallback handling.
Add English and German translations for map rotation select entity. Includes user-friendly labels for rotation options.
Add documentation for the per-map rotation select entity. Explains: - How to rotate maps (0/90/180/270) - Where to find the rotation select entity - That calibration points are rotated as well - That no reload is required Also clarifies usage with Xiaomi Vacuum Map Card.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This prevents multiple Roborock devices with identical map_flag values from sharing rotation state and dispatcher signals.
I found and fixed a thread-safety issue in the rotation update signal. The image entity now schedules the state update back onto the Home Assistant event loop before calling `async_write_ha_state()`, instead of calling it directly from the dispatcher callback.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR fixes a rotation state conflict when multiple Roborock devices are used with the integration.
Previously, rotation values were stored only by map_flag. Since multiple Roborock devices can share the same map_flag values, changing the rotation on one robot could unintentionally affect another robot. #39
Fix
Rotation state and dispatcher signals are now isolated per device and map by using a combined key:
f"{coordinator.duid_slug}_{map_flag}"
instead of only:
map_flag
Included changes
Result
Rotation settings are now fully independent for each robot and map.
A user with multiple Roborock devices has successfully tested and confirmed the fix 😊