@Daniel_Linder I think each time you include it it creates a new token… there is no ‘master token’ i’m aware of.
As each time you include it the token is chaging, this is also the reason why it doen’t work in both apps.
This is an awesome binding; only challenge I had was to find all information at one place; therefore let me summarize the way i did the installation:
With update to oh2.2 all the necessary steps work out of the box as follows:
- Addons-Misc: Eclipse IoT Market
- Addons-Bindings: Openhab Xiaomi Mi IO Binding
Add xiaomi.things
Thing miio:vacuum:xxxxxxxx "Xiaomi Robot Vaccum Cleaner" @ "Kitchen" [ host="192.168.x.x", token="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ]
All the “x” need to replaced by your settings
Add item and sitemap as shown at beginning of this thread
In item file: Replace following channel information:
channel="miio:generic:034F0E45
with your device informaiton
e.g. channel="miio:vacuum:046BC24A
The token of my vacuum cleaner I retrieved via following steps:
Get Token
Only challenge i faced: iBackup does not allow to export token without registering; therefore I used iBackupBot instead:
http://www.icopybot.com/itunes-backup-manager.htm
After backup is loaded, klick on “Apps” at bottom
Use search function and do a search “Xiaomi”
Klick on: xom.xiaomi.mihome -> Documents -> 17465…mihome.sqlite
RichtClick: Export file
Now install http://sqlitebrowser.org/ and execute DB Browser for sQLite
Goto ZDEVICE
Search for data
ZLOCALIP 192.168.2.15
ZMAC 78:11:DC:7D:83:DC
ZTOKEN 8f4efd91194114a614a9da9e41d88f6293bb07adbxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxb0cdff9f69917680151e
Convert crypted token into 32 hext token with:
http://aes.online-domain-tools.com/
@marcel_verpaalen fantastic job!
Many thanks jens
2 Likes
@JensK thanks for the write up… will surely help people.
btw, I think the very last step of crypting to a 32hex token is not required. You can enter the 96 bit token directly, the binding will do the conversion to a 32hex token
The Xiaomi Robot Vacuum has been hacked gaining root access, shown on the 34C3. Overall the security seems to be quite solid, see (sorry, only German) https://www.heise.de/newsticker/meldung/34C3-Vernetzter-Staubsauger-Roboter-aus-China-gehackt-3928360.html
The code and presentation can be found here https://github.com/dgiese/dustcloud.
Maybe this helps to get the token, getting access to the created maps and controlling the cloud communication?
2 Likes
Indeed it may… very interesting.
I’ve bit of a theory on how to get to the token based on the device ID and a little brute forcing.
Need bit of time to try it out on my devices, but if true, I’ll build it into the binding.
2 Likes
Thanks for the update.
I installed the newest version a few days ago and i’m still struggeling.
My colored bulbs are not discovered anymore. The Eyecare lamp is still found but there is still the known error with the token.
I tried different things, like deleting them from the app and adding them again but that won’t help.
The only thing which could be the problem is, that I added the colored bulbs via the singapore server (and not the china mainland) to use them with my amazon alexa via the yeelight skill ( which is not possible when the bulbs are connected via the china mainland server).
I don’t know if the server location makes a difference for this binding.
The Eyecare lamp is connected to the china mainland server (and is discovered by the binding) but there is the error with the token.
Maybe someone has an idea how this could be solved, if not, it’s not too worse because i can use the bulbs via amazon alexa and the Eyecare lamp is not so important for me.
@Caroline_O best update the binding once more… while I fixed one discovery I seem to broke the other.
As far as I know it may work with every server, but keep in mind that each time the token is changing.
@LouiseButler found that I had for the robot v2 a dash instead of a dot in the id. I think that prevented the discovery as vacuum. This should be fixed in the latest minor update of today
Thanks 
I installed the newest version and my colored bulbs are now discovered and work fine.
I tested the power and the brightness channel and they both work well.
I also tried to test the color channel but there I’m a still struggeling. This is my first RGB light which I use with openhab, so have to find out more how this RGB stuff works and how to set up a colorpicker within the habpanel.
Alright, back from the holidays… Hope you guys are doing good.
I tried to find a way to test your suggestion in VS Code but couldn’t find the where and how to do it… 
set_scene[“nightlight”, 10]
and
set_scene[“nightlight”]
What exactly is the advanced command channel?
I guess I have a lot left to learn about.
Best regards
Anthrax
the color channel most likely does not work yet… I added the color bulb mainly so the other functions would be applicable (on/off etc), the color channel I added this as ‘highly experimental’… I’m sure it won’t break anything, but also high chance it does not yet work. I think a conversion between the OH color code and the yeelight color code is needed, but have not looked into it how that can be done.
Hi all,
It is a pleasure to be here, recently I started with my home automation project. Thanks to Marcel I have already been able to do some integrations. I’m in the same situation as Antrax, I’m not able to see in what way I have to apply set_scene.
Thanks again for your effort Marcel.
Regards!
@marcel_verpaalen the topic about token can be interesting for us https://github.com/dgiese/dustcloud/issues/12
If I’m understanding it right we can request token generation from Openhab.
@bademux I don’t see a new way described there.
The possibility to obtain a token has been there from first release of the binding (similar as to how the python version is working). Connect to a ‘virgin’/resetted robot and the token will be obtained with the OH discovery,
.
However, once you obtained the token, you can’t link to the mi app anymore. If you do connect it to the mi app, the token is changing, hence no longer usable.
Maybe nice to know that also the plain text token (as it is stored on the device) can be directly entered in the OH config.
the binding actually accepts 3 flavours of tokens: 16 char plain text, 32 byte hex token (which it also displays) and the 96 byte encrypted token (obtained from IOS app)
UPD:
“APP-commands are not accepted, if Cloud-communication was not established”
source: https://github.com/dgiese/dustcloud/blob/master/xiaomi.vacuum.gen1/techinfo.pdf , page 15
So it is not possible to use Vacuum on local network 
Well,
I don’t care about MiHome application having such great binding for Openhab and OpenHab mobile app,
so I’m thinking about automatization for token generation for unprovisioned\rooted devices.As far as I understand Vacuum sends a token to the cloud, so for rooted devices we can redirect request to openhab or even get token from device by ssh automatically.
@Sepultura @Caroline_O command channel usage
Okay, the cmd channel stuff is bit hidden. What it allows is to send arbitrary commands to miio devices.
Hence commands that are not pre-defined in the binding can still be executed. This can be useful for advanced use cases (e.g. you want to en/disable the do not disturb, or steer the vacuum with the remote controlling option)
As this is not the regular usage, I marked the channel as ‘advanced’ this means that it is not directly visible in OH paperUI.
To make it visible in paperUI, go to your vacuum thing. When you see the list of channels, click on the ‘show more’ to expand the list of channels and make the advanced channels visible.
Than you can enter the command in that channel
After a few seconds it will update itself with the response from the device. for example most commands give just a response like this:
{"result":0,"id":26993}
an alternative of entering it throgh the GUI would be to send the command through the karaf command line
you can send like smarthome:send your item name command[parameters]
regarding token extraction,
Somehow the binding actually extracts the token from my “mi gateway”. I don’t know why that device acts differently from my yeelights. I have not looked further at that, since I am using the mi home binding for the gateway.
I recently setup this binding with my Xiaomi robot. It is working great. I just have a small display issue on my Basic UI dashboard where the current state is displayed on switch items configured for the robot. The odd part is that I don’t have a state format defined in the item label text which I believe should prevent that behavior. Also, I have other bindings setup that way and I don’t have the state information displayed. This is why I am posting in this thread as it might be just related to this binding only.
Dashboard:
Items:
String RobotVacuumActionControl "Cleaning Mode" <cleaningrobot> (gVacuum) {channel="miio:vacuum:xxxxxxxx:actions#control"}
Number RobotVacuumActionFan "Fan Level" <qualityofservice> (gVacuum) {channel="miio:vacuum:xxxxxxxx:actions#fan"}
Sitemap:
Switch item=RobotVacuumActionControl mappings=[vacuum="VACUUM", pause="PAUSE", spot="SPOT", dock="DOCK"]
Switch item=RobotVacuumActionFan mappings=[38="QUIET", 60="BALANCED", 77="TURBO", 90="MAX"]
It is device and even firmware dependent. The earlier firmware versions always provided the tokens, than the later only once. The latest even changes it upon connecting it to the cloud.
Some yeelights and airpurifiers still provide the token with each request.
Well this does the trick and I can confirm both commands working perfectly.
I can now play with other commands from the API reference (link).
Last thing I’m struggling with is how to execute the command channel from within a rule. It always throws formatting errors…
But we’re getting there 
THANK YOU @marcel_verpaalen
I now use the binding for Marcel for openhab more than 6 month and I love it.
As I use some own defined rules I have a question - maybe it will be bullshit but please comment.
Our robot will run 2 or 3 times a week, while the rest of the week he spend @ dock for charging.
After reaching a battery status of about 100% I would like to see the robot moving forward until connection to charging contacts are interrupted.
By reaching battery low limit (aprox. 30%) he has to go back for charging.
- Would it be a good idea to do run upper mentioned method instead of keep him charging all time ? What about battery life time ?
- How could I realize a straight forward movement.
Of cource I could send him “Vaccum” command and after a delay send “Pause” but then the robot moves to a not defined place in the room.
A rule which checks the battery status and wake robot up to go back to dock is already implemented.
Many thanks for your feedback