feat: add better cleaning mode support

[Lash-L]

Adds a clean mode selector

[codecov]

Codecov Report

❌ Patch coverage is 94.35897% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
roborock/data/v1/v1_clean_modes.py	90.62%	5 Missing and 4 partials ⚠️
tests/devices/traits/v1/test_status.py	97.67%	1 Missing and 1 partial ⚠️

Files with missing lines	Coverage Δ
roborock/devices/traits/v1/status.py	97.05% <100.00%> (+0.69%)	⬆️
tests/devices/traits/v1/test_status.py	98.88% <97.67%> (-1.12%)	⬇️
roborock/data/v1/v1_clean_modes.py	87.98% <90.62%> (+5.52%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

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 CleaningModes plus helpers to compute supported options, classify current mode, and build SET_CLEAN_MOTOR_MODE payloads.
• Exposes cleaning-mode options/current mode/name and adds set_cleaning_mode() on StatusTrait.
• 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.

[Copilot]

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.

[Copilot]

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 as is_mode_customized(): when water_mode/clean_mode/mop_mode are ints from device status, expressions like water_mode == WaterModes.SMART_MODE will always be False. Compare using .code or 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.

[Copilot]

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-RoborockModeEnum comparison issue as is_mode_customized() (e.g., water_mode == WaterModes.SMART_MODE). When callers pass integer codes, these checks will always be False because the int is on the left. Compare against .code values 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.

[allenporter]

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)

[Lash-L]

I don't have too strong of an opinion on this (so i can easily be convinced), but I think I'll keep it like this for now as it matches the rest of the file. Perhaps it makes sense to make all of these use clash methods instead though.