Xiaomi Robot Vacuum Binding

Add-ons Bindings
, ,
1693

first i try the command and i get no respond
Command added to Queue {“id”:250,“method”:“get_map_v1”,“params”:} → 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 1)

2020-09-23 21:40:01.881 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Periodic update for ‘miio:generic:1658433C’ (miio:basic)

2020-09-23 21:40:01.881 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:251,“method”:“get_prop”,“params”:[“run_state”,“mode”,“err_state”,“battary_life”,“box_type”]} → 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 1)

2020-09-23 21:40:01.881 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:252,“method”:“get_prop”,“params”:[“mop_type”,“s_time”,“s_area”,“suction_grade”,“water_grade”]} → 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 2)

2020-09-23 21:40:01.881 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:253,“method”:“get_prop”,“params”:[“remember_map”,“has_map”,“is_mop”,“has_newmap”]} → 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 3)

2020-09-23 21:40:06.815 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Communication error for Mi device at 192.168.178.54: Receive timed out

2020-09-23 21:40:06.815 [DEBUG] [nal.transport.MiIoAsyncCommunication] - No response from device 1658433C at 192.168.178.54 for command {“id”:250,“method”:“get_map_v1”,“params”:}.

2020-09-23 21:40:06.815 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_MAP, result: {}, fullresponse: {“error”:“No Response”}

2020-09-23 21:40:06.815 [DEBUG] [internal.handler.MiIoAbstractHandler] - Error received: “No Response”

wich channel is to download the map??

1694

Indeed, seems your vacuum has different command for getting the map… So until we find the right command for it there won’t be a map…

1695

Is there any database with the available commands for every devices??

1696

nope… there is none.
You either need to capture the traffic between the app and the device or decompile the apk plugin and try to understand the logic,

1697

searching the net i found this for the v7 model ,from here i found the wrong name of the battery. here i can see map plan, if i run it i get :slight_smile:
Command added to Queue {“id”:339,“method”:“get_prop”,“params”:[“map_plan”]} -> 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 1)

2020-09-23 21:51:39.167 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_PROPERTY, result: [], fullresponse: {“result”:[],“id”:339}

2020-09-23 21:51:39.167 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Unexpected size different. Request size 1, response size 0. (Req: [“map_plan”], Resp:[])

2020-09-23 21:51:39.182 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Error while handing message {“result”:[],“id”:339}

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

at java.util.ArrayList.rangeCheck(ArrayList.java:657) ~[?:1.8.0_232]

at java.util.ArrayList.get(ArrayList.java:433) ~[?:1.8.0_232]

at com.google.gson.JsonArray.get(JsonArray.java:194) ~[bundleFile:?]

at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.updatePropsFromJsonArray(MiIoBasicHandler.java:438) ~[bundleFile:?]

at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.onMessageReceived(MiIoBasicHandler.java:521) [bundleFile:?]

at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:233) [bundleFile:?]

Is that mean that we must edit the json file to add this channel?? if yes what exactly i must add?

list of all methods/params (don’t test them if you don’t know what you are doing).

get_prop
set_mode
set_pointclean
set_wall
set_zone
set_charge
set_ischarge
set_direction
set_suction
set_repeat
set_broken
set_light
set_voice
set_language
set_ordertime
del_ordertime
get_ordertime
set_notdisturb
get_notdisturb
set_carpetturbo
set_remember
set_calibration
get_curpos
set_resetpos
set_resetmap
set_uploadmap
get_consumables
set_consumables
map_plan
add_map
set_mode_withroom
reset_factory
arrange_room
rename_room
set_mop
set_newmap
set_cardoper
set_iswork
set_timezoneorder
set_auto

hw_info
sw_info
run_state
suction_grade
mode
err_state
battary_life
start_time
order_time
s_time
s_area
v_state
zone_data
repeat_state
remember_map
has_map
water_grade
box_type
mop_type
is_mop
light_state
has_newmap
is_charge
is_work

1698

Okay, so looking at that list, seems the first are the commands, the 2nd list are the properties.
You run the commands like has_map[] if there are no parameters, or with something between the square brackets if needed (like the get_prop commands needs the names of the properties)

You can try the commands and see what are the responses. Once the parameters are known, we can improve the json file. In many cases the parameter will be similar as the response to the get_prop

e.g. you see the responses to the suction_grade property, you can try the set_suction[xxx] to control it. (replace xxx with the value)

1699

i will try and i will inform you.
Thanks again for your support and the great work that you are doing. :+1:

1700

@marcel_verpaalen
Would it be possible to add a switch to every Thing which disables token download for that device? It seems that my vacuums token gets overwritten with a wrong token. I assume this happens because I use Valetudo, so it overwrites with the last token which was pushed to the Xiaomi servers.

1701

Unfortunately that is not so easy…because of the way discovery works in the openhab framework.
I might be able to do that for the whole binding (meaning until you switch it on again, it will not try to get tokens from the cloud during discovery)

btw, the main reason the binding finds the wrong token is when your vacuum is defined in multiple country servers. Than it may fetch the token from the wrong country. If this is the case, logon in the app to the county that you are not using and remove the device. When the device is only linked to single county, I have not experienced it gets it wrong.

1702

