Mop pads spinning on the docking station.

[taszlan]

When dreame-vacuum is active the mop pads of my Mova P10 Pro Ultra keep spinning (intermittent, very short move every couple of ceconds producing a "ticking" noise) while the robot is on the docking station.
Disabling the integration fixes the issue.

[Tasshack]

I highly doubt that integration is capable of doing something like that. I have you tried rebooting the robot?

[taszlan]

IMG_5628.mov

I just tested again. 5-10 minutes after enabling the „P10 Pro Ultra” device the mops start spinning. The mops stop immediately after disabling the device.

[Tasshack]

This is very interesting, can you enable debug logs and share so i can see what integration actually sends to the device?

[taszlan]

home-assistant_2026-05-24T12-46-18.186Z.log

[Tasshack]

I have checked the logs but integration wasn't actively sending commands to the vacuum that may cause this. Perhaps it is because requesting a property that does not exists on your device firmware which the integration does everty time at start. Only thing I can do at this point is commenting out some code and share it to you for testing but I don't have time to do that right now.
This project is four years old and have been using by more than 50k devices but you are the only one having this issue so it is very hard for me to fix that only you can repoduce.

[taszlan]

Sure thing, I was afraid that it might be my vacuum being wonky.

[J3n50m4t]

Reading this - my mova E30 does exact the same thing. I thought its normal. I disabled the integration and it stops.
I don't mind - its fine for years now.

[Parley33]

IMG_5628.mov
I just tested again. 5-10 minutes after enabling the „P10 Pro Ultra” device the mops start spinning. The mops stop immediately after disabling the device.

My Mova P10 Pro Ultra does exactly the same thing.

[maximkatut]

My Mova p10 pro ultra does same thing as well

[Parley33]

Just adding my confirmation – my Mova P10 Pro Ultra does exactly the same thing. The mops tick and micro-rotate as long as the polling is active.

@Tasshack - your theory seems to be 100% correct. It appears that when the integration polls for state updates, it requests a specific property (or properties) that the Mova firmware handles poorly. Instead of just returning a value or ignoring an unsupported property, the robot's base station MCU wakes up and triggers the mop motors with every incoming request.

Since multiple users with Mova devices (P10 Pro Ultra, E30) are now confirming this, it's definitely a consistent firmware quirk for this sub-brand.

I understand you are short on time and don't have the hardware to reproduce this. However, if you could just comment out the suspected properties in the polling loop and share the modified files (or a zip of the custom_components/dreame_vacuum folder), I am ready to test it on my end immediately. I can upload it to my HA, monitor the base station, and provide you with feedback and debug logs to help you pinpoint exactly which property is causing the hardware to wake up.

[Tasshack]

@Parley33 the thing is, integration does not poll anything periodically (while the device is on idle), it relies on MQTT messages to get the updates instead.
The only thing the integration periodically request is the KEEP_ALIVE property but I don't think that is actual cause of the issue.

Integration also requests all implemented properties in types.py only once during initialization, stores the properties does not exists in response and never requests those properties again until next initialization.

I think requesting some property that is not in the firmware followed by keep alive update is causing the issue.
There are more than 350 implemented properties scattered all over the integration so I cannot just comment out some of them and send a version for testing without breaking an other part of the integration.

You can easily try installing older versions of the integration sequentially and try to find a version that does not have this issue so that I can compare the changes and make a much accurate assumption for the cause. (KEEP_ALIVE have been added on v2.0.0b22 to fix this issue)