Mopping unavailable from the dock on auto-mount-mop models (only "sweeping" offered)

[hacosta]

Describe the bug

On an auto-mount-mop model (self-wash base that auto-detaches/parks the mop pads in the dock), the integration cannot start a vacuum-and-mop (or mop) clean while the robot is docked — i.e. the normal idle state between cleans. While docked, select.<vac>_cleaning_mode lists only sweeping; the mopping and sweeping_and_mopping modes are stripped from cleaning_mode_list and the mode is force-set to sweeping. Requests via dreame_vacuum.vacuum_clean_segment (water_volume) and dreame_vacuum.vacuum_set_custom_cleaning (cleaning_mode: [2]) are also silently down-ranked to sweeping. The Dreame app can start a mop from the dock (it mounts the parked pads on demand), so the integration is not matching app behavior.

Root cause appears to be that mop_in_station is forced False whenever the robot is docked:

# device.py
def mop_in_station(self) -> bool:
    value = self._get_property(DreameVacuumProperty.MOP_IN_STATION)
    return bool(value == 1 or value == 4) and not self.docked   # <-- forced False while docked

The cleaning-mode availability logic (_water_tank_changed) and set_cleaning_mode both gate on (not auto_mount_mop or not mop_in_station). While docked, mop_in_station is False, so on a machine with no onboard tank and no pad currently mounted (water_tank_or_mop_installed is False), the mop modes get popped and the mode is force-set to sweeping; set_cleaning_mode(mopping) also raises "Cannot set mopping while mop pads are not installed." The net effect is that on auto-mount + mop-pad-unmounting models the mopping path is unreachable from the dock — even though auto_mount_mop is the feature meant to fetch the parked pads.

To Reproduce

