Well, was a bit too early to celebrate…
After having Roborock online for some time (thus also having retrieved correct DeviceID), the connection dropped to offline. And now I am not able to re-connect, even though deleting thing / reinstalling binding etc, now using both IP, token, deviceid and device model as input for manual install in PaperUI. The Roborock remains OFFLINE.
Make sure you don’t have the 2 things (1from config file and 1from paperui ) at the same time.
That will make the device will refuse the connection.
So either make the thing from file (using the correct deviceId) or from paperui
To answer my own question: yes, the 1S works fine with this binding.
It is autodiscovered as miio:generic and you need to manually add a thing as miio:vacuum and use the deive model rockrobo-vacuum-v1. After providing the token all channels are available.
@marcel_verpaalen, thank you very much for this amazing binding 
Would it make sense to add the roborock.vacuum.m1s to the thingtype vacuum?
Yes, I am aware.
Have tried to delete .things file, have deleted thing in PaperUI followed by restart OH servce / deleting cache and *tmp files and uninstalling PaperUI binding.
However, still, re-installing binding / maunally installing PaperUI thing, I continue to get Offline_Communication_Error.
I actually can’t get this to work. @Flole can you think of any reason why the coordinates wouldn’t be copied to the clipboard?
Edit: Wrong quote in the original draft…
Hi,
i used this binding to integrate my roborock s5 into openhab since version 2.4.0 and it was working perfectly. Now i wanted to update to openhab 2.5.0.M4 but cannot get the roborock-items to work. The log does not show any errors for the binding. Are there any known bugs or breaking changes in the config in combination with the latest milestone?
Yes, it definitely does make sense. My dev environment is broken, need to rebuild it.
Than I can add this. (or feel free to submit a PR 
) It should be as easy as modify the thingtype from unsupported to vacuum indeed.
How can I obtain the tokens now?
The old android app doesn’t seem to work properly now. It doesn’t load the devices.
Also on the newest iOS app I was unable to extract readable data
Ps.: Now the tokens are also stored encrypted in iOS also. So you need to decrypt it to get it working.
I used this Russian app on Android:
https://www.smarthomeassistent.de/token-auslesen-roborock-s6-roborock-s5-xiaomi-mi-robot-xiaowa/ (sorry, German only)
Short version on how to do it:
Uninstall the Mi Home app
Install the Russian app
Set the correct location
Read the token
Thanks that’s good to know.
There is a good tutorial on YouTube how I done it on iOS:
Basically:
First of all thanks a lot for this Binding - it is amazing and works perfectly at my place! 
However, I tried to do the same setup at a friends place - sadly without any luck.
I am always getting a Offline - CONFIGURATION_ERROR state after adding the robot to OpenHab 2.4.0.
The token extraction went smoothly with the methods proposed in this thread. The Thing is also discovered by the Binding. Initially, the Thing has an Online state and seems working. However, after a short time I am seeing in the logs:
2019-10-26 11:27:26.948 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Communication error for Mi device at 192.168.2.116: Receive timed out
2019-10-26 11:27:26.952 [DEBUG] [nal.transport.MiIoAsyncCommunication] - No response from device xxx at 192.168.2.116 for command {"id":52,"method":"miIO.info","params":[]}.
2019-10-26 11:27:26.955 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping xxx (192.168.2.116)
2019-10-26 11:27:26.965 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping xxx (192.168.2.116) success
2019-10-26 11:27:26.971 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for xxx type: MIIO_INFO, result: null, fullresponse: {"error":"No Response"}
2019-10-26 11:27:26.974 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Error received: "No Response"
I repeated the setup several times (each time resetting the robot’s wifi and extracting a new token), but it always converges towards Offline - CONFIGURATION_ERROR state.
At the same time, the XiaoMi App is working properly with the robot - so I am assuming that the robot is connected properly to the router and that this might not be a network issue.
Do you have any idea what I am doing wrong?
Cheers,
Karl
Hi,
Today I received the Yeelight Meteorite LED lamp.
I am running 2.5M4 on x86.
The binding identifies it as yeelink.light.ceiling10 - and since this lamp is not included in the binding as of yet, the Thing is marked as " Unknown Mi IO Device/Unsupported Xiaomi Mi Device" and I only get the “on/off” and “execute command” items.
Trying the “Execute command” using the commands in yeelink.light.ceiling4.json it works as intended. I also tried the lamp with a direct telnet session, and can verify the commands from there as well (as per the Yeelight Inter Operation Specification").
Changing the “Device Model String” for the Thing in Paper UI from yeelink.light.ceiling10 to yeelink.light.ceiling4 does not give me any more Items, @marcel_verpaalen, is there anything I can do to get the items displayed. I belive there should be a duplicate entry in the database for the .ceiling10 that is identical to the .ceiling4 json.
Best regards /Daniel
@Daniel_Linder delete your things and manually add it as a basic device.
Change the model in the config (as you did ) to the yeelink.light.ceiling4
that should give you all the channels.
If it works than we can add yeelink.light.ceiling10 to the file as well and it detect it automatically
@fishi0x01 that is indeed somewhat unuasual.
the only thing that comes to my mind:
@marcel_verpaalen If I manually configure the thing as
Thing miio:basic:light "Yeelight Meteorite" [host="192.168.1.195",token="2a311f11e99d0f66c1669743ed3cec3e",deviceId="07606718" ]
I get an “online” thing, however without any items (the auto discovered thing has “on/off” and “command” items.) If I change the device model string (yeelink.light.ceiling10) in paper UI, I get the message “Error 409 conflict” and it automatically goes back to yeelink.light.ceiling10. I also get a duplicate thing autodiscovered in the inbox, even if I have manually set the thing.
I am out of ideas what to do… any suggestions?
add the modelId in the definition, somethink like this. (as I’m not sure if you can have a text definition and than do additional updates via paperUI. Alternative is to add the thing via paperUI without text config)
Thing miio:basic:light "Yeelight Meteorite" [host="192.168.1.195",token="2a311f11e99d0f66c1669743ed3cec3e",deviceId="07606718" , model="yeelink.light.ceiling4"]
Hi again,
Thanks for the hints. After some (a lot) trial and error, it was a sucess. However, the thing definition must look exactly like this for it to work for me.
Thing miio:basic:07606718 "Yeelight Meteorite" [ host="192.168.1.195", token="a190d29e81034b03bb0634194f1aa1fd", deviceId="07606718", model="yeelink.light.ceiling4"]
However, as mentioned - it works perfectly fine with the model “yeelink.light.ceiling4” model data. So if “.ceiling10” could be added to the database, it would be a good thing.
Many thanks /Daniel
Hi @marcel_verpaalen !
Established a binding in a test environment, connected six bulbs and a vacuum cleaner.
At first glance, everything is fine, only informational messages in the logs are worried.
My lamps in the process of operation are controlled (brightness, temperature, color) openHUB, and turning on and off through a physical switch.
Each time, when the switch is turned on, in the log I see the following entries:
2019-10-31 17:23:10.964 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:0332CD19' to inbox.
2019-10-31 17:23:10.969 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:0335C499' to inbox.
2019-10-31 17:23:10.974 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:0335E030' to inbox.
2019-10-31 17:23:10.982 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:03360ED4' to inbox.
2019-10-31 17:23:10.988 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:0335C161' to inbox.
2019-10-31 17:23:10.991 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'miio:basic:0335FA38' to inbox.
When I reboot the openHAB, I see the following entries in the log file:
2019-10-31 17:00:34.142 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.color1 identified as: Yeelight Color Bulb (yeelink.light.color1). Matches thingtype miio:basic
2019-10-31 17:00:43.857 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.mono1 identified as: Yeelight White Bulb (yeelink.light.mono1). Matches thingtype miio:basic
2019-10-31 17:00:44.032 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model roborock.vacuum.s5 identified as: Mi Robot Vacuum v2 (roborock.vacuum.s5). Matches thingtype miio:vacuum
2019-10-31 17:00:44.213 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.mono1 identified as: Yeelight White Bulb (yeelink.light.mono1). Matches thingtype miio:basic
2019-10-31 17:00:44.250 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.color1 identified as: Yeelight Color Bulb (yeelink.light.color1). Matches thingtype miio:basic
2019-10-31 17:00:44.254 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.color1 identified as: Yeelight Color Bulb (yeelink.light.color1). Matches thingtype miio:basic
2019-10-31 17:00:44.287 [INFO ] [internal.handler.MiIoAbstractHandler] - Mi Device model yeelink.light.mono1 identified as: Yeelight White Bulb (yeelink.light.mono1). Matches thingtype miio:basic
This is in a test environment, with six lamps, and when there will be much more.
Thing miio:basic:white1 "White-01" @ "yee" [ host="192.168.215.51", token="60e7704d26b31a2a464f70dbdd7923c9", deviceId="03360ED4", model="yeelink.light.mono1" ]
Thing miio:basic:white2 "White-02" @ "yee" [ host="192.168.215.52", token="227a8ae518f2a31d15a6cb23bcacad0a", deviceId="0335FA38", model="yeelink.light.mono1" ]
Thing miio:basic:white3 "White-03" @ "yee" [ host="192.168.215.53", token="8e2fc37223bacafbba59888022733e13", deviceId="0332CD19", model="yeelink.light.mono1" ]
Thing miio:basic:color1 "Color-01" @ "yee" [ host="192.168.215.54", token="6670885c6ad5c4a4916623b3e1e4549c", deviceId="0335C499", model="yeelink.light.color1" ]
Thing miio:basic:color2 "Color-02" @ "yee" [ host="192.168.215.55", token="e1f60a1be0b9a28ae06e652021da342b", deviceId="0335C161", model="yeelink.light.color1" ]
Thing miio:basic:color3 "Color-03" @ "yee" [ host="192.168.215.56", token="9c803711bcf4f2e2f770e0993b209e32", deviceId="0335E030", model="yeelink.light.color1" ]
For me, this is a lot of redundant and unnecessary information that prevents me from analyzing log files.
Tell me, did I configure something incorrectly?
How to make sure that this information is not displayed in the info log, but is displayed, for example, in the debug log?
The binding is great! Thank you for your work, I watched the topic from the first day, you spent a lot of time, skill and patience and this is not the end