Well I only used it with the chinese server…
But I think what happens here is that I have used it with the Xiaomi App, the token was uploaded there (to the chinese server), but now I’m using it cloud-free (with Valetudo) and the token changed when I re-flashed the robot with Valetudo. However this new token was not uploaded anywhere (because it is completely cloud-free) and the binding always downloads the last known token…

Anyway, what if I set a wrong country code for this device? That way it will not download the token from the chinese server?

1703

yes, indeed, that would be a good solution… anyway, if you don’t need the cloud as you are then also not getting the map from the server I guess you could also just remove your userid/pwd

1704

Yes you are right, I’m not using the map function also, I have integrated the map with Valetudo.
Though I don’t really want to remove my userid, because I have other devices as well, where this token download comes handy (and I also plan to buy new ones)…

Thanks, I will test it with a wrong country code…

1705

is there an easy way to find out what those exactly are ?
my roborock is already in OH

image
image592×616 43 KB

1706

Check your order history.

2 Likes
1707

You made my day :slight_smile: LOL…

Add them to OH and you see… if you really dont wanna… check the file in userdata/miio with the tokens…in there is also a friendly name of the device

1708

Hi Marcel,
I am trying to edit the viomi.vacuum.v8.json file to add some more channels but i get errors do you any idea why??
Periodic update for ‘miio:generic:1658433C’ (miio:basic)

2020-09-27 10:15:15.166 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:6,“method”:“get_prop”,“params”:[“run_state”,“mode”,“err_state”,“battary_life”,“box_type”]} -> 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 1)

2020-09-27 10:15:15.166 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:7,“method”:“get_prop”,“params”:[“mop_type”,“s_time”,“s_area”,“suction_grade”,“water_grade”]} -> 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 2)

2020-09-27 10:15:15.166 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:8,“method”:“get_prop”,“params”:[“remember_map”,“has_map”,“is_mop”,“has_newmap”,“get_notdisturb”]} -> 192.168.178.54 (Device: 1658433C token: 6F635844XXXXXXXXXXXXXXXX5A303976 Queue: 3)

2020-09-27 10:15:15.295 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_PROPERTY, result: [5,0,2105,100,1], fullresponse: {“result”:[5,0,2105,100,1],“id”:6}

2020-09-27 10:15:15.311 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_PROPERTY, result: [0,0,0,0,11], fullresponse: {“result”:[0,0,0,0,11],“id”:7}

2020-09-27 10:15:15.327 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_PROPERTY, result: [1,1,0,0], fullresponse: {“result”:[1,1,0,0],“id”:8}

2020-09-27 10:15:15.327 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Unexpected size different. Request size 5, response size 4. (Req: [“remember_map”,“has_map”,“is_mop”,“has_newmap”,“get_notdisturb”], Resp:[1,1,0,0])

2020-09-27 10:15:15.327 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Error while handing message {“result”:[1,1,0,0],“id”:8}

java.lang.IndexOutOfBoundsException: Index: 4, Size: 4

at java.util.ArrayList.rangeCheck(ArrayList.java:657) ~[?:1.8.0_232]

at java.util.ArrayList.get(ArrayList.java:433) ~[?:1.8.0_232]

at com.google.gson.JsonArray.get(JsonArray.java:194) ~[bundleFile:?]

at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.updatePropsFromJsonArray(MiIoBasicHandler.java:438) ~[bundleFile:?]

at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.onMessageReceived(MiIoBasicHandler.java:521) [bundleFile:?]

at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:233) [bundleFile:?]
1709

Seems the viomi.vacuum.v8 does not give any response if you request a property that does not exists.

You see the error:
Unexpected size different. Request size 5, response size 4. (Req: [“remember_map”,“has_map”,“is_mop”,“has_newmap”,“get_notdisturb”], Resp:[1,1,0,0])

You are asking for 5 properties, but the vacuum only responds with 4. Hence the binding does not know how to deal with that. You’ll need to test each of the properties individually and see if they provide a response to find out which is the non-supported property.

1710

If i type this in the command: get_notdisturb i get back this answear : {“result”:[0,23,0,10,0],“id”:580} so this mean that i get respond. Then i edit the json file like this
{
“property”: “get_notdisturb”,
“friendlyName”: “Not Disturb”,
“channel”: “get_notdisturb”,
“type”: “String”,
“refresh”: true,
“actions”: [
]
}

and i get the erros that i told you. i try “type”: “String”, and as number but same error

here wea sk 5 and we get 5 respond back
2020-09-27 10:15:15.295 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1658433C type: GET_PROPERTY, result: [5,0,2105,100,1], fullresponse: {“result”:[5,0,2105,100,1],“id”:6}

1711

Hi Niklos,

get_nondisturb seems like a command, not a property. In the command line you would test it with get_prop["get_nondisturb"]… if it is responding with a proper result, indeed it is property. if it is a command you would send it like get_nondisturb[]

As it looks like a command, I doubt that the response to it will be "result”:[0,23,0,10,0] The Id of the command and the response need to match.

Note: The miio:basic handler can currently only deal with properties in the refresh. It is in my wishlist/todo to also allow to send commands as part of the refresh.

1712

You have right, like this: get_prop[“get_nondisturb”] i get this respond : {“result”:,“id”:735}
like you say it is a command not a property.

Thanks a lot for your support