Roborock integration cannot distinguish "Charging + will resume cleaning" vs "Charging after finished job"

[artem-zinnatullin]

The problem

Hi team,

I used to rely on Roborock integration by @humbertogontijo in which I was able to override a very annoying default behavior of the Robot:

When Robot runs out of battery during cleaning it comes back to dock to charge to 80% which takes hours and then resumes when we're already at home and don't want to hear it running.

I was able to check the "In cleaning" attribute and if Robot is "Docker" and "In cleaning" > 0 it means that it is charging but will resume later. If that's the case and battery reaches > 40% and we're not home I then send command to Resume cleaning basically making the robot charge to my set value and resume much sooner than it would have happened by default.

(this used to work with [humbertogontijo/homeassistant-roborock](https://github.com/humbertogontijo/homeassistant-roborock))

Now with the official Roborock integration in the HA core I cannot seem to find a way to distinguish when the robot is charging and will resume vs just charging after finished job.

What's worse, we now constantly get into state where Robot continues cleaning on its own after reaching 80% when we're at home like in the middle of a dinner and don't want to hear it running. The only Automation I can write for this is to force stop the cleaning while it's docked and we come home or intercept the Robot after it resumes cleaning which takes almost a minute do detect.

I've debugged integration status and see these values in both cases of charging:

• State: vacuum.roborock_s7 docked
• State: sensor.roborock_s7_status charging

What version of Home Assistant Core has the issue?

core-2023.10.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Roborock

Link to integration documentation on our website

https://www.home-assistant.io/integrations/roborock

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

Since https://github.com/humbertogontijo/homeassistant-roborock had that info — it must be available to the integration, would be great to expose it!

[home-assistant]

Hey there @humbertogontijo, @Lash-L, mind taking a look at this issue as it has been labeled with an integration (roborock) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of roborock can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign roborock Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

roborock documentation
roborock source
_{^{(message by IssueLinks)}}

[Lash-L]

Gotcha - so if I understand you correctly, you used one of the extra state attributes that was not a entity in order to check if it was still in a cleaning while it was recharging?

Easy enough for me to fix - I don't expose the extra state attributes like we do in the custom integration in core, but I could just create a binary sensor for in cleaning? Would that resolve your problem?

[artem-zinnatullin]

Hey @Lash-L! If you think it's easy to expose those extra attributes — then I'd say all of them should be exposed as long as you deem them ok for stable API!

I'm sure people will come up with all sorts of useful automations based on attributes no one has though of using before :)

---

but I could just create a binary sensor for in cleaning? Would that resolve your problem?

If that "in cleaning" attribute will be true when Robot is docked because battery got low -> charging & will auto-resume — then yes, it's the exact attribute I'm looking for!

I'm happy to create a community forum topic about it once you include it and I test that it works, I'm sure this use-case I've described in the issue bothers a lot of people and it'll be awesome to provide a way to fix it for many.

---

Thank you for being a really responsive maintainer, you're improving many homes around the world with your work 🤝

[Lash-L]

Hey @Lash-L! If you think it's easy to expose those extra attributes — then I'd say all of them should be exposed as long as you deem them ok for stable API!

My understanding is that the core devs don't really like things being state attributes unless they can't be represented as an entity. I could potentially post all possible state attributes on the forum and let users tell me which they would want as an entity

[mindgam3s]

this is exactly what we need!
thank you guys so much.

Is there an ETA on when the change gets into a release ?

[Lash-L]

this is exactly what we need! thank you guys so much.

Is there an ETA on when the change gets into a release ?

If you're on the latest version - you should have a 'cleaning' binary sensor under diagnostic

[mindgam3s]

this is exactly what we need! thank you guys so much.
Is there an ETA on when the change gets into a release ?

If you're on the latest version - you should have a 'cleaning' binary sensor under diagnostic

thanks! didn't realize that :D

sadly the sensors now have about 30 seconds delay when updating ...
so state-changes are reported with 30 secs delay and therefore break my automations from time to time