Xiaomi Robot Vacuum Binding

binding
vacuum
xiaomi
Tags: #<Tag:0x00007f0147df0990> #<Tag:0x00007f0147df0800> #<Tag:0x00007f0147df02b0>

(Bob Miles) #814

Ok so the newest app version has the option to store the map, I don’t know if it was added over the air or via play store app update.
I can’t use it yet, as it requires a robot update as well which is not available yet for me.
But you manual update people could have a try!


(Kristof Rado) #815

@marcel_verpaalen
I have found a bug, but I don’t know how I could solve this. I have a Xiaomi Mi LED Desk Lamp.
The modelId is: yeelink.light.lamp1 (it was auto-configured).
Sometimes the binding fails turning ON/OFF the lamp. When I press the switch it immediately turns back to OFF/ON. Restarting the binding helps with this issue.

When trying to power it ON/OFF when this error happens, I get the following error (you can see when I turn on the lamp, and right after the error it turns off the switch… however sometimes the lamp turns on, sometimes don’t)

2018-11-14 13:49:16.176 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":6969,"method":"set_power","params":["on"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 1)

2018-11-14 13:49:16.196 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:49:16.202 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:49:16.207 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Periodic update for 'miio:generic:0443DBCD' (miio:basic)

==> /var/log/openhab2/events.log <==

2018-11-14 13:49:16.196 [GroupItemStateChangedEvent] - gAllLight changed from OFF to ON through miDeskLamp_Power

==> /var/log/openhab2/openhab.log <==

2018-11-14 13:49:16.216 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:49:16.219 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:49:16.222 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":6970,"method":"get_prop","params":["power","bright","delayoff","ct","color_mode"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 2)

2018-11-14 13:49:16.223 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:49:16.226 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:49:16.237 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":6971,"method":"get_prop","params":["name"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 3)

2018-11-14 13:49:16.246 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:49:16.257 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:49:16.272 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Received message is invalid JSON: 

2018-11-14 13:49:16.274 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: SET_POWER, result: null, fullresponse: {"error":"Received message is invalid JSON"}

2018-11-14 13:49:16.276 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Error received: "Received message is invalid JSON"

2018-11-14 13:49:16.301 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: GET_PROPERTY, result: ["ok"], fullresponse: {"result":["ok"],"id":6969}

2018-11-14 13:49:16.303 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Unexpected size different. Request size 5,  response size 1. (Req: ["power","bright","delayoff","ct","color_mode"], Resp:["ok"])

2018-11-14 13:49:16.309 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Error while handing message {"result":["ok"],"id":6969}

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

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

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

	at com.google.gson.JsonArray.get(JsonArray.java:183) ~[21:com.google.gson:2.7.0.v20170129-0911]

	at org.openhab.binding.miio.handler.MiIoBasicHandler.updateProperties(MiIoBasicHandler.java:378) ~[254:org.openhab.binding.miio:2.4.0.201810282000]

	at org.openhab.binding.miio.handler.MiIoBasicHandler.onMessageReceived(MiIoBasicHandler.java:429) [254:org.openhab.binding.miio:2.4.0.201810282000]

	at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:211) [254:org.openhab.binding.miio:2.4.0.201810282000]

2018-11-14 13:49:16.326 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: GET_PROPERTY, result: ["on","6","0","2700","2"], fullresponse: {"result":["on","6","0","2700","2"],"id":6970}

2018-11-14 13:49:16.328 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Unexpected size different. Request size 1,  response size 5. (Req: ["name"], Resp:["on","6","0","2700","2"])

==> /var/log/openhab2/events.log <==

2018-11-14 13:49:16.326 [GroupItemStateChangedEvent] - gAllLight changed from ON to OFF through miDeskLamp_Power

Or the other error I found. This happens when pinging (polling?) the lamp’s state:

2018-11-14 13:52:58.104 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:52:58.109 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:52:58.113 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":6993,"method":"get_prop","params":["name"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 1)

2018-11-14 13:52:58.114 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Received message is invalid JSON: 

2018-11-14 13:52:58.115 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:52:58.117 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: GET_PROPERTY, result: null, fullresponse: {"error":"Received message is invalid JSON"}

2018-11-14 13:52:58.120 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Error received: "Received message is invalid JSON"

2018-11-14 13:52:58.120 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:52:58.128 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Received message is invalid JSON:

After refreshing the bundle, this is when it works as excepted:

2018-11-14 13:54:53.256 [ome.event.ItemCommandEvent] - Item 'miDeskLamp_Power' received command OFF

