Roborock binding for robot vacuum cleaners [4.0.0; 5.0.0]

Add-on Marketplace Bundles
, ,
1

logo

OpenHAB binding for the Roborock range of vacuum cleaners. Some of these are supported by the MiIo binding, but newer models use a different protocol. Tested with a Qrevo S, S6 Pure and S7.

This binding used a bridge to login to the Roborock servers, and then the ‘Scan’ button can be used to detect installed vacuum cleaners.

All channels from the MiIo binding are working with the exception of Map image support. The link channel has also been removed as there appears to be no data to support it.

Not all commands have been tested, but they should work.

Changelog

Version 0.3.0, 20th July (git a26b950)

  • revert mqtt reconnection code, caused mqtt flooding and disconenction of bots from wifi

Version 0.2.9, 14th July (git 17006e4)

  • code cleanups
  • log last mqtt publish and message received timestamps, if messages stop being received, kill mqtt connection and reconnect.

Version 0.2.8, 9th July (git 336b059)

  • Use OH Storage api to store credentials, rather than creating a file
  • move to mqtt v5 rather than mqtt v3
  • various other changes/tidy ups I can’t remember.

Version 0.2.7, 7th July 2025 (git 8c7b082)

  • Remove semantic-equipment-tag markers to fix OH4.2 compatability.

Version 0.2.6, 6th July 2025 PM update (git 6b933cf)

  • get correct URL by querying roborock api with email address
  • remove config parameter for region

Version 0.2.5 6th July, 2025 (git aa53c55)

Version 0.2.4 5th July, 2025 (git 004d790)

  • Fix starting a routine
  • Ignore more MQTT messages we don’t use/handle
  • Improve tracking of which message IDs have been handled
  • Code simplifications

Version 0.2.3 - 4th July, 2025 (git 2b53920)

  • More work to improve reliability of MQTT message processing
  • Add channels for Routines (works in similar manner to Room Mapping).

Version 0.2.2 - 3rd July, 2025 (git 5487de2)

  • Fix another mqtt packet handling issue

Version 0.2.1 (git ac46547)

  • Fixed bug preventing mqtt updates

Version 0.2 (git 90fbfed)

  • Refactor mqtt connections into the Account Handler, so that even with multiple vacuums, there is only a single mqtt connection
  • Fix bug updating state
  • Fix ‘dock’ command

Version 0.1.2 (git f68c2e0)

  • Fix last cleaning record on my Roborock S6

Version 0.1.1 (git 5a95066)

  • Fix some channels not updating with older vacuums (like S6). Last Cleaning Record channels are still broken for now. History record is not being returned for unknown reasons.

Version 0.1 (git de4d10b)

  • Initial release

To-Do

More testing with different models

Resources

https://smedley.id.au/tmp/org.openhab.binding.roborock-5.0.0-SNAPSHOT- a26b950.jar

6 Likes
2

OK I moved my S6 from MiIo to Roborock and I’m happy to say that running 2x vacuums seems to work fine :slight_smile:

There are some differences in the types of output received. Working through those now and will have a refreshed release at some point soon. Commands work OK, but not all channels are updating on the S6.

1 Like
3

Awesome! Now to decide if I should or not…. @Paul_Smedley do you think that the items would still be compatible the the widget I linked ?

4

They should be. It’s easy enough to test - reset wifi on the vac - connect with roborock app instead of Mi Home, and add to OpenHAB. Channel names are the same as MiIo it’s just how they’re populated. One thing I’ve noticed with my S6 I couldn’t name the rooms on the map with MiIo, but I can with the Roborock App.

btw the python code to decode maps is at python-roborock/roborock/version_1_apis/roborock_client_v1.py at 148a6faa5c37ce619e5749da78be507e50e2b890 · Python-roborock/python-roborock · GitHub - it’s hurting my head.

Code needs to be added at openhab-addons/bundles/org.openhab.binding.roborock/src/main/java/org/openhab/binding/roborock/internal/util/ProtocolUtils.java at roborock · psmedley/openhab-addons · GitHub

1 Like
5

I had some problems starting multiple vacuums in short succession today. I figure that’s a good reason to move the MQTT connectivity to the Account handler so we’re only connecting to roborock’s once rather than 3 times.

I just got this (seemingly) running, will do some more testing to make sure channels are refreshing before I upload it.

Edit: I broke message handling, I’ll fix it tomorrow.

Edit 30/6: Fixes message handling, build updated. Has anyone else been able to test yet?

6

I got routines working :slight_smile: they work in a similar manner to room cleaning. There is a string channel which retrieves the id and routine name from the Roborock API; then another channel to send the Routine ID to Roborock. This isn’t yet uploaded.

Has anyone else been able to test yet?

7

Haven’t been able to just yet, but I’ll get around to it soon!

8

