Xiaomi Robot Vacuum Binding

@ip-ua yes, that is expected. Those color commands are not really working
There is some development needed to properly get the color stuff working.

what would be useful is to get for the various types also the response to the command:
get_prop[ "rgb", "hue", "sat", "color_mode", "bright", "ct", "flowing", "delayoff", "music_on"]
(run it in debug mode, then you can see what the lamps really respond)

pls consider this yeelight support still experimental!
My 1st prio for now is to make the few adjustments to have the binding ready for review and accepted & part of the normal distribution. Than continue with adding these new features.

This is indeed unexpected. Though I’ve seen another message around the same. I somewhat suspect that there is some sort of version issue with the json library I use between the different OH versions (OH2.1 / OH2.2 snapshot)
In the logs I saw, the json actually was perfectly valid, but somehow not accepted as fine.

What version of the runtime are you running?
If you have a chance to change the log level and see what is the json content it considers invalid that would also be interesting.

I’m on 2.2.0-SNAPSHOT build 1098.

Yes, I’ll do that and report back.

Marcel,
You are doing great job and I even do not think about “pushing” you! :slight_smile:
Will try to get data you need soon, but unfortunately I do not have enough time for my Smart Home as I wish.
And I agree that make this binding included in the normal distribution is more important.
Thanks,
Igor

@marcel_verpaalen I getting lots of the same errors as well build 1058

Thank you for that great binding.
I installed it to use it with my xiaomi phillips eyecare lamp.
Installation worked fine and my device is online.
But I now have the problem that i can’t switch the lamp on or off via openhab.
I found this warning in my logfile:

2017-12-07 15:34:00.462 [WARN ] [nal.transport.MiIoAsyncCommunication] - Send command '{"id":28,"method":"miIO.info","params":[]}'  -> 192.168.2.22 (Device: 02C59D6C) gave error Given final block not properly padded

Maybe somebody had the same problem and can help me?

Here’s a snippet from the log with TRACE level logging. There are some successful transactions and some unsuccessful transactions. For the unsuccessful ones, it appears that there is no content and a weird looking checksum in the response?

I have the miio binding logging to it’s own log file. If you want to see more, I can put it somewhere for you to pick up.