2018-11-14 13:54:53.276 [nt.ItemStatePredictedEvent] - miDeskLamp_Power predicted to become OFF

==> /var/log/openhab2/openhab.log <==

2018-11-14 13:54:53.293 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Locating action for channel power: OFF

2018-11-14 13:54:53.298 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Sending command set_power["off"]

2018-11-14 13:54:53.314 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":4,"method":"set_power","params":["off"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 1)

2018-11-14 13:54:53.317 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:54:53.328 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:54:53.337 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Periodic update for 'miio:generic:0443DBCD' (miio:basic)

2018-11-14 13:54:53.340 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:54:53.346 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:54:53.349 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":5,"method":"get_prop","params":["power","bright","delayoff","ct","color_mode"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 2)

2018-11-14 13:54:53.351 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:54:53.356 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:54:53.359 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":6,"method":"get_prop","params":["name"]} -> 10.0.0.148 (Device: 0443DBCD token: 8C91747B4A1CB9BB215A2788909BE0DA Queue: 3)

2018-11-14 13:54:53.361 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0443DBCD (10.0.0.148)

2018-11-14 13:54:53.370 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0443DBCD (10.0.0.148) success

2018-11-14 13:54:53.425 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: SET_POWER, result: ["ok"], fullresponse: {"result":["ok"],"id":4}

2018-11-14 13:54:53.435 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: GET_PROPERTY, result: ["off","6","0","2700","2"], fullresponse: {"result":["off","6","0","2700","2"],"id":5}

2018-11-14 13:54:53.458 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0443DBCD type: GET_PROPERTY, result: [""], fullresponse: {"result":[""],"id":6}


(Kristof Rado) #816

In which menu did you find this? I’m not really good at german…
However I didn’t get any updates for the app in the last week or so. (iOS)
As I can see you have the v2 vacuum, I have the v1 so I already have less features than you. Hope this feature will be added to both models.


(Bob Miles) #817

Sorry I didn’t realize nobody can read it except German people… It’s in the Robot Settings where you set the DND mode…
I also got a robot update now, I’ll install it in the evening:


(Kristof Rado) #818

Thanks! So it seems for me the option is not there in the app and I haven’t got any updates yet. However version numbers differs from yours, so I think the two models have different versions.


(marcel) #819

Right after the binding sends the command to execute the on/off, it is scheduling a refresh of the status.
In your case it seems the on/off did not execute on the light, and due to the directly following refresh, the switch goes immediately back,

Likewise, it appears the light is replying with empty messages.
You can run the binding with debuglevel set to trace to see the actual exchange of messages. This may give more indication of what is happening.

as some commands appear to be missing and messages content is sometimes off, can it be that there is some network connectivity issues with your light? (mine is also extremely poor in signal strength, less than 2 meter from the access-point and still sometimes looses wifi connection)


(Kristof Rado) #820

Yes, it might be, because it is far from the AP, however a Sonoff switch has around 60-70% RSSI.
The only weird thing is that I can still control it from the app when this happens. Also only a bundle refresh is needed to solve this issue, then it works again for days or even weeks without a single error.

If it happens again I’ll try it with trace, but it generates a lot of output, since I have some Xiaomi devices connected :slight_smile:

Ps.: I don’t know if this is an error or this happens because the state is polled from device, but when I turn on the lamp with the switch, it takes 5-10 seconds to update the state in openHab. Before that I didn’t have this experience with the vacuum or the air purifier. States uploaded instantly.


(Constantinos Contis) #821

now with the “save map” feature is there a way to have the saved map in habpanel?


(Bob Miles) #822

Hmm I don’t think the way the map is stored has changed, it is just matched again but no new API or the like…
Sadly, the robot behaves differently when using zoned cleanup. It becomes quite stupid to put it clearly. None of the admirable intelligence, that is seen with a full cleanup, is put to show in zoned cleanup. It just bumps into everything and sometimes even takes a pause to “think” or whatever it’s doing…
Maybe one must put up no go barriers instead of setting a go-to-zone to get the intelligent behaviour for distinct area cleaning :wink:


(Andrew Pawelski) #824

Did this happen?


(Oskar Sawaryn) #825

Hi
Could anyone tell me what I’m doing wrong?
I to looks like this command creates points for spot cleanup, not the area.


rule:


 rule "Zone Cleaning"
  when
     Item vacZoneCleaning received command
  then
   switch (receivedCommand.toString) {
     case "1": {
         sendCommand(actionCommand,"app_zoned_clean[[29900,24900,24300,28700,1]]")
           }
       [...]
  }
