Xiaomi Robot Vacuum Binding

Hi,

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!

HI
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 - #1432 by kovaga

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

ok - I did and will monitor.

for now I can say that the “old” threads that were created by the 2.5.4 are NOT gone after uninstall and dropping the jar.
So most likely a restart of openhab is needed to get rid of those.

Yes indeed, if the device did not respond, they were opened and never closed.
OH restart is the only way to close them

I think this has been fixed in 2.5.6 stable that is about to be released today.

is the scaling interface included in 2.5.5 stable binding?

No it is not… currently the only way to change is to change the scale and recompile yourself
Here is the scale: