Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[miio >= 0.15.1] Mi Vacuum Cleaner Robot connection issue #94

Closed
jghaanstra opened this issue Jan 23, 2018 · 19 comments
Closed

[miio >= 0.15.1] Mi Vacuum Cleaner Robot connection issue #94

jghaanstra opened this issue Jan 23, 2018 · 19 comments
Labels

Comments

@jghaanstra
Copy link

jghaanstra commented Jan 23, 2018

This is a new issue for the Mi Robot Vacuum Cleaner. It seems for some users it works and for others it doesnt (anymore). I had it working fine until I installed firmware 3.3.9_003077 on the robot, it then stopped working. I was hoping the new miio version would fix the issue but for me it doesnt. So this Github issue is intended to gather as much information as possible that can explain the difference in results. It would be nice if more people could chip in to see if we can find a pattern.

  • Robot firmware: 3.3.9_003094
  • Xiaomi server: China Mainland
  • Router: Asus AC68U
  • DNS: Google (8.8.4.4) and OpenDNS (208.67.220.220)
  • Has it worked previously: Yes
  • Token retrieved: Rooted Android phone and viewed the table devicerecord in miio2.db to get token after connecting to WiFi
  • Other: I also see this in the devicerecord table in the miio2.db field extraInfo: {"isSetPincode":0,"fw_version":"3.3.9_003094","needVerifyCode":0,"isPasswordEncrypt":0,"is_factory":false}

I'm including DNS info as some have suggested that timeout issues are related to certain DNS services being blocked by Xiaomi. It does not seem relevant in this case as it's LAN traffic but who knows ...

When using miio.device() in the example.js with the token added manually in the code the following error is thrown:

removed
@aholstenson
Copy link
Owner

Thank you for the details! As you said it would be great if more people could add details about their own setups and we'll see if we can work out what's wrong together.

@jghaanstra
Copy link
Author

jghaanstra commented Jan 24, 2018

Here is some extra info. I had to remove tokens.json from my Windows profile to have miio CLI-tool discover the robot again. Using the tokens update command does not seem to regenerate a new tokens.json anymore. But when setting the token manually in the CLI-tool or in example.js I still recieve the error Could not connect to device, token might be wrong . I have reset my vacuum cleaner, reconnected it to my WiFi, retrieved the new token again from miio2.db but to no avail. The error remains. Below is the complete debug log. I'm still clueless as to why this is not working for my vacuum cleaner.

removed

Sometimes when trying to connect to the robot I get a lot of the errors as below. This seems sporadically but afterwards I'm seeying data from the robot coming in.

removed

@aholstenson
Copy link
Owner

Thanks! That gives me a few ideas. It looks like the library connects to the vacuum sometimes then. Which is confusing. The dwaal-error is unrelated, it was for an experimental naming feature, but it doesn't play nice with Windows so I have removed it in 0.15.2.

But if it works sometimes it might an issue with the vacuum sleeping or otherwise not responding to network requests. But I would think that it wouldn't respond to the initial handshake if that was case.

I'm going to look into two things based on your log:

  1. Check that the token is correctly set before the first call to miIO.info
  2. The delay and number of retries for the initial call to miIO.info should be increased to see if it helps

@350d
Copy link

350d commented Jan 25, 2018

I've installed latest miio on my new Pi setup and my Mi Robot stops working too. Here is my error report seikan/homebridge-xiaomi-mi-robot-vacuum#15

@aholstenson
Copy link
Owner

@350d Thanks for adding some additional details! I don't think that plugin has been updated to be compatible with 0.15.x yet, some work is needed by the plugin author to support the new version. That might affect things for you.

@aholstenson
Copy link
Owner

@jghaanstra I've added a bit more debug info to the master-branch, if you have the possibility it would be great if you could test it out. The new debug-info should provide some more clues to how tokens are used and which ports is used to receive data.

I'm especially interested in the difference between the cases where you are able to connect and those where you are not.

@jghaanstra
Copy link
Author

jghaanstra commented Jan 25, 2018

@aholstenson thank you for your efforts. Below are some logs again, one of a not working discovery attempt (DUMP 1) and one of a working connection using example.js and setting the token as option of miio.device() (DUMP 2). I noticed that I was never able to connect using the local token storage. I have added tokens.json manually as miio tokens update does not seem to work (DUMP 3) although I can see in the log it's using the correct token from tokens.json.

When setting the token as option of miio.device() manually in example.js I get a succes ratio of about 5%. I have added a log (DUMP 4) using the working example.js where it does not connect. The error suggests the token might be wrong but this is not the case as it works with this token sometimes.

Another strange thing, I have installed the latest Mi Home app and the token fields in miio2.db are all empty for my devices. It seems Xiaomi is gonna make it harder to control their devices through third party integration.

Anyway, here are the dumps:

DUMP 1 - token registered in tokens.json and trying discovery through CLI or example.js (gives the same error)

removed

DUMP 2 - working connection with example.js and token as option in miio.device()

removed

DUMP 3 - using miio tokens update

removed

DUMP 4 - working example.js with token as option of miio.device() but no connection

removed

@aholstenson
Copy link
Owner

Thank you for taking the time to put that together! Sadly I can't quite figure out what's wrong, it just seems like the vacuum sometimes doesn't respond, almost like it's a sleep mode where it doesn't listen to the local network.

I've pushed 0.15.3 and 0.15.4 which contains some fixes to issues with token handling when they are being updated via the CLI. It shouldn't affect the overall connectivity though.

If anyone else is having similar issues or ideas about what is wrong, please do add details to this issue. Any information helps!

@jghaanstra
Copy link
Author

I was afraid of that. Thanx for putting in the effort though. When I find some time I'll see if I have more success with the python-miio, a comparable library written in Python. If this shows similar behaviour I can pinpoint it on my network or configuration, if this works I can pinpoint it to the library and comparing them would be the next step.

One last question, on what Xiaomi server have you set up your Mi Robot?

@aholstenson
Copy link
Owner

Sounds good, comparing is always a good thing.

I think my vacuum is connected to the old US-server. I have also avoided updating the firmware, so I'm probably running a really old firmware by now.

@jghaanstra
Copy link
Author

jghaanstra commented Jan 26, 2018

In retrospect I should have stayed on an older firmware too.

Could you explain a little what the difference is between the miio discovery and miio.device() in relation to the token? Discovery seems to always detect my device when I have not set the token in tokens.json, when I do it never finds my device. While miio.device() only connects works 5% of the time either using token in token.json or set it manually as option.

I'm trying to pinpoint where it fails. Looking at the log it doesnt seem to be a sleep issue to me but the robot just does not respond to {"id":1,"method":"miIO.info","params":[]} command most of the times and than destroys the socket.

WORKING miIO.info COMMAND

removed

NON WORKING miIO.info COMMAND

removed

@aholstenson
Copy link
Owner

There is currently an issue with discovery treating connection failures as non-existent devices. I'm rewriting the discovery a bit right now, so in the next version it will return a "placeholder device" that can be used to update the token via code.

I've been looking at your dumps as well, did some manual testing to verify that the token has been set and that the checksums are correctly calculated with it. Everything checks out, so nothing new to report from my end, sorry.

I also read through rytilahti/python-miio/issues/92 where a few users seem to have the same connection issue. Most seems to have an issue with their token though, which isn't the case for you.

@jghaanstra
Copy link
Author

Although the token is correct I'm not excluding it as a possible cause somehow. The current results of not connecting could for many users suggest the token is not correct (the actual error of your library even suggest so, and perhaps miio-python shows a similar token related error). I need to set up a python enviroment to test this in further detail, but I'm not to familiar with python so this will take me some time.

Something else I want to add to this issue for further troubleshooting. I have noticed that when I try to connect to the device it mostly works the first time after some cooling down periode. Trying to connect shortly after will not work. The suggests it's also not a sleep issue (but more an awake issue :-) ).

@jghaanstra
Copy link
Author

Instead of setting up a new linux based enviroment I went with WinPython and have setup python-miio on my Windows machine. I can confirm that I do not have any issues with connecting to the Mi Robot using python-miio.

This pinpoints my connection issues to this specific miio library and the next step is comparing this library against the python-miio library. This is gonna be challinging for me as my javascript knowledge is limited and my python knowledge is pretty much non existent. But it's a step ahead ...

It would be great if more knowledgeable users with a similar issue could chip in though.

@aholstenson
Copy link
Owner

That's very interesting. Does running python-miio with debug output show anything interesting? Might provide a clue to the difference between the two libraries.

@jghaanstra
Copy link
Author

jghaanstra commented Jan 27, 2018

Here is some debugging output:

removed

Something I noticed is the miio-python works with sequence numbers for the commands. Not sure why but if this is to prevent some sort of caching I could match that with the fact that I'm able to connect once with this library and then it doesnt work for some time. That's a long shot though.

Another unrelated question, how do I retrieve the status. It seems device.state() returns a bit of info, but not the actual state anymore.

@aholstenson
Copy link
Owner

Thanks, I noticed the sequence numbers as well. I pushed a change to the repository does something similar on errors, could you see if that helps with the connection issues?

Regarding the state, I've added a few examples to the docs here: https://github.com/aholstenson/miio/blob/master/docs/devices/vacuum.md

I need to document the vacuum a lot more though, the state has been split into several different capabilities, such as one indicating if is charging, one if its cleaning, one if it has an error and so on. It's on my todo, going to try to get to soon.

@jghaanstra
Copy link
Author

JACKPOT!!!

I'm able to connect now every time using the latest commit. I do notice the first connection is slightly faster then the following ones. I'm assuming your implementation of sequence numbers kicks in after it fails. Not too big a deal but it could be optimized to always use some sort of sequencing to avoid this issue. Thanx a million for figuring this out!

@aholstenson
Copy link
Owner

Awesome!

The fixes have been pushed to NPM in version 0.15.5. Closing this issue and then we can see if we can do some optimization in a later version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants