very good work! i can’t wait to test your new binding !
After upgraded to 5.5.7_002008 openhab cannot connect to Xiaomi Vacuum. In Paper UI I have:
Status: OFFLINE - COMMUNICATION_ERROR No Response from device
Sorry fixed
I’m using a Roborock S6
if you need some tests…i’ve got time…
how did you fix it? Did you recapture the token? I am facing the same problem since update to 3.5.4_004007 with V1.
thx
Rebooted OH and worked.
Same token
Hi Marcel,
I’ve tested the Cloud connectivity with RoboRock S5 just now, Current firmware version: 3.5.7_002008.
Everything looks OK. All properties got populated, all channels are OK. I never used the old approach with retrieving the token, so I would say this is a great feature for me. 
A suggestion from my side is to maybe move the messages to DEBUG log level.
Cheers,
Konstantin
I am facing a very interesting problem: I wanted to check my token to verify that I did it right. I am not able to access the sql file XXX_mihome.sqlite. The system is requesting a passcode:
other Files in the folder off my iPhone I am able to open e.g. the MiStatDataBase.sqlite file. How can this happen? any Idea?
After pressing cancel, an other Popup with message invalid file format appears, wich is really confusing me.
Kindly,
Woogi
Thanks for confirming
indeed: I’ll do that once more finished. I did most of the code cleanup, but still need to work on the initiation part (making sure multiple requests do not result in mutliple parallel logons as is now possible happening during discovery)
I guess that’s IOS, right? in the android versions we already can’t access the token in he db for some time.
Suggest to try the experimental binding (few topics up) which can get the token from the cloud.
I wonder if this channel miio:generic:0707B93F:consumables#consumable_reset is meant to be used to reset certain consumable back to 100%. Is that the meaning of it?
If this is the usage of this channel, what values need to be send as commands? Is it one of the read channels, i.e. (sensor_dirt_percent, filter_percent, side_brush_percent, main_brush_percent)?
Cheers,
K.
Indeed this is the meaning. It resets the usage back to 100%
I think in paperUI the options are coming up automatically. But see below the values to send.
<channel-type id="consumable_reset">
<item-type>String</item-type>
<label>Reset Consumable</label>
<state>
<options>
<option value="none">Select Consumable</option>
<option value="main_brush_work_time">Reset Mainbrush</option>
<option value="side_brush_work_time">Reset Sidebrush</option>
<option value="filter_work_time">Reset Filter</option>
<option value="sensor_dirty_time">Reset Sensors</option>
</options>
</state>
</channel-type>
Oh. Thanks a lot!
Sorry for the confusion. I use the old school way with config files and items. 
I should have looked into the code XML.
Hi,
I’m not sure if it’s a user handling issue or it’s a bug in the discovery but after initial discovery I renamed the discovered thing to a more meaningful name for myself…
Now it appears again in my inbox.
Maybe you could do a filtering based on serial number or something, i.e. if serial number exists in a thing probably treat it as already discovered… (not sure if it’s a good approach just suggesting without knowing the code…)
Cheers,
Konstantin
it is a feature…
see Xiaomi Wifi devices (Mi IO) - Bindings | openHAB
The binding has 2 methods for discovering devices. Depending on your network setup and the device model, your device may be discovered by one or both methods. If both methods discover your device, 2 discovery results may be in your inbox for the same device.
The mDNS discovery method will discover your device type, but will not discover a (required) token. The basic discovery will not discovery the type, but will discover a token for models that support it. Accept only one of the 2 discovery results, the alternate one can further be ignored.
Unfortunately there is no easy way that this can be avoided until further improvement of the OH framework for mDNS discovery
1 Like
new version of the alpha version with cloud connection is available.
Fixes/new functionality
5 Likes
Hi Marcel,
Map now works for me on S5.
Thank you !
Are there any potential performance-related constraints for the map that you’re aware of? I guess it’s not harmful in any way for OH or the Xiaomi, right?
Hi Marcel
I have tried the new alpha binding (25 march), I have the new S4 model, it recognizes the model but there are virtually no channels, so I applied it manually and changed the vacuum model to an S6 and then all the channels showed up.
Everything seems to work except the map I get this.
And in the miilo folder, the map files look like Adobe Acrobat document?
Thank you for your amazing contribution 
@polychronov don’t think so. The mihome app requests this map almost every few seconds. We do it typically each 30 sec…
@Anders_Saederup I think indeed your map is yet another version.
Can you send the exact model string you are getting (before you updated it) and a few examples of those map files (I guess your system shows them as the adobe files) and a screenshot of your mihome app map to get an idea of how the map is suppose to look like