Conversation
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Adds a high-level “cleaning mode” abstraction for V1 devices (vacuum / vac+mop / mop / custom / smart), including mode classification from status codes and RPC payload generation for setting modes.
Changes:
- Introduces
CleaningModesplus helpers to compute supported options, classify current mode, and buildSET_CLEAN_MOTOR_MODEpayloads. - Exposes cleaning-mode options/current mode/name and adds
set_cleaning_mode()onStatusTrait. - Adds/extends unit tests for cleaning mode behavior and updates the V1 device snapshot output.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
roborock/data/v1/v1_clean_modes.py |
Adds CleaningModes and implements option discovery, payload generation, and current-mode classification. |
roborock/devices/traits/v1/status.py |
Surfaces cleaning-mode APIs on StatusTrait (options/current/name/get/set). |
tests/devices/traits/v1/test_status.py |
Adds a focused test suite for cleaning-mode options, classification, and RPC payloads. |
tests/devices/__snapshots__/test_v1_device.ambr |
Updates snapshot to include newly exposed cleaning-mode fields. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (1)
roborock/data/v1/v1_clean_modes.py:304
is_smart_mode_set()has the same int-vs-enum comparison issue asis_mode_customized(): whenwater_mode/clean_mode/mop_modeare ints from device status, expressions likewater_mode == WaterModes.SMART_MODEwill always beFalse. Compare using.codeor reverse operand order (e.g.,WaterModes.SMART_MODE == water_mode) so SMART_MODE is correctly detected.
return (
water_mode == WaterModes.SMART_MODE
or clean_mode == VacuumModes.SMART_MODE
or mop_mode == CleanRoutes.SMART_MODE
)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
roborock/data/v1/v1_clean_modes.py:304
is_smart_mode_set()has the same int-vs-RoborockModeEnumcomparison issue asis_mode_customized()(e.g.,water_mode == WaterModes.SMART_MODE). When callers pass integer codes, these checks will always beFalsebecause theintis on the left. Compare against.codevalues or flip the comparisons so the enum’s__eq__can handle ints.
return (
water_mode == WaterModes.SMART_MODE
or clean_mode == VacuumModes.SMART_MODE
or mop_mode == CleanRoutes.SMART_MODE
)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| SUPER_DEEP = ("super_deep", 8) | ||
|
|
||
|
|
||
| class CleaningModes(StrEnum): |
| return options | ||
|
|
||
|
|
||
| def get_mop_only_vacuum_mode(features: DeviceFeatures) -> VacuumModes: |
There was a problem hiding this comment.
This is getting the vaccuum mode when the vacuum is in mop only mode?
| ) | ||
|
|
||
| @property | ||
| def cleaning_mode_name(self) -> str | None: |
There was a problem hiding this comment.
Should be current_cleaning_mode_name?
| return cleaning_mode.value | ||
|
|
||
| def get_cleaning_mode_parameters(self, cleaning_mode: str | CleaningModes) -> list[dict[str, int]]: | ||
| """Get the RPC payload for the selected high-level cleaning mode.""" |
There was a problem hiding this comment.
I was going to say this can be private, but really I think it can just be inlined. in set_cleaning_mode
| SUPER_DEEP = ("super_deep", 8) | ||
|
|
||
|
|
||
| class CleaningModes(StrEnum): |
There was a problem hiding this comment.
Some pydoc here describing how this differs from the other lower level modes would be useful. Basically never use those and always use this?
| return WaterModes.STANDARD.code | ||
|
|
||
|
|
||
| def _get_clean_motor_mode_params(mode: CleaningModes, features: DeviceFeatures) -> tuple[int, int, int]: |
There was a problem hiding this comment.
I think this should be using the enum types instead of the code everywhere in this file, then only convert to the code when added to the params dict
| return [params] | ||
|
|
||
|
|
||
| def get_current_cleaning_mode( |
There was a problem hiding this comment.
One thought is that this could be on CleaningModes as a classmethod like CleaningModes.from_modes
or similarlyget_cleaning_mode_parameters can be CleaningModes.get_params(...)
I think the only advantage could be the names would be shorter, but otherwise its not to different than what is here and can just be a style choice (optional)
|
|
||
|
|
||
| def get_current_cleaning_mode( | ||
| clean_mode: int | None, |
There was a problem hiding this comment.
Can this also take the enum values instead of the codes?
| def get_cleaning_mode_parameters(cleaning_mode: str | CleaningModes, features: DeviceFeatures) -> list[dict[str, int]]: | ||
| """Get the RPC payload for switching the high-level cleaning mode.""" | ||
| try: | ||
| mode = CleaningModes(cleaning_mode) |
There was a problem hiding this comment.
i'd say do the string to enum conversation as high up as possible and just take the enum here
Adds a clean mode selector