2017-12-07 13:23:20.104 [DEBUG] [ing.miio.internal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":35649,"method":"get_clean_summary","params":[]} -> 192.168.x.x (Device: 03D9D158 token: 716F784A4877537657466F4D6832624E Queue: 2)
2017-12-07 13:23:20.104 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.104 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 70 00 00 00 00 03 D9 D1 58 5A 29 86 F9
checksum: 4C 76 B5 EF 2D 3D 38 D5 4A 11 EB 83 FA 88 08 3A
content : 97 7E D2 97 F3 12 C8 8C FD CE 3B FD 03 89 D6 5A 26 6D F9 DD 9E 79 F9 1F 93 8E F6 17 7A A8 5B 4E 21 01 08 FE 69 51 EC D2 B2 61 44 DD 51 91 95 B4 4B 34 60 4E 79 D9 A4 0F 87 0E 33 5C E2 34 68 D0 1A 31 66 33 62 69 F1 54 08 CA 55 E3 3C 13 E4 C4
Header Details: Magic:21 31
Length:   112
Serial:   03 D9 D1 58
TS:2017-12-07 13:22:49
2017-12-07 13:23:20.104 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.105 [DEBUG] [ing.miio.internal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":35650,"method":"get_status","params":[]} -> 192.168.x.x (Device: 03D9D158 token: 716F784A4877537657466F4D6832624E Queue: 3)
2017-12-07 13:23:20.105 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.105 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 F0 00 00 00 00 03 D9 D1 58 5A 29 86 F9
checksum: 82 8E 39 F6 5A 02 DD 04 EF 52 52 F0 08 07 E5 3F
content : D5 07 83 A2 56 CF 14 24 99 E0 41 D3 9B 8E A5 71 72 1C E3 14 B2 BB 32 56 F6 6E BB 60 C2 8A F3 2A 45 E3 6C 50 55 53 2C 0C 74 05 23 C1 88 6D 2B CE 8E 79 A9 23 61 9C EA 74 10 5B AF 39 E5 D1 FD 41 D5 41 1B 51 1C D5 89 D2 DE 11 86 93 46 6C 77 2F 02 32 C6 E4 F4 40 5B B1 DE 6E F2 44 02 32 72 B5 14 CB 2D 3B F2 F8 00 C1 E1 8F D5 23 7E 83 93 BB 8F 31 D8 58 CB E6 1D 60 F9 5B 43 A4 89 BF 9E 9A 58 5B 65 78 1D 19 77 F9 8C C7 87 25 19 6D 7C E8 86 DD 00 F2 9C B2 35 A1 64 AC 64 EB 88 0B 88 5E 53 92 CE 6A 0B AA 5D 24 3D 22 73 E8 1F CB 78 40 89 4A AE 91 FE 95 B9 6F 5C 8B 09 1B C2 B0 F8 F6 BD 5D F2 98 79 DE 7E 68 F8 4C DA E2 08 49 39 45
Header Details: Magic:21 31
Length:   240
Serial:   03 D9 D1 58
TS:2017-12-07 13:22:49
2017-12-07 13:23:20.106 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.106 [DEBUG] [ing.miio.internal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":35651,"method":"miIO.info","params":[]} -> 192.168.x.x (Device: 03D9D158 token: 716F784A4877537657466F4D6832624E Queue: 4)
2017-12-07 13:23:20.106 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.107 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 B0 00 00 00 00 03 D9 D1 58 5A 29 86 F9
checksum: 26 83 BA C6 31 2F 6F 05 0C 2A F6 7C 87 5A C6 97
content : 52 F0 E7 3B 8C F1 96 5E A7 A1 F2 C4 BE 04 62 6F B3 40 00 85 ED 15 A7 D0 09 05 44 27 6A 26 B2 EF 9E FD F2 7E 58 14 AE 9D 5A C1 8F 50 17 90 8F 21 3F 84 DF 6E EF D5 8C 4E 21 77 89 73 DA 20 34 F0 B3 1A 8F BC DB 81 03 1D 9E 9D 7F DE 74 C5 0F EF 66 29 AB 92 AE 8B D7 A4 5C 80 91 E3 15 2B 2F A0 FF 4A C5 22 97 10 50 2D E5 9D C1 76 25 2A FD D5 90 40 64 A7 87 F1 28 7F 27 A2 BB 44 A7 55 81 D6 31 6F 55 F9 A0 AE A3 0B 52 09 B1 07 83 D2 1C A3
Header Details: Magic:21 31
Length:   176
Serial:   03 D9 D1 58
TS:2017-12-07 13:22:49
2017-12-07 13:23:20.107 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.107 [DEBUG] [ing.miio.internal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":35652,"method":"get_consumable","params":[]} -> 192.168.x.x (Device: 03D9D158 token: 716F784A4877537657466F4D6832624E Queue: 5)
2017-12-07 13:23:20.107 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.391 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 20 00 00 00 00 03 D9 D1 58 5A 29 87 17
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:   03 D9 D1 58
TS:2017-12-07 13:23:19
2017-12-07 13:23:20.391 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.391 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.391 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 20 00 00 00 00 03 D9 D1 58 5A 29 87 17
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:   03 D9 D1 58
TS:2017-12-07 13:23:19
2017-12-07 13:23:20.392 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Received response from 192.168.x.x:
2017-12-07 13:23:20.392 [INFO ] [ing.miio.internal.transport.MiIoAsyncCommunication] - Received message is invalid JSON:
2017-12-07 13:23:20.392 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.392 [DEBUG] [g.openhab.binding.miio.handler.MiIoAbstractHandler] - Received response for 03D9D158 type: DND_GET, result: null, fullresponse: {"error":"Received message is invalid JSON"}
2017-12-07 13:23:20.393 [DEBUG] [g.openhab.binding.miio.handler.MiIoAbstractHandler] - Error received: "Received message is invalid JSON"
2017-12-07 13:23:20.393 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Connection 192.168.x.x:55955
2017-12-07 13:23:20.394 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Message Details:Message:
Header  : 21 31 00 20 00 00 00 00 03 D9 D1 58 5A 29 87 17
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:   03 D9 D1 58
TS:2017-12-07 13:23:19
2017-12-07 13:23:20.394 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - Received response from 192.168.x.x:
2017-12-07 13:23:20.394 [INFO ] [ing.miio.internal.transport.MiIoAsyncCommunication] - Received message is invalid JSON:
2017-12-07 13:23:20.394 [TRACE] [ing.miio.internal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@67472fa2, data {} from {}
2017-12-07 13:23:20.394 [DEBUG] [g.openhab.binding.miio.handler.MiIoAbstractHandler] - Received response for 03D9D158 type: CLEAN_SUMMARY_GET, result: null, fullresponse: {"error":"Received message is invalid JSON"}

@marcel_verpaalen: Kudos to you. :+1: Thx’s

The Xiaomi Robot Vacuum binding runs smoothly.
I enjoyed the items and sitemap example - so it’s an easy peasy start.
I received my robot this week.
I was curios to see how the robot works - now i understand the exaltation about.

I struggled a while to conquer the token. I tooks me about 1,5 hours.
But this is not to openhab or the binding. It was the MiToolKit. It crashed allways during the last step - extracting the token.
It is crucial to follow all instruction to the MiToolKit very careful.
… to anybody don’t give up - you get an english translation of the mi-home app as extra reward.

1 Like

nice work!
yeelight led strip and philips bulb works fine.
but im having problems with 2 yeelight ceiling lights
if i try to switch it on, it switches off by itself:
2017-12-20 23:23:55.713 [ome.event.ItemCommandEvent] - Item ‘og_licht_schlafzimmer_power’ received command ON
2017-12-20 23:23:55.764 [vent.ItemStateChangedEvent] - og_licht_schlafzimmer_power changed from OFF to ON
2017-12-20 23:23:55.812 [vent.ItemStateChangedEvent] - og_licht_schlafzimmer_power changed from ON to OFF

same issue when switching it off.
Dimming the brightness works fine.
any idea?

Did you use the very last version of the binding from the market? I made a small fix for it a day or 2 ago.
However,I may need to change the link sure to the recent oh2’2 release

I now added a yeelight smart bulb (color version) via the binding to openhab and I get the same problem as described above.
So I think that i have made a general mistake when adding things? At first i thought that it had to do with the eyecare lamp, because it might not be supported, but as there is the same mistakes with the smart bulbs I think that there is an other problem.
Maybe somebody has an idea what i can try to do to solve that?
My log file:

09:27:25.812 [WARN ] [rnal.transport.MiIoAsyncCommunication] - Send command '{"i d":2559,"method":"miIO.info","params":[]}'  -> 192.168.2.22 (Device: 02C59D6C) g ave error Given final block not properly padded
09:27:35.763 [DEBUG] [binding.miio.handler.MiIoBasicHandler] - Periodic update f or 'miio:basic:035C1198' (miio:basic)
09:27:35.768 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Sending Ping 035C 1198 (192.168.2.21)
09:27:36.173 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Ping 035C1198 (19 2.168.2.21) success 
09:27:36.183 [DEBUG] [binding.miio.handler.MiIoBasicHandler] - Model needs to be  determined
09:27:36.187 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to  Queue {"id":99,"method":"miIO.info","params":[]} -> 192.168.2.21 (Device: 035C11 98 token: A2189D08096304F46AF360C30D071D24 Queue: 1)
09:27:36.191 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Sending Ping 035C 1198 (192.168.2.21) 
09:27:36.198 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Ping 035C1198 (19 2.168.2.21) success
09:27:36.212 [WARN ] [rnal.transport.MiIoAsyncCommunication] - Send command '{"i d":99,"method":"miIO.info","params":[]}'  -> 192.168.2.21 (Device: 035C1198) gav e error Given final block not properly padded
09:27:36.216 [DEBUG] [ding.miio.handler.MiIoAbstractHandler] - Received response  for 035C1198 type: MIIO_INFO, result: null, fullresponse: {"error":"Given final  block not properly padded"}
09:27:36.219 [DEBUG] [ding.miio.handler.MiIoAbstractHandler] - Error received: " Given final block not properly padded"

Hi Caroline
How did you get the token from the yeelight? I have a smart bulb and I like to try out this binding for controlling it. I previously used the Yeelight binding, which did not ask for a token (I think)
BR
Brian

I used this way to get the token:

If you have an android device it is explained a few comments above the linked post.

I got and android and the Miio method, doen’t give me the token for the yeelight… I also tried the toolkit but this only gives me the token for the vaccum.

Is the the yeelight availlable in the mi home app or is it just in the yeelight app?I’m using both apps and my smart bulb is also in the mi home app. (I’m using the same account for both apps)

i used the very last build.
removed the binding and installed it new yesterday.
also tried with latest openhab2.3 snapshot

having problems with the colorMode too. i think the item should be a number instead of a string.

you need to add all lamps in the mihome app, then you can read the tokens with mitoolkit.
maybe try different phones if it dont works. i cant get the tokens on my xiaomi phone… but on motorola works fine

1 Like

@Caroline_O
Given final block not properly padded This error also indicates a wrong token.
I got the same error when using a previously valid token. Extracting the current token fixed this issue for me.

There seems to be a difference in response between a random token and a earlier token of a device. (with a random token, the device just does not respond at all, with an earlier valid token you get the padding error or invalid Json error)

I don’t exactly know why the device is changing tokens, I think even a firmware update can trigger it. Certainly a reset or change of wifi network will trigger a new token creation

Yes, I think this is an issue to be fixed. I’ll fix it in my next small update in the coming days

Thanks for your answer, but sadly this didn’t solved my problem.
I checked again if the token i used is the newest token (it was). Then I reseted the lamp and used the new generated token. But that didn’t worked too.