Fixed a bug where it only worked with US accounts, added a configuration parameter for the region (ie US, EU, CN, RU)

Afternoon update 6th July - worked out how to detect region, link updated in Post 1.

9

I tried to install the binding on 4.3.5 and get the following warning.

Summary

WARN org.openhab.core.config.core.xml.osgi.XmlDocumentBundleTracker The XML document ‘/OH-INF/thing/thing-types.xml’ in module ‘org.openhab.binding.roborock’ could not be parsed: ---- Debugging information ---- cause-exception : com.thoughtworks.xstream.mapper.CannotResolveClassException cause-message : semantic-equipment-tag class : java.util.ArrayList required-type : java.util.ArrayList converter-type : com.thoughtworks.xstream.converters.collections.CollectionConverter path : /thing-descriptions/bridge-type/semantic-equipment-tag line number : 10 class[1] : org.openhab.core.thing.xml.internal.BridgeTypeXmlResult required-type[1] : org.openhab.core.thing.xml.internal.BridgeTypeXmlResult converter-type[1] : org.openhab.core.thing.xml.internal.BridgeTypeConverter class[2] : org.openhab.core.thing.xml.internal.ThingDescriptionList required-type[2] : org.openhab.core.thing.xml.internal.ThingDescriptionList converter-type[2] : org.openhab.core.thing.xml.internal.ThingDescriptionConverter version : 1.4.21 -------------------------------

On 5.0.0.M3 im able to create both things

10

Thanks for testing. Tomorrow morning I’ll remove the tag that 4.3 doesn’t like.

Removed the entries and will upload a new build shortly.

11

I still see some occurences where the MQTT server stops sending packets. Commands are sent (seemingly with no error), but no responses are received. I’ve changed things from mqtt3 to mqtt5 and also added the automaticReconnectWithDefaultConfig() flag to the mqtt connect.

Will see how long it lasts now before needing to be restarted :slight_smile:

NB: the above changes aren’t committed yet.

Update: I broke some things and whilst I think I’ve now fixed them, my vacs are now being reported by the API as being offline (even though my router says they’re online). The app also reports them as offline. I’m currently away from home, so if they don’t come back online, I’ll investigate tomorrow when I get home.

1 Like
12

OK things are working again. I reworked things so that instead of saving the login details to a file, we use the openHAB Storage API to save them.

Uploading a new build shortly.

I’m still not sure what happened with the connection of my vacs. The wifi light on them was flashing so I did reconnect them to wifi. All seems OK now. I also noticed that last night, my firewall had blocked one the vacs from accessing the roborock mqtt server

2 Likes
13

Build updated seems to ‘fix’ MQTT messages which stop being received. I’m recorded the timestamp of the last publish, and the last message received. If 5 minutes after a publish, there have been no messages received, we disconnect/reconnect the mqtt connection.

14

Thank you Paul for this binding!
I have just installed it (version 0.2.9) and connected my S7 MaxV. So far everything is working fine.
I will report back if I find any issues.

Thanks again,
Matt

15

Thanks for testing!!! There is still some tuning required to the mqtt reconnection code

1 Like
16

hi,
i’ve tested wrong loging details for the Roborock bridge. This thing shows still online, not error config or else. I will test more, if im back at home at friday and report

Edit:

I’m having the same problem now. Could this be related to deleting the SSID item?

17

I don’t fully understand the mechanics of this failure to connect to wifi, but it’s definitely some kind of anti DDoS measure by roborock.

Periodically, the roborock mqtt server disconnects. A week or so I added code to reconnect automatically, but sometimes the server disconnects immediately, so we reconnect. This can result in the binding spamming roborock servers. Some time later,roborock somehow disconnects the vacs from wifi, and they need to be manually reconnected.

I made some further (unreleased) changes last night to slow down the mqtt reconnect in the hope it will help things.

Meanwhile, I’m starting to investigate local control using the bots IP address.

1 Like
18

Just on the MQTT messages not being received. It’s definitely a weird one. Publishing commands still works, even with no messages being received/processes by the binding. So a mqtt connection is still there. I’ve backed out my reconnection code.

Capturing some logs right now, and I’ll try work out where things are getting stuck, it’s possible there is still an unexpected/errant json format that is screwing things up.

Edit: logs didn’t reveal too much. I’ve reworked code to subscribe to each vacuum’s specific topic rather than using a wildcard (#). Will see what happens overnight.

19

Every time I connect our vacuum cleaner to openHAB, it loses the Wi-Fi connection. Occasionally, openHAB also crashes, and nothing works anymore.

Openhab Version ist 4.3.5

20

The wifi connection is caused my excessive mqtt retries, I’ll upload a new build soon which backs out some of those changes. I’ve had no OH stability issues since running this.

Edit: more stable build uploaded that shouldn’t trigger mqtt reconnections and roborock blocking robots. Updates still stop being received after some time :frowning: