error at log: Timeout fetching xxx data and device is unavialable for few moments #73763
Comments
|
Hey there @rytilahti, @syssi, @starkillerOG, @bieniu, mind taking a look at this issue as it has been labeled with an integration ( xiaomi_miio documentation |
|
i have the same with my vacuums i am using. Logger: homeassistant.components.xiaomi_miio Timeout fetching roborock.vacuum.s6 data |
|
I'm looking for somebody who is able to setup a Home Assistant Core (python virtualenv) instance to compare the behavior of the pure HA core setup with a Home Assistant OS (docker) setup. |
|
Same think all the time roborock s5 max goes unaivable all the time. Logger: homeassistant.components.xiaomi_miio Timeout fetching Svetlana data |
|
Hello, same since today with my S5 and S6, they keep becoming unavailable and I have a timeout in the logs: |
|
I need more testing but it seems my Unifi Dream machine was blocking some traffic from Xiaomi, that's why my 2 vacuums were having issues. |
|
No i dont got ubiquitu hardware, my set up is simple, just a router but it keeps giving me errors. Logger: homeassistant.components.xiaomi_miio Timeout fetching xxxx data |
I am using a pure python venv installation and have the same issue. In addition the temperature sensors often stay at the same level without any update for way too long. My system is not reachable from the outside, but that does not apply since the devices are locally anyway (not using the cloud button). Xiaomi Air purifiers H3 and Pro |
|
The problem with not sending updates seems to be If that is on the plug-in side - which I hope - I would like to change that. Is that possible? |
Not having them connected to the cloud might be irrelevant, as there are devices that are known to become unresponsive on specific conditions, like on some roborock gen1 firmware vacuums think they are stuck and are rebooted by a watchdog when they are not receiving any responses for their requests. See https://python-miio.readthedocs.io/en/latest/troubleshooting.html#intermittent-connection-issues-timeouts-xiaomi-vacuum for some details on that. |
|
This was may concern. So there is nothing we can do, right? Maybe extending the timeout would be making sense, considering the watchdog has a timeout as well. |
|
i agree with @dawiinci maby longer wait for response time will solve or partial solve problem? I have this problem with my three fans and three purifier. I checked and in XIaomi app this devices are all time avialable, so problem with unavialable devices exsist only in HA. below last 24h, over 800 hits
first three are fans fan.zhimi_fan_za5 last two pufifiers zhimi_airpurifier_mb3
|
@syssi I can help with python virtualenv vs supervized and |
|
@Enzokot Thanks for your support! Do you have the same issues mentioned above at your supervized setup? |
Yes, with all listed devices |
|
Please pick a debian based host and install the Home Assistant Core in a virtualenv: https://www.home-assistant.io/installation/generic-x86-64#install-dependencies Please don't use any virtualization. For the test scenario it's important to have a super simple (bare metal) setup. If you have trouble to setup a virtualenv + homeassistant please let me know. I will try to provide support. As soon as the setup (HA core instance) is up and running (accessible via http://a.b.c.d:8123) we will your the Xiaomi devices. Let the setup run a few days, so we can compare the history graphs of both HA instances (virtualenv vs. dockerized=your production system). |
|
@syssi I have new installation (without/simple any configs for HA) Home Assistant Core in a virtualenv on Raspbian PI4 and new one (without/simple any configs for HA) Home Assistant Supervized on mini PC like Gygabyte Brix (x86). This is good for testing? May be any tuning for the log file? |
|
Perfect! So we are good to go. Please add the Xiaomi devices to your new setup. Make sure the setup is able to talk to your MiIO devices and please provide some screenshot (like above #73763 (comment)) of your history graphs. I assume there won't be so much dropouts compared to the supervized setup. |
|
same here - Purifier 2s became unavailable every few seconds
|
|
Same goes with my mi air purifier 3C, disconnect every few minutes Logger: homeassistant.components.xiaomi_miio Timeout fetching Mi Air Purifier 3C data No issue at all with mi air purifier 3H |
|
@syssi result by days |
|
Good job! It looks like there is no big difference between the setups. The supervized instance shows the same pattern as the virtualenv setup. |
This integration is listed as LOCAL POLLING; why would location block affect the status? |
I'm experiencing the same issue, but there's no pattern to the timing. Interestingly, Ubiquiti states the device has been connected the entire time. |
|
@BillyFKidney The firmware of some Xiaomi devices is pretty bad. The communication between HA/python-miio is local but the devices tries to talk to the Mi cloud periodically. If the internet access is blocked the firmware gets stuck or runs into timeouts. The local communication slows down or is impossible in these situations. |
|
i have all communication allowed, and last 24h for my fan.zhimi_fan_za5 and two pufifiers zhimi_airpurifier_mb3
|
|
@KitHubek There are devices out there which don't like to be polled very frequently. I don't know this fact does apply to your device. I just try to provide a much details as possible here. |
|
last 7 days. Crazy is that Xiaomi purifer PRO has no problem. 7 days i cant see 1 error with purifer PRO. Other devices - no comment
|
|
what is the timeout set in the integration after which the device is considered unavailable? I did a regular fan ping test for 3 hours and the duration is max 3 seconds. Of course, the vast majority does not exceed 1s. I think that increasing the waiting time for a reply would solve the problem and it would definitely reduce it significantly |
|
@KitHubek The default polling timeout is 10 seconds: https://github.com/home-assistant/core/blob/dev/homeassistant/components/xiaomi_miio/__init__.py#L78 IMO there is a difference between: A device responds to ICMP requests (ping) in time vs. the device API is able to respond to a miIO request. You could try to increase the timeout (by editing the file of you HA installation + restart). I assume this won't improve the situation because the miIO device will never respond to some requests. |
|
since there are some inquiries to which the device will not answer, maybe it would be worth doing so that the device is simply not marked as unavailable based on these queries, or when available, take into account only those queries that are standard for everyone the type of device, i.e. the state of the on / off switch, ip address, anything else that is always present with each device |
Hi @syssi , I have a core version has described in your message (on a beagle bone black which is a mini PC like the Raspberry PI) and unfortunately I have not the supervised version running in parrallel. I have sometimes also some unavailabilities (see bellow), and that actually does not bother me. In this example the unavailability is only 22s : so who cares? But there is actually a critical side effect. I don't know if this occurs on the core version only or in all install versions but since these unavailabilities generate "ERRORS" it can break actually the run of other homeassistant processes or the core process itself. For example, if it happends during the startup of homeassistant, it will fail to load (see bellow). It can may be break also other services such as core updates or other critical processes ? So I see actually 2 issues :
Do you think I should create a new issue for this : catch the xiaomi_miio error (for example try to generate a warning and not an error?) Regards, |
|
any update to fix this issue? |
|
I'm having this issue as well, and I can see the device reconnecting to the wifi in the hostapd logs after ~20 seconds. Since that means the entire connect is reset, it would explain why a timeout wouldn't work. After rebooting the vacuum it seems to be better for now (or maybe it will reconnect if it can't connect to the gateway?). |
|
There is #82601 that might improve the situation. @ntkoopman reconnection to wifi sounds like a device reboot which gives a (potentially useful?) clue that the device has arrived in an unrepairable state causing the reset. The root cause (if not fixed by the linked PR) remains still unknown :-( |
|
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. |
issue-triage-workflows
bot
closed this as not planned
|
Feel free to give the dev branch a try to see if the #82601 fixes (or at least alleviates) the issue, and please report back, thanks! |
When testing, do I need to copy the entire xiaomi_miio folder from Dev into my local custom_components folder, or just the changed file (init.py)? |
The problem
See this timeout error at log, and devices are reallly on moment unavialable
Logger: homeassistant.components.xiaomi_miio
Source: helpers/update_coordinator.py:197
Integration: Xiaomi Miio (documentation, issues)
First occurred: 15 czerwca 2022, 08:54:49 (2358 occurrences)
Last logged: 18:16:59
Timeout fetching fan1 data
Timeout fetching purifer1 data
Timeout fetching purifer2 data
Timeout fetching fan2 data
Timeout fetching purifer3 data
Timeout fetching fan3 data
Purifers: 2x Mi 3H EU ver and Mi PRO EU ver
Fans: 3x Smartmi Standing Fan 3
What version of Home Assistant Core has the issue?
2022.6.6
What was the last working version of Home Assistant Core?
2022.4.5
What type of installation are you running?
Home Assistant OS
Integration causing the issue
xiaomi_miio
Link to integration documentation on our website
https://www.home-assistant.io/integrations/xiaomi_miio/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: