Xiaomi Robot new Device ID

[JirinSV]

Hi,
I'm trying to connect to my new vacuum cleaner that I received yesterday, but so far no luck with that.
It seems that my device has some strange device ID. Xiaomi Mi Robot Vacuum should have 0x02f2 (754), but I'm getting 984 (0x03D8).

INFO:mirobo.device:Sending discovery to <broadcast> with timeout of 5s..
INFO:mirobo.device: IP 192.168.8.1: 984 - token: b'51344c5942785736757a3133766a7836'

Firmware version of my device is: 3.3.9_003077.

When I try to connect it always ends up with timeout:

INFO:mirobo.cli:Debug mode active
ERROR:mirobo.cli:Unable to read the stored msgid: [Errno 2] No such file or directory: '/tmp/python-mirobo.seq'
DEBUG:mirobo.cli:Connecting to 192.168.3.100 with token 51344c5942785736757a3133766a7836
DEBUG:mirobo.protocol:Unable to decrypt, returning raw bytes.
DEBUG:mirobo.device:Discovered 984 18672 with ts: 2017-07-13 21:15:10
DEBUG:mirobo.device:192.168.3.100:54321 >>: {'id': 1, 'method': 'get_status'}
ERROR:mirobo.device:got error when receiving: timed out
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/mirobo/device.py", line 129, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out

Is it possible to add support for this device ID? I'm able to record communication between Robot and Xiaomi app.

[rytilahti]

Hi!

Huh, so it is still returning the token still, I thought the newer firmwares do not do that?! Anyway, can you check out the instructions for obtaining the token from here https://github.com/home-assistant/home-assistant.github.io/blob/next/source/_components/switch.xiaomi_vacuum.markdown and see if the token is the same?

edit: just to add, the device IDs do not matter anymore, every time the script it launched it does at first a discovery to fetch that information, so that shouldn't be the problem.

[JirinSV]

Will test it tomorrow and will let you know. I read in the meantime issue #14 which is probably the same problem.

[rytilahti]

Considering that you are getting the "unable to read the stored msgid" the issue in #14 should be fixed already, so this might be something different. Please report back though.

[JirinSV]

I was able to retrieve the token from my iOS device, but it also doesn't work with it. One note here, the guide points to the file "_mihome.sqlite" which is wrong, "USERID_mihome.sqlite" (where USERID are numbers) has to be used.
Token is different than the one recognized by discover command.
From what I understood there is a communication change in firmware 3.3.9, is this already in included or not?

[JirinSV]

I have tried the same token in the evening and now it works perfectly. I don't know if Xiaomi devices are checking IP addresses that try to reach it with wrong data and then black lists them for a while. In the morning nothing happened and I was receiving timeouts.
Thanks for your help. It would be great if you could update the readme file about the token retrieval. I can write the guide for iOS.

[rytilahti]

Glad you got it working! So you had two tokens, which one worked now correctly? PRs for updating the readme are welcome! (there's also an overlap with the documentation for the homeassistant component, so it should also be updated..)

I don't know if there is some sort of blacklisting going on, but using wrong sequence numbers could also cause, the request will be accepted only after a pause for a while. If someone knows how to "renew/refresh" the connection, help on fixing that would be very welcome.

[azogue]

Hi @jirijasa, I'm having the same problem, I think

I received mine today ;-), and I'm testing the HA integration, congratulations @rytilahti!
I think I've made a big mistake updating the firmware :-(, now I only get the timeout error...

The token I've recovered from an iOS unencrypted backup, and, as @jirijasa was saying, the token is in "USERID_mihome.sqlite" (where USERID are numbers), and you have to open the sqlite DB with a compatible tool to read it (I think the instructions talk about reading the files as plain text ¿?)
Also, the devtype and the serial numbers are 984 and 56063, respectively.

With the token, I've been able to integrate the switch in HA, and even create some template sensors from the switch attributes (anyone thinking about a Home Assistant component instead of a switch platform?), BUT:

After starting the robot with the HA switch, I've opened the mobile app to play a little with the fan speeds, and I think at that moment the timeouts have started. Now I can't retrieve the status ...

As I'm reading around here, the problem could be the timestamps?? They appear to be tz-naive but the official app has the timezone code (which is correct).
Also, blacklisting?? If so, why?? I didn't change the token...

As last resort, do you now how can I downgrade the firmware? (I think I know the answer to that, but I have to try)

[azogue]

OK, after reading #28, I've tried to set the start_id to a big number (9990), and it worked 👍
And after that, it appears it is working (now I'm playing only with the CLI)

So, how about set automatically the id near to 9998 when a timeout is received? Actually, It's working with bigger id's than 1e4 (I've tested it with numbers in the 1e8-9 order, so that changed.
Looks like the key is renewing the connection, but I don't know how.

[rytilahti]

Version 0.1.2 will 1) do a "discovery" for each send command separately and 2) will re-try up to 3 times when a send() fails, all while incrementing the ID by 100 for those calls, so the timeout problems should be fixed.

I don't understand what do you mean with blacklisting, if not that the robot will avoid responding to packets with the sequence ID it has already answered to?

Regarding to this being a homeassistant component, that is what I would like to see too, as it would make it easier to add support for other devices using the same communication protocol, e.g. what @syssi's recently merged PR did for the wifi plugs.

[azogue]

Hi @rytilahti,
Forget about blacklisting (I read it above, but it has no reason to be).
I'm increasing an internal id in a customized version of the switch platform in HA component (to test the services PR and fix some errors, like using DeviceException and setting self._vacuum to none when timeouts arise, in order to create the vacuum object with an increased id. It's working, but is far for perfect). If you push your solution (there are no new commits), I could test it with the last firmware.

Regarding HA integration, I was referring to a xiaomi_vacuum component (with sensors, services and a switch), but I think you're talking about a most generic xiaomi component, isn't it?

In that case, I suppose the yaml config would be some like that:

xiaomi:
- platform: vacuum
  name: Vacuum cleaner
  host: !secret xiaomi_vacuum_robot_ip
  token: !secret xiaomi_vacuum_robot_token
  sensors:
    - battery
    - status
    - fanspeed
    - cleaned_area
    - cleaning_time
    - error
- platform: plug
   # ...

Am I wrong?
But, I don't see why the grouping if no configuration is shared between products. I don't have any more xiaomi devices, so perhaps I'm totally wrong, but, is not unique the token for each product and account?
If there is a 'xiaomi hub' which control multiple devices, that could be a xiaomi_hub component, but the vacuum robot is a solely product by itself, and it's much more than a switch! (can't recall switches than can move with a joystick ;-)

[rytilahti]

@azogue I was just wondering what's the best way to expose those other devices (currently there are 3 open PRs from @syssi to introduce support for more devices sporting the same protocol!) to HASS. As they share similar discovery / handshake process, I had this thought that it would make sense to combine them inside one component somehow.

However, after looking into your PR and test-trying it for some time I think we can agree your solution is much better even if it will require boilerplate to add support for other devices in the future. I will make a comment on that PR.

P.S. xiaomi_gw/xiaomi is currently already used for the gateway hub component, which does device discovery for those. However, like you said, it's a hub not a standalone product, so it makes more sense there.

edit: I'm closing this issue now, as the original problem has been solved already in 0.1.2 release.

[azogue]

P.S. xiaomi_gw/xiaomi is currently already used for the gateway hub component, which does device discovery for those. However, like you said, it's a hub not a standalone product, so it makes more sense there.

I saw it later!

As you can see in the discussion over here, what is happening is the fusion of the botvacs (sounds like a b-series cyfy movie, hehe), so I think the new xiaomi devices should go in their respective natural locations, is not a problem at all, if all relay on your library to talk to the devices. All code relative to the talking is being shared here, and in the future you can try to make an auto-discovery which can trigger any xiaomi device encountered and auto-config it, that would be awesome and don't need to be inside only one HA component, as I believe.

[rytilahti]

@azogue I really like the fact they there are plans on a common interface for the bots, and I think users will also appreciate it when configuration and automation can be done consistently across different devices :-)

Speaking about the auto-config, some devices introduce themselves over mdns so that could work for netdisco (like it is done now for yeelights, I thought the robot also advertised itself at some point to me with 'rockrobo', but I can't see those advertisements currently in my network for some reason..) in this case too. I will be looking into this at some point in the future when I find some time to tinker.