Xiaomi Vacuum Cleaner robot timeout / unavailable #9013
Comments
|
I see, those are a lot of errors... Well, for now there isn't a solution for lazy botvacs, and I think these problems have to be handled within the I'm understanding that you normally can access the bot and control it from HA, but sometimes you enter in that bad-update loop for quite some time, I'm correct, @olskar ? I myself have some of these bad updates from time to time, but I chose to ignore them, because I hadn't the time to investigate and, anyway, in practice, they do not pose any problem to the botvac control... logger:
default: warn
logs:
# Hide botvac connexion errors which happen sometimes:
homeassistant.components.vacuum: error
mirobo.device: criticalSo you'll never see the messages, but that's obviously not a solution for the problem. I could imagine some sugar-code in the HA component to handle these without so many logging, remembering the last good update and so, but it would be just that, not a real solution whatsoever. |
|
Ok, I reopened it cause it seemed the person in the old issue resolved it by having the right token, but I got the same error even with the right token. If the error should be resolved in python-mirobo, I agree opening an issue there is the right way. Do you know if this constant behavior might have a negative impact on performance in Home Assistant, or is it just cluttering the logs? |
I think there is no real problem; if so, you could see some 'reset timer' in the logs or some side effects in cpu or memory usage, but it's not the case. That's why I chose to ignore them by now... |
|
Same problem here. |
|
For some reason the vacuum is not always responsive to the initial handshake, but the reason is not yet known. This may be, however, related to this problem: rytilahti/python-miio#48 |
|
The same issue is discussed here I think: aholstenson/miio#59 |
|
Also have this log issue, though it does not seem to affect the operation of the vacuum at all. So for now I will ignore the log entries! |
|
For those who are ignoring the messages, I had to change the logger settings (see post from @azogue) since the update to 0.57. In the last line, I had to change
|
|
Started seeing in logs today (not sure if related to bump from 0.57 or was there all along): |
|
That's not related to this issue, the backend library got bumped without converting the code to use the new package name (the first warning) and |
|
@ferdydek I have the same issue in my log. |
|
The solution is to avoid calling |
|
@rytilahti But I don't call dnd, I have the Xiaomi Mi Vacuum component active in my configuration, I haven't done anything else. Is there something I can do to fix this? |
|
@joq3 there is nothing broken, its just log info, not actual drop in functionality. |
|
@joq3 it is coming from the platform requesting @ferdydek the "unable to discover" comes from the library indeed. At the moment the library will try to do a discovery every time before it sends a command to the device, why it fails sometimes is unclear. The tests for this broke as calling |
|
I still get those errors even with #10839 merged :/ @rytilahti |
|
Yeah me too. |
|
That PR fixes just deprecated warnings which is unrelated to unavailable/timeout issues, I just linked it here as people started discussing about those here. The cause for timeout / unavailable issues is unknown and may be related to local network setups. |
|
I have similar impression as @rytilahti regarding the cause of the timeouts. I do get from time to time "Can't upload the map die to low connection speed. Check your network" in HiMome App just after the "Getting info..." disappears. I don't think it has anything to do with my local LAN/WLAN, rather suspect somewhere in the process of getting information a query to Chinese mi servers is passed and that is causing a cascading timeout. |
|
I think there are users having this problem even when they have blocked the external network access for the device, so that cannot be the only reason. To debug this, we would require testing through various versions to see at what point it stopped working (git bisect may help here) to pinpoint that change. |
|
Just chipping in here. I dont use home-assistant but the same issue occurs on a nodejs library (miio) to control the Xiaomi Mi Robot Vacuum Cleaner. It was introduced with the lastest firmware update of the device with version number 3.3.9_003077. It's described here: aholstenson/miio#59 I lack the knowledge to do a proper inspect of the traffic with a MITM attack but that seems the only way to really troubleshoot what's happening. |
|
@jghaanstra The issue you are referring to is closed. You should consider reopening the issue, if it isn’t solved. |
|
Getting time-outs from the device just means that the device is not answering for a reason or another, there's no simple way to pinpoint what is causing this, but the 3077 firmware incorporated more strict checking of the communication (incl. order of messages, thereby increasing That being said, there may very well be something that's been overlooked, but it is not so simple to find out the real causes on real use-cases with heterogeneous network setups. For many python-miio (or miio in JS) is working just fine, where-as some encounter problems with no apparent / easy to find out reason. If someone has ideas how to debug these issues please report into issue tracker of those upstream projects where possible, thanks! |
|
Just received a new Mi Robot - was getting this issue on the first setup in HA. Unavailable in UI and timeouts in the logs. 2017-12-22 09:41:12 ERROR (SyncWorker_0) [miio.device] Got error when receiving: timed out 2017-12-22 09:41:12 WARNING (SyncWorker_0) [miio.device] Retrying with incremented id, retries left: 3 |
|
I have the same issue. It can't connect to the Xiaomi Vacuum from HomeAssistant, but the mirobo Python library works like a charm on my Mac. (with the same IP + token). Anything I can do to help debugging this issue? |
|
@danielpalstra your errors are not related to this issue. I guess the other issues were fixed with your update and you are left with the point 3 below. But this is not the issue for that problem. I think we need to close this issue as it begins to suck up all possible issues with miio.
|
|
I think those may be related, but as this issue has started to cover so many different issues, it's starting to get hard to keep track on all of it. Thanks for summarizing it all to those three points, however, to my understanding it was only the point 3 what was being tracked in this issue, those two others being just unfortunate, unrelated problems. Number 2 was never tracked here (in homeassistant's issue tracker), and I think the fix is still to be released with the next homeassistant release. The insight that it works with the mirobo tool is an interesting one though, as if that's true then there must be a way to fix it and that the problem has to have something to do with the state handling (the mirobo tool keeps just the msgid stored between executions where-as the platform keeps the whole instance around). What makes it hard to debug is 1) different people have different kinds of network setups, and they all think they are hit by this issue even if it may be just caused by their network setup and 2) this is working for quite a few people just fine, or so I'd assume. |
|
Hey guys, |
|
@rytilahti how can I help to gain more insight into "issue 3"? |
|
I am having the same issues after updating Home Assistant to v.60. The Mi Vacuum shows up as unavailable. Before the update everything worked great! |
|
Same issue as above users. EDIT: My original reply was beyond useless. I have solved my issue and will post it here in hopes of helping someone. My Hass.io version is 60.0. My problem was I grabbed my token from my iOS device using a .sqlite DB explorer and got a 96 character token. This was not working for me, so I used miio (miio --discover) and got a 32 character token. I tried using this token, but still not working. I would run --discover after pairing the device to my network and my MiHome app, but the token would should '???' when I ran 'miio --discover'... weird. The solution for me was to take the original 96 character token and decode it to a 32 character token. I forget the website I used, but there are probably a hundred of them that can do the same thing. |
|
Getting the token is described in https://python-miio.readthedocs.io/en/latest/discovery.html#tokens-from-backups . The most reliable way is to extract them from backups, and works with all supported devices. Tokens of vacuums have not been discoverable through other means for a while now. The @danielpalstra considering it works in the console, it most likely has something to do with either 1) timing or 2) msg id -- you could enable debug mode and check the timing between the handshake and the status request, maybe the time difference is too great and the robot ignores the request because of that. For message ids, they should always be incremented, so if you see out-of-order msgids that could be something to investigate. |
|
@rytilahti took a spin with the dev Docker image and it seems to be working better. Will double check network and time settings. |
|
Is this perhaps solved by #11232 ? Haven't received any error messages after upgrading python-miio to 0.3.3 Edit: No, still same problem :( |
but since I have updated to HomeAssistant 0.63, I receive the same error: |
|
Please make sure you are using the latest version of |
|
By updating to python-miio to 0.3.6 solves the issue but HA downgrades the library on boot always: |
|
You could start HA by |
|
Yes, I have updated the |
|
Still getting: info: There is no issue with functionality or sensors. Vacuum works fine. |
|
This is fine. The device doesn't respond sometimes. The second try / retry was successful in your case. |
|
I have The issue with my gen2 roborock is that it’s unable to discover it anymore. Mirobo command line tool also doesn’t work anymore. Is this because the vacuum token has changed? Any ideas? Tried downgrading same thing. Surprised mirobo command line isn’t working anymore. |
|
Please check your token. It has possibly changed. There is not much known about the 2gen vacuum yet. |
|
So I connected the gen2 xiaomi vacuum back to internet and to mi home android app. The earlier version where you can still get token. Now I’m home assistant the fan speed is 102%. Which is suppose to be balanced mode. It use to say balanced and max. Now just 102%. Strange that it kind of went into a crashed mode and couldn’t get back online even the mi home couldn’t detect it until I restarted it. |
|
No idea why the mi home app set the fan speed to 101, 102, 103, 104 Anyone with a gen2 has seen this strange behaviour? |
|
After a week of idling. Gen2 vacuum didn’t respond. And when I restarted hass. It was no longer available. Starting to think whether I need to allow the vacuum to access dns and ntp maybe. |
|
Found a post on the forums saying that the vacuum would only work after allowing dns and ntp?? Has anyone here experienced the same thing? Sounds like the vacuum retires accessing the internet too much and eventual enters a crashed state. |
But it's not good if I get these messages up to three times a minute right or am I wrong? https://gist.github.com/tringler/87bd31b43e6cb0955c01a39ee4263b36 I have no problems to call the vacuum cleaner at all. I'm struggling only with these messages all the time. I think |
|
No, that's not definitely good. Did you look at the link @beatmag posted? Do you allow your vacuum to connect to the cloud? If not, do you silently drop the packets or are you rejecting them? The former is known to cause (or at least amplify) the problem. |
|
I jumped from 0.65.0 to 0.65.6 and my first gen robovac is not detected anymore. I reject any attempts of my robovac to communicate with the internet. Worked fine till the update to 0.65.6. |
|
See my commentary on #11048 (comment) . If someone is having still issues with this (and none of the listed potential causes apply), feel free to open a new issue & including enough information to debug this. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 |
and others
Home Assistant release (hass --version):
0.51.2
Python release (python3 --version):
3.4.2
Component/platform:
vacuum
Description of problem:
I see that #8982 was closed @azogue but I am afraid I still have the same problem. The token is correct and mirobo can communicate without problems, all the times I have tried. As you can see it spawns those errors for more than 20 minutes.
The text was updated successfully, but these errors were encountered: