xiaomi vaccum cleaner not responding #92
Comments
|
Unfortunately I have no solution for this problem, but let's keep it open for now. |
|
same here: `DEBUG:miio.protocol:Unable to decrypt, returning raw bytes. During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
Is this with 0.3.0 or with an earlier release? If with an earlier one, could you try and update (we have changed the handshake only to send a single discovery packet, as sending multiple caused some sort of flood protection on some devices)? |
|
Will check later today when come back home. Can you please remind me how can i check the version ? mirobo --help or mirobo --version ? |
|
mirobo --version to check version. but i'am on 0.3.0 and have a similar error. |
|
I have version 0.2.0, so updated just right now to version 0.3.0, and tried it out. |
|
Same here. Using mirobo version 0.3.1. I reset my vacuum, did the discovery: $ mirobo discover --handshake 1...and got back a good token: INFO:miio.device:Sending discovery to <broadcast> with timeout of 5s..
INFO:miio.device: IP 192.168.8.1: 986 - token: b'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
INFO:miio.device:Discovery doneHowever, when I try to use this token (with the correct IP): mirobo --ip 192.168.1.130 --token b'xxxxxxxxxxxxxxxxxxxxxxxxxxxx...I get the same stack trace: ERROR:miio.vacuum_cli:Unable to read the stored msgid: [Errno 2] No such file or directory: '/tmp/python-mirobo.seq'
ERROR:miio.device:Unable to discover a device at address 192.168.1.130
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/bin/mirobo", line 11, in <module>
sys.exit(cli())
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 1043, in invoke
return Command.invoke(self, ctx)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum_cli.py", line 86, in cli
ctx.invoke(status)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum_cli.py", line 116, in status
res = vac.status()
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum.py", line 99, in status
return VacuumStatus(self.send("get_status")[0])
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 165, in send
self.do_discover()
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 118, in do_discover
raise DeviceException("Unable to discover the device %s" % self.ip)
miio.device.DeviceException: Unable to discover the device 192.168.1.130Incidentally, sometimes, I'll get this response instead: ERROR:miio.vacuum_cli:Unable to read the stored msgid: [Errno 2] No such file or directory: '/tmp/python-mirobo.seq'
ERROR:miio.device:Got error when receiving: timed out
WARNING:miio.device:Retrying with incremented id, retries left: 3
ERROR:miio.device:Got error when receiving: timed out
WARNING:miio.device:Retrying with incremented id, retries left: 2
ERROR:miio.device:Got error when receiving: timed out
WARNING:miio.device:Retrying with incremented id, retries left: 1
ERROR:miio.device:Got error when receiving: timed out
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 200, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 200, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 200, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 200, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/bin/mirobo", line 11, in <module>
sys.exit(cli())
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 1043, in invoke
return Command.invoke(self, ctx)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum_cli.py", line 86, in cli
ctx.invoke(status)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum_cli.py", line 116, in status
res = vac.status()
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/vacuum.py", line 99, in status
return VacuumStatus(self.send("get_status")[0])
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 222, in send
return self.send(command, parameters, retry_count - 1)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 222, in send
return self.send(command, parameters, retry_count - 1)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 222, in send
return self.send(command, parameters, retry_count - 1)
File "/Users/abach/.local/share/virtualenvs/miio-Q_DY263b/lib/python3.6/site-packages/miio/device.py", line 223, in send
raise DeviceException from ex
miio.device.DeviceException |
|
Just tried running the same command in debug mode and got this: INFO:miio.vacuum_cli:Debug mode active
ERROR:miio.vacuum_cli:Unable to read the stored msgid: [Errno 2] No such file or directory: '/tmp/python-mirobo.seq'
DEBUG:miio.vacuum_cli:Connecting to 192.168.1.130 with token 5a653170446642364f4c6d37384d7761
DEBUG:miio.protocol:Unable to decrypt, returning raw bytes.
DEBUG:miio.device:Got a response: Container:
data = Container:
data = (total 0)
value = (total 0)
offset1 = 32
offset2 = 32
length = 0
header = Container:
data = !1\x00 \x00\x00\x00\x00\x03\xda\xbe\xa4Y\xffTO (total 16)
value = Container:
length = 32
unknown = 0
devtype = 986
serial = 48804
ts = 2017-11-05 18:11:27
offset1 = 0
offset2 = 16
length = 16
checksum = \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff (total 16)
DEBUG:miio.device:Discovered 986 48804 with ts: 2017-11-05 18:11:27, token: b'ffffffffffffffffffffffffffffffff'
DEBUG:miio.device:192.168.1.130:54321 >>: {'id': 1, 'method': 'miIO.info', 'params': []}
ERROR:miio.device:Got error when receiving: timed outThe |
|
Sounds like these folks are having a similar issue: aholstenson/miio#59 |
|
Got my case figured it. At some point, it looks like the token changed on me; rediscovered it from an iOS backup and everything started working. |
|
@bachya Had the same problems: Then extracted token from android-apk/sqlite-db, it was a different token, so tried that with mirobo and it worked immediately. |
|
I just upgraded to v0.3.1 and am still seeing intermittent connection problems (I wonder if the robot is shutting down wifi periodically?). Not sure if what I am seeing is exactly the same as the OP, but it definitely works some of the time, and fails to connect other times. When a status request fails I am seeing this; It will fail like this for 5-10 times and then all of a sudden work; |
|
@sumnerboy12 How often are you requesting information from the vacuum? Maybe it has some sort of protection mechanism when too many requests are made consecutively? :-) @MatsKarlsson that's a good catch, that the token extracted from the device will not work (anymore, if it ever did with newer FWs) at all! |
|
I did wonder that, but I have found that making a request after > 24hrs still results in this error (sometimes). When it starts working I can fire off requests quite rapidly (1 per sec) and they all come back. Then after a while it seizes up and remains that way for a number of minutes. |
|
Ok, good to know. I'm not sure how to start debugging that though, the device remains connected to the network all the time though, I suppose? |
|
The device should be connected - it is sitting in its dock under my desk and there is a Unifi UAP directly above it. But I am wondering if it periodically disconnects to save battery or something? I have noticed that while it is running it re-connects (I have an alert whenever my DHCP server assigns an IP address) quite frequently, sometimes 4-5 times during a clean. |
|
UPDATE: still exhibiting this behaviour with v0.32. |
|
Does anybody managed to get this working with the latest firmware, The library correctly exchanges handshake, and fails with timeout when trying to send method. Token is extracted from android app, I've already tried to reset the device and send those with new token, but no luck so far. |
|
@mariuszluciow I have been running it all the time with that firmware without problems, also using a token extracted from the android app. @sumnerboy12 unfortunately I have no idea with regards to its network behavior, I have not been keeping track on that. Is your robot allowed to communicate with the xiaomi servers or are you keeping it locked away from the internet like I do? |
|
My robot is on my iot vlan with no internet access. Seems strange that only
a few of us are having this problem.
…On 10 Dec. 2017 11:06, "Teemu R." ***@***.***> wrote:
@mariuszluciow <https://github.com/mariuszluciow> I have been running it
all the time with that firmware without problems, also using a token
extracted from the android app.
@sumnerboy12 <https://github.com/sumnerboy12> unfortunately I have no
idea with regards to its network behavior, I have not been keeping track on
that. Is your robot allowed to communicate with the xiaomi servers or are
you keeping it locked away from the internet like I do?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE046mzrKYjpYyvmw3lECiAQSmBaIixAks5s-wRWgaJpZM4P-KGY>
.
|
|
@rytilahti I've installed the https://github.com/ioBroker/ioBroker.mihome-vacuum - surprisingly the iobroker is able to talk with my vacuum. I will take a look later what's the difference between this lib and the iobroker plugin. |
|
Updated error message after upgrading to latest version; |
|
So it looks like the robot just stops responding periodically. Doesn't seem to matter if it is on charge, or in use. It will work for a few minutes and then stop for a few minutes. |
|
And the same log, with debug enabled (in case there is something else in there that might help explain); |
|
Sorry to spam this issue, but just tried again and got the same error that I posted previously (26 days ago), which is different to the one I just posted above. Very odd. |
|
Can't reach my mirobo #145 when I see this. I Downgrade to construct==2.8.16.. But I have new error.. |
|
Hi guys, I've faced the same timeout issue. It turned out that my token had changed. I did a full factory reset (home+reset button), connected to the mi robot wifi, ran a discovery and got back a token. That token worked. However, when I setup (no firmware update) my mi robot in the MI home app (iOS), discovery didn't work anymore using the previously obtained token... That made me curious what might have changed so tried the android root method (https://github.com/jghaanstra/com.xiaomi-miio/blob/master/docs/obtain_token_mirobot_new.md) and look! another token was displayed! I gave it a try and it worked again. |
|
@zhkufish that is another issue, if the problem still exist please open a separate issue for that. @mapl when you set it up in the mobile app, the robot will be provisioned with a new token, thereby making the old one invalid. It should also be noted that the newer firmware versions do not allow token extraction at all, but one has to resort to extracting it from a backup. The procedure is described in the documentation: https://python-miio.readthedocs.io/en/latest/discovery.html#tokens-from-backups . |
|
It wasn't clear enough to me as I assumed the token will never change. Once you have the token you're ready to go. Thanks for pointing that out |
|
Yeah, I think it would be nice to have a sort of FAQ or most common problems and possible solutions to them in the documentation. So if anyone is interested in writing some documentation, that could be something to contribute to :-) |
|
UPDATE: I moved my vacuum to an internet-accessible VLAN and now I can continuously connect with no issues. I am polling the vacuum every 10s and it seems to be rock solid. I re-tried moving back to my isolated VLAN (for IOT devices) and had the same connection issues as before. I am guessing the vacuum is trying to phone-home and is blocking the connection handler/port/something while this attempt times out. And therefore I can only get through locally if I happen to attempt a connection outside of this timeout period. Is anyone else running their vacuum in an isolated VLAN? |
|
@sumnerboy12 I'm running mine in an isolated system, although I let it do DNS requests but do not let it do anything else. Anyway, your findings seem to be similar what I just experienced while reading the logs directly out from the vacuum; when afterwards it will seem to do some sort of initialization routine: |
|
Your tip for allowing DNS requests seems to have worked (initially at least). I moved the vacuum back to my IOT VLAN (with no internet access) but enabled outgoing DNS requests. I can now reliably access the vacuum using |
|
Argh...spoke too soon. After half an hour or so of good connection it has since been broken again. Looking in the logs it seems to connect OK for about 60s and then I get 6 mins (almost to the second) of dead time. I am polling the device every 10s to retrieve the state and publish to MQTT. |
|
Ah, sorry if I misled you, I just mentioned allowing DNS requests as it is in my current setup. I'm getting also those timeouts now and then, and I think the reason is indeed that the vacuum cannot communicate with their servers. If someone here is having this problem even when having the vacuum connected to the cloud, there might be also other problems there in the protocol implementation. |
|
No need to apologise! I am prepared to try anything at the moment :). My timeouts are definitely not occasional, they seem to be pretty consistent - around 60s ok, then 6 mins (to the second) timing out, repeat. For now I have just given the vacuum full internet access from my IOT VLAN thru the firewall. I will keep watching this thread with interest. BTW - thank you for the fantastic library!! |
|
I’m having the exact same problem. I’ve placed the vacuum gen 2 onto network that doesn’t have internet. Mirobo works sometimes and sometimes not. HASS mostly has a lot of failed messages but once in a while it can get a successfully api request in. So allowing DNS doesn’t work either? |
|
Didn't seem to for me, no. The robot must be blocking the API listening port while it tries to connect to the Xiaomi servers, which seems to take 6 mins to timeout on my robot. It then re-tries about a minute later, meaning the majority of the time it is blocking access from openHAB/HA. |
|
What kind of isolation you have in your network? Are you sending ICMP unreachables and TCP resets back on connection attempts? If not, maybe that could help to speed up the timeouting, considering the robot runs a linux kernel. And you're welcome, it's nice to hear that people find it useful :-) |
|
Unfortunately networking is not my area of expertise. I am running a Unifi USG with pretty simple firewall rules to isolate the IOT VLAN and that is about it. I will do some reading to see if I can implement some additional rules as you describe, to try and shorten the timeout. |
|
@rytilahti you are a genius. I did some reading and up-skilled a little on firewall configs. As a result I changed my IOT VLAN outgoing firewall rule from drop to reject and now the vacuum is not experiencing the 6 min time outs. I left it running overnight and only noticed the occasional (quick) timeout. Many many thanks for your helpful suggestion! |
|
Glad to hear you got it working! It won't indeed fix it completely, but it is not so terrible (and I think usually the second try will go through like always?). Maybe that's something to add to "Common problems"/FAQ section of the docs 👍 |
|
Yep, might be worthwhile, as I can imagine there are quite a few users that wish their vacuum to be on an isolated VLAN, rather than broadcasting their house floor plans to some remote servers in China! |
|
PRs are welcome! ;-) |
|
Is it as simple as telling iptables to reject with tcp reset and icmp unreachable for any forwards??? I tried. But I suspect I need to do the same for DNS requests. Since DNS request isn’t a forward. Could you show us the iptable commands? |
|
Heeey, its NOT construct related! Everyone upvote the fanfare emote! |
|
I'm having the same problem (running in an isolated VLAN), but unfortunately I don't have the option to "reject", only "block". Do you have any other ideas that may work around this? |
|
Hi all. It’s working much better now!!!! Pretty much had to block all forwards with reject and then block dns request since that hits the gateway and is consider local. |
|
See my comment in regarding to these errors: home-assistant/core#11048 (comment) -- PRs for adding "troubleshooting" or "FAQ" to the docs including this information would be greatly appreciated! |
Hi,
I am using your mirobo library to start and stop my xiaomi mija vacuum cleaner. It works great, except the case when the vacuum is not being called for longer period of time (day/two).
Then when I try to start the cleaner using your library I get following errors.
If I try about 3 times in a row, it start to work again, and works fine.
It looks like the vacuum goes to sleep maybe ?
The text was updated successfully, but these errors were encountered: