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.
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.
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:
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…
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.
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:
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.
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.
First I want to thank you for this great binding, now here comes the questions:
Is there a way to configure the binding username and password through config files rather than paperui?
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.
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?
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 :
