got most of the commands up and running for viomi-vacuum-v7, I still need to figure out how to change the water level used by the vacuum, but most of them are already there.
@merccooper if that is all, you can make a basic device database entry to (almost fully) support it.
Only the get_disturb would be trickey
Look at the existing database files, gives you direction on how to do. All the things you find in the get_prop section should have a corresponding property in the database.
The actions are to send the set_… commands
sorry, but could you be more precise?
do you mean that thing config shold look like this:
Thing miio:vacuum:070835F7 "Bobbi" @ "Wohnzimmer" [ host="192.168.4.110", token="XXXXXXXXX" ]
I already tried that and have the same problem, but other error
2019-12-20 10:18:27.600 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Receiver thread received SocketException: Socket closed
2019-12-20 10:18:27.600 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Stop Xiaomi Mi IO background discovery
2019-12-20 10:18:27.601 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Receiver thread ended
2019-12-20 10:18:27.693 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Start Xiaomi Mi IO background discovery
2019-12-20 10:18:27.698 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Getting new socket for discovery
2019-12-20 10:18:27.699 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Starting discovery receiver thread for socket on port 48427
2019-12-20 10:18:27.699 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 172.17.255.255 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.700 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-393,5,main] waiting for data on port 48427
2019-12-20 10:18:27.702 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 224.0.0.50 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.703 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 172.18.255.255 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.705 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 172.19.255.255 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.707 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 224.0.0.1 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.708 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 192.168.4.255 from 0.0.0.0/0.0.0.0:48427
2019-12-20 10:18:27.711 [TRACE] [l.discovery.MiIoDiscoveryParticipant] - ServiceInfo: [ServiceInfoImpl@17026561 name: 'roborock-vacuum-s5_miio117978615._miio._udp.local.' address: '(null):54321' status: 'NO DNS state: probing 1 task: null', has NO data, empty]
2019-12-20 10:18:27.712 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Received 32 bytes response from 192.168.4.110:54321 on Port 48427
2019-12-20 10:18:27.714 [DEBUG] [l.discovery.MiIoDiscoveryParticipant] - mDNS roborock-vacuum-s5 identified as thingtype miio:vacuum with did 070835F7 (117978615)
2019-12-20 10:18:27.714 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery response received from 192.168.4.110 DeviceID: 070835F7
Message:
Header : 21 31 00 20 00 00 00 00 07 08 35 F7 5D FC 91 E3
checksum: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
content : N/A
Header Details: Magic:21 31
Length: 32
Serial: 07 08 35 F7
TS:2019-12-20 10:18:27
2019-12-20 10:18:27.715 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-393,5,main] waiting for data on port 48427
2019-12-20 10:18:27.715 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery responses from : 192.168.4.110:21 31 00 20 00 00 00 00 07 08 35 F7 5D FC 91 E3 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2019-12-20 10:18:27.716 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Discovered Mi Device 070835F7 (117978615) at 192.168.4.110 as miio:generic:070835F7
2019-12-20 10:18:27.716 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Received 32 bytes response from 192.168.4.110:54321 on Port 48427
2019-12-20 10:18:27.718 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery response received from 192.168.4.110 DeviceID: 070835F7
Message:
Header : 21 31 00 20 00 00 00 00 07 08 35 F7 5D FC 91 E3
checksum: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
content : N/A
Header Details: Magic:21 31
Length: 32
Serial: 07 08 35 F7
TS:2019-12-20 10:18:27
2019-12-20 10:18:27.718 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - No token discovered for device 070835F7. For options how to get the token, check the binding readme.
2019-12-20 10:18:27.719 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-393,5,main] waiting for data on port 48427
It is so easy to set this up with autodiscovery. 
You do it as per the binding readme incl the model &deviceId:
Thing miio:vacuum:070835F7 "Bobbi" @ "Wohnzimmer" [ host="192.168.4.110", token="put here your token", deviceId="0326xxxx" ,model="rockrobo.vacuum.v1"]
]
If this helps, then I have this:
Thing miio:vacuum:s50 "vacuum" @ "vacuum" [ host="192.168.215.20", token="xxxxxxx", deviceId="0470DD46", model="roborock.vacuum.s5" ]
1 Like
This works for me:
openHAB 2.5.0 Release Build
Oh, what a typo. I wanted to write:
Now it’s working with 2.5.
Sorry 
Did you got an answer to your question?
As long as my Roborock S6 is connected the a wifi with internet access everything is working fine.
As soon as I deny internet for the Roborock S6 he no longer response any openhab commands. Though Openhab is still able to contact the Roborock.
Is there no possibility to use the binding without allowing internet connection for the Roborock?
is it possible to make the commands depend from other? for example to turn on the vacuum I need to use set_mode_withroom [0, 1, 0], but if I want to clean around the edges the command should be set_mode_withroom [1, 1, 0]…for example if the “checkbox” (or anything) is checked on clean around the edges and I start cleaning it will send set_mode_withroom [1, 1, 0]…i hope you understand what I was trying to explain, im very bad explaining stuff 
Hello, I have two questions about this binding. The first is a problem with visualizing the fan and control elements for the 1st version of the Vacuum:
Thats my items:
String actionControl "Vacuum Control" {channel="miio:vacuum:67f48725:actions#control" }
Number actionFan "Vacuum Fan" (gVac) {channel="miio:vacuum:67f48725:actions#fan" }
Thats in my sitemap:
Switch item=actionControl mappings=[vacuum="Vacuum", pause="Pause",spot="Spot", dock="Dock"]
Switch item=actionFan mappings=[38="Silent", 60="Normal", 77="Power",90="Full", -1="Custom"]
I copied it from some examples here and it should work. I am using OH2 v2.5.
Also, could you please add support for Xiaomi Air Purifier 3/3H ( zhimi-airpurifier-mb3 and zhimi-airpurifier-ma4). The protocol is a bit changed but they just add it in https://github.com/rytilahti/python-miio/pull/585
Thanks
If you don’t want the red circled stuff, just put an empty format into your item label:
"Vacuum Control []"
1 Like
Wow, didnt know its so easy. Thank you!
Is there a list which roborock models work with this binding?
Xiaomi roborock s50 is working? What about s60 or s5 max?
hi…
there is a new xiaomi yeelight ceiling light:
yilai.light.ceiling1
https://www.gearbest.com/smart-ceiling-lights/pp_009313773573.html
its (still) not working with this model string but with “yeelink.light.ceiling1”.
maybe you can add this thing.
thank you
itm_RoboActionCommand.sendCommand("get_recover_maps")
is working fine and in my case gives the following result:
{"result":[[1,1575723134],[2,1577540948],[3,1577807926]],"id":5272}
1,1575723134 is referring to the initial, not edited map
2,1577540948 is referring to the older backup map
3,1577807926 is referring to the newer backup map
Any idea how to set one of these recovery map as active (load one of the map)?
I managed to do it with the help of the library https://github.com/rytilahti/python-miio with the following command:
mirobo raw-command recover_map 2,1577540948
How can this be done in obenhab? I had no success with the command channel.
For further information please see my PR: https://github.com/rytilahti/python-miio/pull/608
Did you try
itm_RoboActionCommand.sendCommand(“recover_map [2,1577540948]”)
if not, check with mirobo in debug mode what is the formatting of the command send, than it should be possible to replicate in OH command channel.