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.

Sign up for GitHub

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

Jump to bottom

Unable to connect to cloudless Gen 2 Vacuum #162

Open
Hypfer opened this issue Jun 23, 2018 · 9 comments · May be fixed by #215
Open

Unable to connect to cloudless Gen 2 Vacuum #162

Hypfer opened this issue Jun 23, 2018 · 9 comments · May be fixed by #215

Comments

@Hypfer
Copy link

Hypfer commented Jun 23, 2018 •
edited
Loading

I'm having trouble connecting to my Gen 2 Xiaomi vacuum which is not connected to the xiaomi cloud.
I've followed this guide to set it up.

This library gets a timeout and returns Could not connect to device, token might be wrong
However, using the same token everything works well using the python mirobo utility found here.

miio version is the latest git master.
robot version is v11_001228
@Hypfer
Copy link
Author

Hypfer commented Jun 23, 2018

By looking at the miio log on the vaccum itself, I found out that calls by this library cause the following messages:

[20180623 11:03:52] [INFO] handle_mobile_msg
[20180623 11:03:52] [DEBUG]  msg: {"method":"miIO.info","params":[],"id":1}, strlen: 41, len: 41
[20180623 11:03:52] [INFO] Got miIO.info.
[20180623 11:03:52] [WARNING] miIO.info fail

But only on the first try after a reboot.
If I try again I get

[20180623 11:04:47] [INFO] OT protocol diagrams come...
[20180623 11:04:47] [DEBUG] look like a repeated msg:-3,1
[20180623 11:04:49] [INFO] OT protocol diagrams come...
[20180623 11:04:49] [DEBUG] look like a repeated msg:-3,101

The log of a mirobo connection looks like this:

[20180623 11:04:31] [INFO] OT protocol diagrams come...
[20180623 11:04:31] [INFO] handle_mobile_msg
[20180623 11:04:31] [DEBUG]  msg: {"id": 10, "method": "get_status"}, strlen: 34, len: 35
[20180623 11:04:31] [DEBUG] handle_mobile_msg, newmsg: {"method":"get_status","id":917357018}, strlen: 38
[20180623 11:04:31] [DEBUG] cloud/mobile cmd: {"method":"get_status","id":917357018}, strlen: 38, len: 38
[20180623 11:04:31] [DEBUG] ot_agent_recv_handler_one(): fd:15, msg:{"id":917357018,"result":[{"msg_ver":2,"msg_seq":6,"state":8,"battery":100,"clean_time":2594,"clean_area":40270000,"error_code":0,"map_present":1,"in_cleaning":0,"fan_power":75,"dnd_enabled":0}]} length:195 bytes
[20180623 11:04:31] [DEBUG] mobile_msg_callback, send back to mobile: {"result":[{"msg_ver":2,"msg_seq":6,"state":8,"battery":100,"clean_time":2594,"clean_area":40270000,"error_code":0,"map_present":1,"in_cleaning":0,"fan_power":75,"dnd_enabled":0}],"id":10}
[20180623 11:04:31] [INFO] callback_queue_issue() id: 917357018, to: mobile

@Hypfer
Copy link
Author

Hypfer commented Jun 23, 2018

By changing network.js#L305 to "get_status" it seems to send a useful answer according to the miio.log on the device.

Also, since the mirobo utility doesn't seem to keep track of the request id in a permanent storage, I guess that the last ID is somewhere inside the handshake?
Incrementing the request ID by 100 on each failed request as seen in network.js#L519 is a terrible "solution" to the repeated msg error.

@Hypfer
Copy link
Author

Hypfer commented Jun 23, 2018 •
edited
Loading

I was wrong. Apparently, python-mirobo does save the last msg id in some temporary file.
~/.cache/python-miio/python-mirobo.seq

@Hypfer
Copy link
Author

Hypfer commented Jun 23, 2018

Okay so the miIO.info command is only available on devices which are or were at some point connected to the cloud.
This results in the library not being able to work with said vacuum since it cannot detect that it is a vacuum.

I'd suggest providing a possibility to manually specify the device type.

@Algram
Copy link

Algram commented Jan 27, 2019

I am having the same issue with a Gen 1.

@Algram Algram linked a pull request Jan 27, 2019 that will close this issue
Open
@Algram
Copy link

Algram commented Jan 27, 2019

@Hypfer I have opened a PR that fixed this issue for me. Could you maybe try the branch and check if the vacuum V2 issue is fixed by this aswell? Thanks!

@Hypfer
Copy link
Author

Hypfer commented Jan 27, 2019

Works 👍

@rytilahti
Copy link

Also adding my comment from the linked PR here, in case you are running dummycloud the info works fine:

$ mirobo info
rockrobo.vacuum.v1 v3.3.9_003194 (28:6C:07:xx) @ 192.168.xx - token: 75xxxxxxxxx

@Algram
Copy link

Algram commented Jan 27, 2019

I for one do not want to use dummycloud. The last time I checked it needed internet access (ntp servers and stuff). My vacuum does not have internet access so it would not work in my case I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Don't call "miio.info" when a model was provided Algram/miio
3 participants
@Hypfer @rytilahti @Algram