Xiaomi Gateway becomes unavailable after some hours

Hi Jowi42,

If I remove the host and/or mac entries then HA will not discover the gateway. I have discovery_retry set at 5.

I think I experience the same problem with the gateway, it becomes unavailable after some hours and even changing it to a fixed IP and changing that in the configuration.yaml doesn’t have any effect.

Also the same as some people here I was using the Xiaomi gateway with my previous hass.io installation for months without any problem, now it’s stable for only 2 hours … Also without xiaomi host set to the IP it will not discover the gateway and only log “No gateway discovered”.

Hi Guys,

I have the same issue. Fresh install of HA (awesome work by the way !) on a Pi 3 via Docker. I had some difficulties to get the Gateway Discovered, but with the IP and the Mac address set it finally worked.

After 2.5 hours my captors get vanished, If I restart HA again all is back to the normal but then 2.5 hours after same issue.

Did you find a way to fix it ?

Thank you !

Hi all,

Same problem here.

Connected the gateway without any problems. But after 150 mins it stops working and initially after boot it seems to not update my sensors aswell.

If read something about adding --net=host to the docker instance because it might have something to do with multicast, but both of them, i don’t know how to check or to configure.

I am using hass.io from the image, so i didn’t install it myself on any linux distro, nor did it configure it in docker myself.

Thanks in advance!

Same issue here since updating from .72 to .78. I have blocked the Xiaomi gateway’s internet (parental control style) on my router since the beginning, but I haven’t changed it.

Start reading at the top of this topic :wink: Did you try this;

Hi @sjee, thank you for your answer. I don’t have any firewall set. I am a bit sceptical about this because It seems we all are experimenting the same behavior : the gateway get vanished after 2.5 hours and but still available via Mi Home, and If we restart HA all is ok again for 2.5 hours

I’m from France and my router is provided by my ISP (Freebox) and I doubt the other guys have the same Network Gear. I will try to dig a bit further this week-end …

@alexjomin not all… I’m not having any issues and @Lucas_Rey was able to solve the exact same issue. There are several (long) topics on network issues related to the Xiaomi gateway. As far as I know the way HA communicates with the gateway is different from the Mi home app. From that point of view there are some limitations in the API. The solutions I have seen where always related to the network configuration (router, wifi repeater, firewall, etc.) Others replaced the xiaomi gateway with a different zigbee gateway solution.

@sjee Maybe it’s a networking issue, but if so, the 2.5 hours timeout limit should be hardcoded somewhere in HA. I will try with another router and I’ll let you know.

I guess we have a clue here : https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/xiaomi_aqara.py#L45

So if we have a networking issue, the timeout is fired after 150 min. It explains why we are experimenting the same time to see the Xiaomi Sensors unavailable. New router ordered today, I’ll you know.

@alexjomin Any luck yet? My Homeassistant/Aqara was stable until about two weeks ago. Since then, it’s always stable for 2,5 hours and gets unavailable after exactly 2,5 hours.
My router is a Netgear R7000, so that should be stable enough :slight_smile:
The Aqara gateway is about 1 meter away from the router.

I did change my setup of home assistant to a docker environment, with port 8123 exposed. If anything would have been wrong with the ports, it wouldn’t work at all I guess - and not just 2,5 hours, right?

@harmjanr Did you add the --net=host to your container ?

By the way to be sure, enter inside your container and run a tcpdump -A -i wlan0 udp port 9898 (if your interface is wlan0) If all is ok you should see the UDP messages coming from the Xiaomi Gateway if not, the gateway is not reaching the container.

@alexjomin Nope, I created one bridge network that is used for all my docker containers. It is set up this way to have container linking in my reverse proxy. But the docker network can’t really be the problem, otherwise it wouldn’t work at all instead of only 2,5 hours, right?

Read the topic, there is a very good explanation why network issues will actually cause a 2,5 hour timeout.

@harmjanr that what I thought first too but without the net option set, I had the same 2.5 hour timeout behaviour

I just changed the network to host, and replaced the container linking. Let’s wait for 2,5 hours now :slight_smile:

@alexjomin After 3,5 hours, it still seems to work! Thanks for the help with the net option :smiley:

@harmjanr Glad to hear that :slight_smile:

My installation is on hassbian.
Can someone please explain me what should I do with the —net=host? Do i need to do this change on my installation?
I have a problem that sometimes I stop get events from the gateway on ha but continue to get events on mi home app.
For example I can press the xiaomi smart button and it wont work buy if I press it again it will work.
The same issue with the door sensor… after some time I don’t open the door I try to open and I don’t get notification but the second time I get the notification just fine.
Can someone help me with this?

Thanks a lot!

I’ve got the same problem :frowning: it’s really annoying.
I will try to describe it a little bit.

Gateway configuration:

xiaomi_aqara:
  discovery_retry: 5
  interface: 192.168.0.94
  gateways:
      key: !secret gateway_key
      host: 192.168.0.136
      mac: !secret gateway_mac

There are 3 motion sensors, 3 door/window sensors, and one aqara cube.
Problems:

  1. On HA frontend there is a light switch automatically generated by HA. When switched on, in 90% of cases it turns on the gateway light. When switched off, in 40% cases it turns light off. Sometimes this kind of actions generate “Invalid Key” error in logs.
  2. Sometimes sensors (not all of them) become unavailable. So any automations based on them are worthless.