Xiaomi Robot Vacuum Binding

I also started to get errors for my Roborock S5 in 2.5.4

[WARN ] [nal.transport.MiIoAsyncCommunication] - Error while polling/sending message
java.lang.ArrayIndexOutOfBoundsException: null
	at java.lang.System.arraycopy(Native Method) ~[?:1.8.0_242]
	at org.openhab.binding.miio.internal.MiIoCrypto.iv(MiIoCrypto.java:52) ~[bundleFile:?]
	at org.openhab.binding.miio.internal.MiIoCrypto.encrypt(MiIoCrypto.java:74) ~[bundleFile:?]
	at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendCommand(MiIoAsyncCommunication.java:257) ~[bundleFile:?]
	at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendMiIoSendCommand(MiIoAsyncCommunication.java:173) ~[bundleFile:?]
	at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:232) [bundleFile:?]

In my case my S5 vacuum is not connected to the cloud and was never connected to it. I use it with valetudo. Can this cloud polling be disabled?

EDIT: Actually solved it myself. Edited things file and changed token as @kovaga suggested.

A log line appeared:

[INFO ] [g.miio.internal.cloud.CloudConnector] - No Xiaomi cloud credentials. Cloud connectivity disabled

Most probably it is enabled by default.

No… it just a message which is information that indeed the cloud login userId/password are not there, hence the binding is behaving as before without cloud related functionality (tokens/map).

In the latest snapshot this is changed to a debug message instead of info message, so you won’t see it anymore in the reglar log settings.

No. I mean this message started to appear periodically only when I made a change in the things file. Previously it shot Error while polling/sending message instead.

Marcel, can you please point me to the download link of the miio 2.5.5 jar

Same vacuum here (1S). I had some problems changing to the cloud service but after several attempts of deleting the Thing and readding it and restarting openHAB it finally worked:

Binding version:

261 x Active x 80 x x openHAB Add-ons :: Bundles :: Xiaomi Mi IO Binding

Debug log:


is anybody else getting a lot of threads stuck in TIMED_WAITING? I have the same issue as described here:

On a rpi3b+ with OH 2.5.4. - i have one Roborock S50 connected and my number of Threads exceeded 4000…
I tried clearing the cache and will see what’ll happen…

is there a way to make map bigger?At my 7" tablet i cant see anything… being longsighted cause i am an old guy ,doesnt help at all :slight_smile:

I was hoping/expecting this would be solved in from 2.5.4. before it could happen in case of connectivity issues, or on case of incomplete/wrong thing definition.

If you experience this, pls make a debug log for buy of longer time to see what is causing the restarting of the receiver thread.

It is prepared to allow for scaling, just did not make a field in the interface to set it. I may add that in a future release

Thanks for your quick reply! Something might be wrong with my installation, when I trigger actions and run the roborock, cpu load kept increasing rapidly.
I have reinstalled the binding and now we’ll see what happens. I keep you posted!

Hello marcel, thanks for the fast answer!
Uninstalled 2.5.4 binding via Paper UI. Added the 2.5.5. version to the addon-folder /usr/share/openhab2/addons and re-booted.

Recieved the following log:

2020-05-10 22:26:43.933 [INFO ] [g.miio.internal.cloud.CloudConnector] - Getting vacuum map rubyslite%2F261631712%2F0 from Xiaomi cloud server: de

2020-05-10 22:26:45.904 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:

java.lang.Error: Probable fatal error:No fonts found.

at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) ~[?:1.8.0_232]

at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1106) ~[?:1.8.0_232]

at sun.font.CompositeFont.doDeferredInitialisation(CompositeFont.java:287) ~[?:1.8.0_232]

at sun.font.CompositeFont.getSlotFont(CompositeFont.java:376) ~[?:1.8.0_232]

at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:82) ~[?:1.8.0_232]

at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:97) ~[?:1.8.0_232]

at sun.font.FontDesignMetrics.initMatrixAndMetrics(FontDesignMetrics.java:359) ~[?:1.8.0_232]

at sun.font.FontDesignMetrics.<init>(FontDesignMetrics.java:350) ~[?:1.8.0_232]

at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:302) ~[?:1.8.0_232]

at sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:855) ~[?:1.8.0_232]

at org.openhab.binding.miio.internal.robot.RRMapDraw.drawOpenHabRocks(RRMapDraw.java:345) ~[?:?]

at org.openhab.binding.miio.internal.robot.RRMapDraw.getImage(RRMapDraw.java:414) ~[?:?]

at org.openhab.binding.miio.internal.handler.MiIoVacuumHandler.getMap(MiIoVacuumHandler.java:478) ~[?:?]

at org.openhab.binding.miio.internal.handler.MiIoVacuumHandler.lambda$5(MiIoVacuumHandler.java:451) ~[?:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_232]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_232]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_232]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_232]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]

Is the old binding still somehow “working”?

In the folder /srv/openhab2-userdata/miio there is only the token-file, no map-files.
I am running on Openhabian.

Hallo Sebasian,

Either download the one in post Xiaomi Robot Vacuum Binding (if you use this, please send me a debug log file so the issue can be better understood)
or disable the map channel & Cloud functionality (=no userId/password), which will make it behave as before the new functionality was introduced.

Hi Marcel,

a cache clean and reinstall fixed the issue, just to let you know!

Thanks for the great work!

I saw the icon of vacum, but cannot find now, can somaone share ?

First I want to thank you for this great binding, now here comes the questions:

  1. Is there a way to configure the binding username and password through config files rather than paperui?
  2. EDIT: Why am I sometimes getting duplicated commands when clicking a switch:

2020-05-13 18:18:52.298 [nt.ItemStatePredictedEvent] - MiPowerPlugPower predicted to become OFF
2020-05-13 18:18:52.336 [vent.ItemStateChangedEvent] - MiPowerPlugPower changed from ON to OFF
2020-05-13 18:18:53.672 [vent.ItemStateChangedEvent] - MiPowerPlugPower changed from OFF to ON
2020-05-13 18:19:06.899 [vent.ItemStateChangedEvent] - MiPowerPlugPower changed from ON to OFF

This makes the switch on the basic ui pannel to “flicker” when I click on it.

  1. Can I pair this plug directly to OpenHAB without the Xiaomi App? As currently I can’t discover it as a thing in PaperUI if I don’t have it paired on my phone with the Xiaomi App. EDIT: I guess not, as I saw the switch needs to be connected to WiFi first, and the only way to do that is through the Xiaomi App, correct?

yes, that is possible. Please see this post: Xiaomi Robot Vacuum Binding

This may happen if there are still unprocessed commands in the queue for the device. So if your device still has a properties refresh in the queue, executing that will cause the UI to switch back (the plug did not yet receive the command you executed), after that the command is executed, changing the switch state, the following refresh will update the UI to the new state that you were expecting.

Note that some of the powerplugs have rather poor wifi causing lot of connection losses and delayed execution. I’ve seen similar behavior indeed with my plug.

and indeed… there little possibility to connect without first using Xiaomi app.
(in theory you can, but you need to connect to your plug’s wifi, you could control it that way. If you are ready to experiment you can issue the commands to change the wifi settings and hope that the binding cloud connectivity picks up the new token… note: untested territory but probably possible)

Hi @marcel_verpaalen
I am on latest stable where the binding does discover the token in its own.
Since then I have the issue that it eats threads like hell. (Mi IO MessageSenderThread: TIMED_WAITING)

I was firstly thinking it was related to another binding. Therefore the info is here :

Zigbee Channel?

Are you using the released version, would you mind trying the 2.5.5 snapshot version as at least one cause of the leaking threads has been fixed.

can i uninstall and reinstall on 2.5.4. stable or do I need to drop the jar to get it?

I think you best uninstall the 2.5.4 one and then drop the 2.5.5 one in the add-on folder

I think few topics up I looked up the download link