end

sitemap:

Selection	item=vacZoneCleaning mappings=[9="All", 1="Master Bedroom", [...] ]

(Bob Miles) #826

My guess is that your area does not match the map stored on the robot. Can you try to extract the coordinates from Flole or the like and see if they are still valid?

I think I have found why the robot is behavin different when using zoned clean up: Actually, the cleaning itself is not different. But When you start the zoned clean up it will try to reach the corner of the area, and the navigation there is not as sophisticated as during the cleaning. So maybe setting the area to have corners which are easily reached might help…


(Oskar Sawaryn) #827

Thank you so much! I have Flole app installed but I didn’t know it can extract coordinates!
Now I’ve got another problem. I’m trying to voice control my vacuum via Google Home like “Clean the kitchen”.
I’ve created an ifttt task but don’t know that comment need to be send to actionCommand item.

This one? With quotes or without? Maybe something different? Or maybe other item?
“app_zoned_clean[[29900,24900,24300,28700,1]]”


(Kristof Rado) #828

@marcel_verpaalen

I was able to capture when this ON/OFF thing happens with TRACE logging. Can you have a look at it?
I couldn’t find any problems there.

https://pastebin.com/BpxR8JDz


(marcel) #829

@rkrisi looks interesting… I indeed see something that is not suppose to happen.
Need to look more deeply into the logic to see why that happens


(Kristof Rado) #830

Thanks :slight_smile: Let me know if you need any more information. Interesting though that it happens very rarely…


(Michael Joos) #831

@marcel_verpaalen I have the issue that this (great) :+1: Binding does not reconnect to my Roborock in some cases.

Background: I’m switching off my Roborock over night and it seems that the device goes to standby and is not reachable anymore over WLAN = Offline in openHAB. So far so good :slight_smile:
Next day when the Roborock is alive again openHAB does not reconnect automatically and I have to restart openHAB.

The funny thing is that this only happens if I start openHAB and Roborock is already in Standby-Mode (offline). If I start openHAB and Roborock is online it automatically reconnects the next day, even if the device was offline over night.

Is it possible to handle this in the Binding or is this part of openHAB-Core-Functionality?

Thanks
Michael


(marcel) #832

@michaeljoos mmm that is strange and unexpected.
3 thoughts:

  1. is the IP changing when the device is online again? I can imagine that it gets the IP wrong
  2. Is your device setup as generic or as vacuum… though that should normally not matter, if it is a generic one, can you try to set it up manually as miio:vacuum type
  3. there is a counter to make each message unique. Maybe the vacuum expects it to start from 0 again when it wakes up.

Can you check the following:

  1. if the ip is changing
  2. instead of restarting OH, just go into your vacuum, edit the config (at least one setting needs to change) to see if that is also fixing the connection
  3. change thingtype to vacuum

(Michael Joos) #833

@marcel_verpaalen The IP address remains and the thing is already defined as miio:vacuum type

Today I did test again:

  1. Roborock ON and ONLINE in openHAB
  2. Switch OFF Roborock --> After a few seconds OFFLINE in openHAB
  3. Switch ON Roborock --> After a few seconds back to ONLINE in openHAB

The above is fine :slight_smile:

Second Test:

  1. Roborock ON and ONLINE in openHAB
  2. Switch OFF Roborock --> After a few seconds OFFLINE in openHAB
  3. Restart openHAB --> After System has been started Roborock is still OFFLINE (what is OK)
  4. Switch ON Roborock --> And now Thing is not going to ONLINE anymore (not OK)
  5. Edit and a change one setting and save --> Roborock back to ONLINE

Hope this helps. But it’s not really critical…


(Salexes) #834

I have found the issue but I dont know how to solve it.

When I define my item like this:
Dimmer YeelightLEDCeilingLampV4JIAOYUE650RGB_Brightness "Schlafzimmer Licht" <light> (gLight) [ "Lighting" ] {channel="miio:generic:0456E259:brightness"}
Then the light is not changing its brightness at all.

It only works when I use this item:
Number YeelightLEDCeilingLampV4JIAOYUE650RGB_Brightness "Schlafzimmer Licht" <light> (gLight) [ "Lighting" ] {channel="miio:generic:0456E259:brightness"}

But the problem is when the item is defined as number I can not use the commands on and off. And I want to be able to tell alexa: “Turn of Schlafzimmer Licht” and “Set Schlafzimmer Licht to 75%”.

How to solve this?