Problem was that the device was running…
@sfrechen @Constantinos_Contis I uploaded the latest build which is suppose to fix the (re-)logon issue you experienced.
thnx ,i will test it asap,link for the new .jar?
@marcel_verpaalen i test the new jar…works perfect.I used a clean 2.5.3 openhabian backup,i removed roborock and my yeelights,removed stable binding and restarted openhab.After reboot added new jar at addons and after configuring my cloud user and pass ,binding discovered all devices with token.Nice work mate.When u ll find a way for a bigger map with less blue background it will be a perfect binding.I ll be here to test it 
I have a lot of xiaomi devices. Most of the wifi devices (yeelights) are configured using China Mainland sever. A few devices, such as roborock s60 and air purifiers are EU models, so these are configured using a second “EU account”. When extracting the tokens myself, this doesn’t matter. How will this scenario work with the latest version of the binding?
Multiple accounts is not supported by the binding.
It does support your devices on the same account being on multiple servers. (e.g. some devices on the CN server and others on the DE server).
Thanks for the feedback. I will obviously have to rethink my setup. If the changes to the binding is merged to 2.5.4, will I be able to use the binding the “old way”, i.e. without linking to an account?
yes, you will be able to continue to use it ‘the old way’
Also you can use the cloud option for one of your accounts, besides having devices that are not linked to it. (or do a quick change between accounts if a new token needs to be retrieved)
What is your usecase to require 2 accounts? You can login with one account to multiple servers as well
The cloud connectivity is merged into the regular OH 2.4-snapshot build since today
1 Like
I set it up like that from the beginning, to have the yeelight app connected to China, and the MiHome app to Europe. I believe there was some issue in the past, that resulted in that setup.
I get this in my logs.
Mi Device model roborock.vacuum.s5 identified as: Mi Robot Vacuum v2 (roborock.vacuum.s5). Matches thingtype miio:vacuum
I also get 2 x things in PaperUI.
Mi Robot Vacuum v2
Xiaomi Robot Vacuum
miio:generic:0706B6E3
and
Xiaomi Mi Device 070B6E3 (117880547) roborock-vacuum-s5_miio117880547
Xiaomi Robot Vacuum
miio:generic:0706B6E3
If I remove both then search for new things, it brings up both things again. If I reboot, the first above shows as offline, until I edit it then save it, then the log message appears and it comes online again.
How do I fix this???
It is a feature… not a bug 
in the mean time RTFM Xiaomi Wifi devices (Mi IO) - Bindings | openHAB
Solution is instead of delete use the hide function in paperUI…
Hi! Updated to openHAB 2.5.4 Build #83
When loading openHAB, a warning is displayed:
2020-04-09 16:09:35.163 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MiIoVacuumHandler of thing miio:vacuum:s50 tried updating channel consumables#consumable_reset although the handler was already disposed.
I have not seen this before. I don’t understand what the problem is.
And I can’t figure out how to download the map. I am using the things file:
Thing miio:vacuum:s50 "Vacuum" @ "Vacuum" [ host="192.168.215.20", token="415474554e4f6b5555555550384b6546", deviceId="0550DD55", model="roborock.vacuum.s5" ]
Need to do something else to load the map?
If you need to specify the country (my robot is attached to China), then how to do this in the file of things?
After restarting openHAB, I do not have a directory:
userdata/miio
Thanks!
The warning may happen if you restart one of the things (e.g. restart of the binding or change of config of a thing). This means it was still communicating while the initiating of the new config is in progress.
It is harmless unless it would be persisting.
For the map download feature you need to set a country in your thing, in your case set it to cn and you need to put in the your cloud logon details in the binding config page. Map is not coming from the device itself, but instead from the cloud, hence the need for cloud logon details.
1 Like
Thanks, I’ll watch.
Sorry, missed this, my English is very bad.
Here is my result:
Is this a good result?
dunno how it looks for you in the MiHome app. It is different from the examples we saw so far for S5.
Can I guess that you don’t have rooms defined? I think all the others had rooms defined, which gives a different color on the inside.
As I worked with only single example file, would not mind to receive a copy of your rrmap file and screenshot of how it looks in the regular app.
Yes! Thanks for the help. As time will be, I will look again!
Fan shows -1 in OpenHAB, clicking to change to say, quiet or Max, changes it for a couple seconds (sometimes) but then it goes back to -1 again. Is this a binding issue or vacuum API issue?
It is a logic in the binding issue indeed.
To convert the value to text it used the standard values from the v1 model, for other models this may not be matching. If it does not find a match it comes back with the -1. Seems these default values differ per model and maybe mihome version.
The numeric fan field is showing the actual value returned from the vacuum which should contain a value between 1->100 for older models and also >100 for newer