Timeout fetching XIaomi device data

[KitHubek]

The problem

flood at log as below:
Timeout fetching xxx data

First occurred: 8 marca 2023 09:13:20 (4663 occurrences)
Now 10 mar about 21:00 so, about 60 hours, 4663 / 60 = about 77 hits per hour, so its morethan 1 error peer minute

lumi.gateway.mieu01 - all ok, no timeout (have 1)
zhimi.airpurifier.mb3 - not ok, many timeout (have 2, everyone on different room, and connected to different AP)
zhimi.airpurifier.v7 - i can say, ok, sometimes timeout. maby max 10/24h (have 1)
zhimi.fan.za5 - not ok, many timeout (have 3, everyone on different room, and connected to different AP)

i checked, and in my router details, all this clients have uptime many many days, at console logs havent any hit with timeout or roaming to another AP
At Xiaomi Home app, all devices are all the time online and all the time i can see all details and can turn on/off and control all functions

What version of Home Assistant Core has the issue?

core-2023.2.5

What was the last working version of Home Assistant Core?

this problem is for many months

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

config_entry-xiaomi_miio-4271c7288b91dcab4ae536e5d796f5c2.json.txt
config_entry-xiaomi_miio-31ac6d6b4c26a736770a9b3e41961fa0.json.txt
config_entry-xiaomi_miio-bd9244e7ab8b0e0d4f91261418e5f46d.json.txt
config_entry-xiaomi_miio-7536ca765aa14ed581ca6ab00d225cbd.json.txt
config_entry-xiaomi_miio-d97ca4b97e2c322e6ce0fc358bab2036.json.txt
config_entry-xiaomi_miio-fd93c84a10e8eb9d1a5df52fdd80bbd5.json.txt
config_entry-xiaomi_miio-5ee9bd883ddee03037990354b2722b19.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.xiaomi_miio
Source: helpers/update_coordinator.py:182
Integration: Xiaomi Miio (documentation, issues)
First occurred: 8 marca 2023 09:13:20 (4663 occurrences)
Last logged: 20:19:05

Timeout fetching my purifer 1 data
Timeout fetching my fan 1 data
Timeout fetching my fan 2 data
Timeout fetching ny fan 3 data
Timeout fetching my purifer 2 data

Additional information

No response

[home-assistant]

Hey there @rytilahti, @syssi, @starkillerOG, mind taking a look at this issue as it has been labeled with an integration (xiaomi_miio) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of xiaomi_miio can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign xiaomi_miio Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

xiaomi_miio documentation
xiaomi_miio source
_{^{(message by IssueLinks)}}

[akula3]

I also have this error:

Logger: homeassistant.components.xiaomi_miio
Source: helpers/update_coordinator.py:182
Integration: Xiaomi Miio (documentation, issues)
First occurred: 16. März 2023 um 03:22:52 (11 occurrences)
Last logged: 10:01:27

Timeout fetching Device data

[JayRHa]

Have the same error

[FlingersDH7]

Since friday this error also started to show up. And not only this xiaomi integration, but also the Xiaomi vacuum map extraction tool stopped working. So maybe these things are related

[kingo55]

I'm seeing this after upgrading recently too, for my zhimi.airpurifier.v7. It doesn't appear as a connectivity problem with the device itself, because I can still ping it when Home Assistant reports the timeout bug.

ping 192.168.2.107
PING 192.168.2.107 (192.168.2.107) 56(84) bytes of data.
64 bytes from 192.168.2.107: icmp_seq=1 ttl=255 time=404 ms
64 bytes from 192.168.2.107: icmp_seq=2 ttl=255 time=1.97 ms
64 bytes from 192.168.2.107: icmp_seq=3 ttl=255 time=2.30 ms
64 bytes from 192.168.2.107: icmp_seq=4 ttl=255 time=10.9 ms
64 bytes from 192.168.2.107: icmp_seq=5 ttl=255 time=3.70 ms
64 bytes from 192.168.2.107: icmp_seq=6 ttl=255 time=10.5 ms
64 bytes from 192.168.2.107: icmp_seq=7 ttl=255 time=2.10 ms
64 bytes from 192.168.2.107: icmp_seq=8 ttl=255 time=3.46 ms
64 bytes from 192.168.2.107: icmp_seq=9 ttl=255 time=1.98 ms
64 bytes from 192.168.2.107: icmp_seq=10 ttl=255 time=16.6 ms
64 bytes from 192.168.2.107: icmp_seq=11 ttl=255 time=2.02 ms
64 bytes from 192.168.2.107: icmp_seq=12 ttl=255 time=1.95 ms
64 bytes from 192.168.2.107: icmp_seq=13 ttl=255 time=10.4 ms
64 bytes from 192.168.2.107: icmp_seq=14 ttl=255 time=6.74 ms
64 bytes from 192.168.2.107: icmp_seq=15 ttl=255 time=2.14 ms
64 bytes from 192.168.2.107: icmp_seq=16 ttl=255 time=1.98 ms
64 bytes from 192.168.2.107: icmp_seq=17 ttl=255 time=2.07 ms
64 bytes from 192.168.2.107: icmp_seq=18 ttl=255 time=1.96 ms
64 bytes from 192.168.2.107: icmp_seq=19 ttl=255 time=73.6 ms
64 bytes from 192.168.2.107: icmp_seq=20 ttl=255 time=2.22 ms
64 bytes from 192.168.2.107: icmp_seq=21 ttl=255 time=48.2 ms
64 bytes from 192.168.2.107: icmp_seq=22 ttl=255 time=1.96 ms
^C
--- 192.168.2.107 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21011ms
rtt min/avg/max/mdev = 1.953/27.873/404.463/83.928 ms

The issue appears intermittently for me - there are periods with a stable connection and other periods with barely any connectivity in HA:

So far, I haven't worked out what it is, but I'm having a read through some of the more recent commits.

[rytilahti]

Such errors are encountered on some devices more than others, and it's likely related to the low-level protocol handling inside the backend library. As I have written in many issues already, these are really hard to track down and debug.

The device keeps answering to the pings as long as it's up. On some devices a watchdog boots the device and these happen due to that reason rather seldomly. On some devices the "server" speaking the protocol thinks the incoming requests are somehow incorrect and drops them, maybe because of the internal state or some other reason. The reason is not really easy to find out without debugging the daemon on the device or without access to the logs on the device.

In your screenshot it's rather odd that the disconnects happened so often but suddenly it's more stable.. Maybe a firmware update changed something?

[kingo55]

Thanks - that was my thinking too. When reading through recent commits, it only looked like updates to upstream libraries. Not an easy thing to debug. Maybe it solves itself upstream.

[rytilahti]

There has been no changes to the protocol handling in python-miio for years, and the last release which is used by homeassistant is also almost one year old at this point.

Would you mind trying if #82601 improves the situation on your device?

[rytilahti]

Feel free to give the master branch a try to see if the #82601 fixes (or at least alleviates) the issue, and please report back, thanks!