1. Auto-mount model, docked and idle, mop pads auto-parked in the dock (mop pad sensor = not_installed, auto_mount_mop on).
2. Try to start a mop via any of:
   • select.select_option on select.<vac>_cleaning_mode → sweeping_and_mopping (the option isn't even listed; only sweeping is).
   • dreame_vacuum.vacuum_clean_segment with water_volume: [2].
   • Turn on customized_cleaning, call dreame_vacuum.vacuum_set_custom_cleaning with cleaning_mode: [2], then clean the segment.
3. The robot only sweeps; the pads stay in the dock (mop_pad stays not_installed, cleaning_mode stays Sweeping).

Expected behavior

As in the Dreame app: the robot returns to the dock, installs the parked pads, and mops — cleaning_mode becomes mopping / sweep+mop and the mop pad reads installed.

Screenshots

N/A. Note: cleaning_mode_list exposes only ["sweeping"] while docked with pads parked; it immediately expands to all four modes once the pads are physically mounted (which is the workaround).

Additional Information (please complete the following information)

• Model Name [e.g. dreame.vacuum.p2028]: dreame.vacuum.r24162
• Firmware Version [e.g. 1156]: 1760 (4.3.9_1760)
• Home Assistant Version: 2026.5.4
• Configuration Type [With or without map support]: With map support
• Errors or warnings shown in the HA logs (if applicable): None on the silent sweep. Separately, dreame_vacuum.vacuum_set_custom_cleaning raises HomeAssistantError: Mop temperature is not supported on this device when mop_temperature/mop_pressure are passed, even though the service schema marks them required.

---

Integration version: v2.0.0b23.

Related: #1615 (similar "sweeping becomes the only available mode" symptom, but different root cause and a different model; that one was resolved by upgrading to b23, whereas this is reproducible on b23).

Suggested fix

The mode-availability pruning (_water_tank_changed), set_cleaning_mode, and the mode-list builder all share the guard (not auto_mount_mop or not mop_in_station). When auto_mount_mop is on and pads are parked in the station, that guard is meant to be skipped — but mop_in_station is hard-forced False while docked (return bool(value == 1 or value == 4) and not self.docked), so the guard always engages from the dock, mop modes get stripped, and set_cleaning_mode(mopping) raises "Cannot set mopping while mop pads are not installed."

Rather than change mop_in_station itself (it's used elsewhere and the not docked clause may be intentional there), add a station-availability check that stays valid while docked and use it for the auto-mount gating:

@property
def mop_pads_available(self) -> bool:
    """Pads usable for this clean: mounted on the robot, OR parked in the
    station while auto-mount is enabled (valid even while docked)."""
    if self.water_tank_or_mop_installed:
        return True
    if self.auto_mount_mop:
        value = self._get_property(DreameVacuumProperty.MOP_IN_STATION)
        return bool(value == 1 or value == 4)
    return False

Then, in both _water_tank_changed (the if not self.status.water_tank_or_mop_installed: block that pops MOPPING/SWEEPING_AND_MOPPING and force-sets sweeping) and set_cleaning_mode (the elif not self.status.water_tank_or_mop_installed: raise ...), allow the mopping path when mop_pads_available is true — i.e. don't strip the modes, don't force sweeping, and don't raise, when pads are parked in the station on an auto-mount machine.

Caveat: this assumes the raw MOP_IN_STATION property is meaningful while docked. The existing and not self.docked suggests it may be unreliable when docked — if so, the alternative is to persist the last known parked-pad state across the dock transition instead of reading it live. Also unverified downstream: that the start command then actually triggers the auto-install — but the Dreame app does exactly this from the dock, so the firmware supports it.

Secondary fix (the mop_temperature error above): vacuum_set_custom_cleaning marks mop_temperature/mop_pressure as required in services.yaml, but the device rejects them ("Mop temperature is not supported on this device"). Make those fields required: false and only forward them in async_set_custom_cleaning when the capability is present.

Workaround

Keep the pads physically mounted and turn off auto_mount_mop; then water_tank_or_mop_installed is true and the mop modes remain available even while docked.

[Tasshack]

Rather than change mop_in_station itself (it's used elsewhere and the not docked clause may be intentional there), add a station-availability check that stays valid while docked and use it for the auto-mount gating:

This is how it is implemented inside the app source code but I will check it again to see how it is handling the case you have mentioned (docked but not installed).

[Tasshack]

@hacosta your assesment is correct, APP does not care the device is docked or not with mop is in station checks. I have checked the rest of the integration and decided that you can safely remove docked check from mop_in_station function. I have no idea where it came from or why I have included it.

    @property
    def mop_in_station(self) -> bool:
        """Returns true when the mop pad is in the station."""
        if self.water_tank_or_mop_installed:
            return False
        value = self._get_property(DreameVacuumProperty.MOP_IN_STATION)
        return bool(value == 1 or value == 4)

Only other place it has been used as a sensor is inside water_tank function that has another issue.

    @property
    def water_tank(self) -> DreameVacuumWaterTank:
-----
            if self.mop_in_station:
                return DreameVacuumWaterTank.IN_STATION
-----

DreameVacuumWaterTank does not have IN_STATION value but it is defined as MOP_IN_STATION instead.
You may also want to fix that from types.py and cons.py since the translations are still using "in_station". I guess I had forgot to change the enum name earlier.

types.py

class DreameVacuumWaterTank(IntEnum):
    """Dreame Vacuum water tank status"""

    UNKNOWN = -1
    NOT_INSTALLED = 0
    INSTALLED = 1
    MOP_INSTALLED = 10
    IN_STATION = 99  ## This was changed

const.py

WATER_TANK_IN_STATION: Final = "in_station" ## Previously as WATER_TANK_MOP_IN_STATION: Final = "mop_in_station"

WATER_TANK_CODE_TO_NAME: Final = {
    DreameVacuumWaterTank.UNKNOWN: STATE_UNKNOWN,
    DreameVacuumWaterTank.INSTALLED: WATER_TANK_INSTALLED,
    DreameVacuumWaterTank.NOT_INSTALLED: WATER_TANK_NOT_INSTALLED,
    DreameVacuumWaterTank.MOP_INSTALLED: WATER_TANK_MOP_INSTALLED,
    DreameVacuumWaterTank.IN_STATION: WATER_TANK_IN_STATION, ## This was changed
}

These fixes will be applied to the next Beta release, thanks for the help.

[dmc-gergobakos]

I may be experiencing a related cleaning mode issue on a Xiaomi model using the Dreame integration.

Device:

Model: dreame.vacuum.r2209
Integration version: v2.0.0b25

The select._cleaning_mode entity always exposes only these options:

mopping
sweeping_and_mopping

The sweeping option is never available, regardless of whether the mop tray is installed or removed.

When the mop tray is installed, the robot operates in one of the two exposed modes, so the entity shows a valid state.

When I remove the mop tray, the robot switches to vacuum-only mode internally, but the integration still exposes only mopping and sweeping_and_mopping. Because the actual mode is sweeping, which is not present in the entity’s options, the current state is shown as unknown.

The official Xiaomi app calls this mode Vacuum and allows me to switch to it regardless of whether the mop tray is installed. The robot behaves correctly in vacuum-only mode, but Home Assistant still reports the cleaning mode as unknown, because sweeping is missing from the available options.

So this appears to be both:

an incorrect cleaning mode option list, because sweeping is never exposed;
and a state mapping/detection issue, because vacuum-only mode is reported as unknown.

This prevents automations such as:

vacuum-only cleaning, including carpets;
followed by vacuum-and-mop cleaning.

Could this be related to the same cleaning mode filtering logic discussed in this issue?

[Tasshack]

I may be experiencing a related cleaning mode issue on a Xiaomi model using the Dreame integration.

Device:

Model: dreame.vacuum.r2209 Integration version: v2.0.0b25

The select._cleaning_mode entity always exposes only these options:

mopping sweeping_and_mopping

The sweeping option is never available, regardless of whether the mop tray is installed or removed.

When the mop tray is installed, the robot operates in one of the two exposed modes, so the entity shows a valid state.

When I remove the mop tray, the robot switches to vacuum-only mode internally, but the integration still exposes only mopping and sweeping_and_mopping. Because the actual mode is sweeping, which is not present in the entity’s options, the current state is shown as unknown.

The official Xiaomi app calls this mode Vacuum and allows me to switch to it regardless of whether the mop tray is installed. The robot behaves correctly in vacuum-only mode, but Home Assistant still reports the cleaning mode as unknown, because sweeping is missing from the available options.

So this appears to be both:

an incorrect cleaning mode option list, because sweeping is never exposed; and a state mapping/detection issue, because vacuum-only mode is reported as unknown.

This prevents automations such as:

vacuum-only cleaning, including carpets; followed by vacuum-and-mop cleaning.

Could this be related to the same cleaning mode filtering logic discussed in this issue?

Can you share capabilities list from vacuum entity attributes?

[Tasshack]

@dmc-gergobakos can you create a different issue about this?