miio --discover node issues

[philboycn]

xiaomi vacuum, miio --discover --sync cmd:

Device ID: 55388595
Model info: Unknown
Address: 192.168.8.1
Token: 7a6c4e46553032326c53365374413834 via auto-token

Support: Unknown
(node:94) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Call to device timed out
(node:94) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

please help me out..

[philboycn]

firmware version: 3.3.9_003074, updated 4 days ago..

[rafale77]

I am a bit surprised that you are getting an auto-token from yours. Mine is hidden and even after a reset, picking up per the instructions, it refuses to update.

Device ID: 55355676
Model info: Unknown
Address: 192.168.0.122
Token: ???
Support: Unknown

miio --update 55355676 --token 496535305450724B695A617537657448
INFO Attempting to update 55355676
ERROR Could not update device, token might not be correct. Error was: Call to device timed out

[jghaanstra]

Must be an incorrect token @rafale77 . I'm in the same boat, my Mi Robot is still on an older firmware and the app tells me there are no updates available. Running the update CLI command gives me this result.

miio --update 51...703 --token 694D4642...64149394C64
INFO  Attempting to update 51...703
INFO  Device updated

So this wont force the device to update. I'm guessing Xiaomi is very slowly rolling out the latest updates, especially for user that use the international app. It would be interesting to see if the latest update exposes the token which would make discovery a lot easier.

[rafale77]

I thought so too but I triple checked the token output after the reset and it was correct. I am wondering if the new firmware resets the token again during setup of the device.

My-Retina-Macbook:~ XXX$ miio --discover
INFO Discovering devices. Press Ctrl+C to stop.

Device ID: 55355676
Model info: Unknown
Address: 192.168.8.1
Token: 366c7769544d42776a5a346545787a63 via auto-token
Support: Unknown

(node:1482) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Call to device timed out
^C
My-Retina-Macbook:~ XXX$ miio --update 55355676 --token 366c7769544d42776a5a346545787a63
INFO Attempting to update 55355676
ERROR Could not update device, token might not be correct. Error was: Call to device timed out

[aholstenson]

From the error you are getting it looks like miio doesn't handle the error properly, which is a bug.

The problem comes from that Mi Vacuum is sometimes slow to respond to requests. I've had some issues where it doesn't show up during discovery. I'm guessing this is some sort of optimization done as it runs on battery.

And yes, after the setup the device will hide its token. Most newer devices and firmwares seem to do this as a security measure.

[rafale77]

Thanks. So is there a way to extend the timeout so that the token gets saved? Or is the token actually saved locally anyway in spite of the error?

Ran another test by extracting the comm from wireshark through the json and I am pretty convinced now that the token changes again when the device (vacuum cleaner) is setup into the account. The token appears invalid as the json does not get decoded.

[rafale77]

I can confirm that the token gets changed when one registers the vacuum into his account so resetting the vacuum cleaner to get the token no longer works with the newest firmware. I ended up making an encrypted backup of my ios device and went to look for the token which recorded in the account file of the app.

[jghaanstra]

But does it now also expose the token upon discovery, even after registration? If that would be the case it would actually be an improvement.

[aholstenson]

I'm not 100% that the token will actually be saved when the error occurs and there is currently no way of increasing the time out without changing the code. The default is to try a call 3 times with 2 seconds between the calls.

It's very interesting that the vacuum changes its token when it is registered in the Mi Home app. And bad news for this library. I'll play around with my own vacuum a bit and see if the same is true for the older 3.3.6_003061 firmware, but it'll probably be first next week.

[rafale77]

@jghaanstra
Unfortunately no it doesn't. There are alternate ways to get the token though as I found out using either an android or ios device and the mi home app. I did manage to get mine.
@aholstenson
Turns out it was not a miio bug... It was indeed the wrong token and it was due to the fact that the token had changed. 3.3.9_003074 resets it's token upon joining an account.

[jghaanstra]

@rafale77 I'm very much interested in what method you are referring to to obtain the token. Do you have a reference?

[rafale77]

This is what I did using a macos client

1. I setup my iOS device with the Mi-Home app.
2. Created an unencrypted backup of the device on my laptop using itunes.
3. Installed iBackup Viewer from here: http://www.imactools.com/iphonebackupviewer/
4. Extracted this file /raw data/com.xiami.mihome/_mihome.sqlite to my computer
5. Open the file extracted using notepad. You will then see the list of all the device in your account with their token.

[philboycn]

@rafale77 Is your token working by this way？

[rafale77]

@philboycn ... yes, I would not have posted it if it didn't work.

[olehs]

@rafale77 Thank you. Worked for me.
Token stored in the app was not the same I obtained just after Reset.
Looks like now they transmit it over cloud servers to clients.

[mbulandra]

Inspired by @rafale77, I managed to recover a key from My Home app on Android on RPi.

1. I have setup my Raspberry Pi 3 with RTAndroid and Mi Home app
2. Prepared ADB over the network connection between my laptop and RPi
3. Opened ADB shell and recovered the key from the app's configuration database

me@laptop:~ $ ./adb connect 192.168.xx.yy
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
connected to 192.168.xx.yy:5555
me@laptop:~ $ ./adb shell
rpi3:/ $ su
rpi3:/data/data # cd com.xiaomi.smarthome/databases/
rpi3:/data/data/com.xiaomi.smarthome/databases # sqlite3
SQLite version 3.9.2 2015-11-02 18:31:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open miio2.db
sqlite> .tables
android_metadata  devicerecord
sqlite> select * from devicerecord;

Here you get all the settings along with the token.

sqlite> .quit
rpi3:/data/data/com.xiaomi.smarthome/databases # exit
rpi3:/ $ exit
me@laptop:~ $

[philboycn]

@rafale77 Thanks a lot. It worked. So exciting. The token in .sqlite is one digit miss at the first of it. I was plan to try 1 to 0 to complete the token. fortunately succeed at the number 3... Thanks again !

[tibahut]

I can confirm the last firmware renews the token when I register the vacuum with my phone.
I add this steps for android users on Windows, with non rooted phone (works also with root), based on steps done by @mbulandra :

• Configure the robot with the Mihome application.
• Enable developer mode and USB debugging on the android phone and plug it into the computer.
• Get ADB tool for Windows : https://developer.android.com/studio/releases/platform-tools.html
• Create a backup of the application com.xiaomi.smarthome :
  .\adb backup -noapk com.xiaomi.smarthome -f backup.ab
• If you have this message : "More than one device or emulator", use this command to list all devices :
  .\adb devices
• And execute this command :
  .\adb -s DEVICEID backup -noapk com.xiaomi.smarthome -f backup.ab (with DEVICEID the device id from the previous command)
• On the phone, you must confirm the backup. DO NOT enter any password and press button to make the backup.
• Get ADB Backup Extractor : https://sourceforge.net/projects/adbextractor/
• Extract All files from the backup :
  java.exe -jar ../android-backup-extractor/abe.jar unpack backup.ab backup.tar ""
• Unzip the ".tar" file.
• Open the sqlite DB miio2.db with a tool like SQLite Manager extension for FireFox.
• Get token from "devicerecord" table.

[hrietman]

Reading the above comments I am not sure if it is fixed or if there is a fix? I am using miio and with a Xiaomi Wifi Smart Plug I get the same error (after a while, seems the device got offline/online):

UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 312998): Error: Call to device timed out

Any pointers on how to handle the error appreciated.

[hrietman]

Narrowed it bit down by catching the unhandled rejection:
Possibly Unhandled Rejection at: Promise Promise { <rejected> { Error: Call to device timed out at Timeout.retry [as _onTimeout] (/Development/xyz/node-red/node_modules/miio/lib/device.js:225:18) at ontimeout (timers.js:386:14) at tryOnTimeout (timers.js:250:5) at Timer.listOnTimeout (timers.js:214:5) code: 'timeout' } } reason: { Error: Call to device timed out at Timeout.retry [as _onTimeout] (/Development/codecentric/node-red/node_modules/miio/lib/device.js:225:18) at ontimeout (timers.js:386:14) at tryOnTimeout (timers.js:250:5) at Timer.listOnTimeout (timers.js:214:5) code: 'timeout' }

Maybe it helps

[SebastianDaehnrich]

I have the same problem on the latest firmware.
I got the token from iBackup Viewer but its not working.
Somebody has an idea?

[jaumard]

@tibahut I try your method but I can't create a backup without any password (because my device is crypted)

I try this java.exe -jar ../android-backup-extractor/abe.jar unpack backup.ab backup.tar "123456" where 123456 is the password I put but then the abe.jar crash

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.RuntimeException: java.lang.NumberFormatException: For input string: ""
	at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:444)
	at org.nick.abe.Main.main(Main.java:128)
	... 5 more
Caused by: java.lang.NumberFormatException: For input string: ""
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:592)
	at java.lang.Integer.parseInt(Integer.java:615)
	at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:282)
	... 6 more

PS: I'm not on windows but on mac but should work... and I'm not root on my phone

[syssi]

@SebastianDaehnrich Can you tell me the length of your extracted token? It must be 32 hexadecimal characters. It looks like the iOS app stores 96 characters (encrypted token?) now. Can you confirm this?

[jaumard]

@syssi Android side it's still 32 characters

[syssi]

Luckily, yes! :-) I hope it won't change, too.

[jaumard]

But doesn't change the fact that it doesn't work anymore with latest firmware :(

[androidand]

I am getting the same issue, firmware 3.3.9_003077 (attempted update today from the iOS app, no new firmware found). The IP is fixed.

miio --discover
Device ID: 6464...5
Model info: rockrobo.vacuum.v1 (vacuum)
Address: 192.168.x.x52 (rockrobo)
Token: 3947........4d78685........f676e via stored token
Support: At least basic

(node:67191) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Call to device timed out

miio --update 6464...5 --token 3947........4d78685........f676e
INFO Attempting to update 6464...5
ERROR Could not update device, token might not be correct. Error was: Call to device timed out

Tested with node 8.4 and 6.5. So, I seem to get a token, 32 length, then it says the "token might not be correct".

[0xcb49]

@androidand You can try this http://forum.smartapfel.de/forum/thread/370-saugroboter-xiaomi-mi-robot-vacuum-token-auslesen/?postID=7021#post7021 to get the right token. It worked on my device.

[aholstenson]

Things should be a little bit better with connectivity in version 0.15.0, the token extraction issue will still be there due the changes outlined in this issue. I'm going to close this issue as I've opened #92 to track pure discovery issues and #93 for token issues.