Since yesterday i have my Xiaomi Aqara gateway connected (including a couple of sensors) to Hass.io
But for some unknown reason they stop working after 150 min. after reboot of the system.
When i restart Hass.io they come back up but only for those 150 min.
It also looks like it’s not updating the sensors and most of the time the system appears to not communicating with the gateway, since (for instance) changing the light on the gateway from off to on works, but turning it back off doesn’t.
I’ve read something about adding --net=host to the docker container (no idea how since Hass.io was not installed manually but using the image) and a problem with (possible) not having multicast traffic turned on.
Anyone experiencing the same issue? Or anyone any idea on how to fix this?
I would like to share my experience here that I think might be useful for some of you.
I have been using HASS in Synology docker for around 3 years without major issues. 2 months ago, I started to experience the exact problem of it being not working after 150min. I’d tried changed to HASSIO and Hassian, or disabled bluetooth related components, without any success. My workaround was to restart HASS every hours through crontab.
Further reading the comments in this post, I found that the multicast support of router could be a cause. I also remember I switched to Tenda WM3 mesh network around 2 months ago, that could be somehow related. Yesterday, I changed to ASUS RT86U, and everything worked again, without any “Invalid Key” or sensors/ switch “unavailable”. So, it concluded that the router IS the cause.
Don’t know why, Tenda mesh wifi is failing Xiaomi GW. Happy to hear if others have recommendation on how to get around to make it work without changing the router.
It’s probably down to your WiFi channel interfering with the gateway zigbee channel as they both share the 2.g spectrum, WiFi tends to drown it if to close. you can reduce by setting WiFi channel further away
Have a look at my findings tonight. Looks like there might be issues with later gateways where the MAC address starts 04:xx:xx:xx:xx:xx. I found that during discovery the gateway identifies it with a SID minus the leading zero, which is what the entitity_ids are created from. From then on, when it broadcasts its update messages with the full SID, HA doesn’t see is as a match so ignores it.