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.
What? That’s no more complicated than your separate wifi for your guests. And what if I’m running a perfectly functional network with multiple subnets on different VLANs for a business? I guess we should just toss HA out the window because of that.
No not really I see time and time again people with over complex networks and none of them strip back to basics in case it’s an issue with their setup or a compatibility issue somewhere. Remarks like your last one its just a kick in the balls for all the people who have spent hours of their own time getting stuff like this working.
Security comes with complexity. You’ll have to set the cursor. From everything in the same network, behind your internet box, accessing everything. To each type of device is isolated from the others…
If you have a plain LAN with all devices, then you cannot easily block the “phone home” devices. The Xiaomi gateway is one of those. And it works very well even if you block its internet access. You also can’t prevent anyone accessing this LAN from doing (almost) anything on every device you have.
I have several VLAN at home, 3 SSID (main users, kids, IoT), servers are in a VLAN, including HA. So every connection from a smart device goes through the firewall. Filtered broadcasts work fine with the proper firewall. I won’t say it’s easy to configure, especially if you’re not in the field. But, that’s my opinion only, I think it’s worth the pain, security wise. Because it’s my home that could be exposed.
There is nothing inherently overly complex about a network with two VLANs, especially for people like me who regularly design large scale global networks. And I like how you made the assumption that when troubleshooting, people don’t step back. For example, when I was troubleshooting the troublesome XIaomi gateways I immediately added a direct interface for my HA instance into the same subnet, sniffed all the traffic on the switch, on the HA instance, and from the Xiaomi gateway, and then slowly took the direct interface away and repeated troubleshooting. This was all to evaluate if Xiaomi products will work with HA in an environment that’s not a simple, flat network without annoying workarounds. The short of it is no, they won’t. And yes, that reflects on how Xiaomi operates; no matter all your hand waving about how great they are for you, that doesn’t mean they’re great across the board for everyone.
If you’re not going to actually add anything to the discussion please leave instead of calling people names with no actual helpful input.
Your right I will leave the discussion there’s some people who just can’t be helped. However I would like to know where you think I have been calling people names?
Your right I will leave the discussion there’s some people who just can’t be helped. However I would like to know where you think I have been calling people names?
You didn’t call people names, that was my mistake - you’re just incredibly rude and insulting and can’t seem to consider situations outside of your own personal one, ie, calling people who are trying to work on something a “kick in the balls” to those getting it working.
Guess what? We know it works on a flat network. The goal is to get it working outside that environment, which is not that radical of a proposition in anything but a simple home network, like, you know, a business running HA backends? The problem is that the HA’s config for Xiaomi gateways indicates unicast connections (where you can specify an actual host IP) but Xiaomi delivers push notifications via multicast, and while the HA documents mention this, it’s not explained in depth. When you multicast on multiple subnets you need IGMP support in your network hardware (which is either non-existant, badly implemented, or off by default in consumer grade equipment), or you need to run a multicast static routing daemon to fill in the IGMP gap. Or you can add an interface to the HA system that links directly into the Xiaomi gateway’s subnet, and bypass all the routing requirements, but then you need to specify in the HA config to use that particular interface to listen to multicast advertisements on instead of the default interface.
See? That’s actual, helpful information, which you are not adding.
Actually the kick in the balls comment was in direct response to something TSM-EVO wrote
Also not helpful. But for some unknown reason you have taken it upon yourself to call me out for having an issue with that and then have the cheek to call me rude.
His reply wasn’t helpful either, but he called out a company. You literally told everyone trying to get this to work that they were insulting people who had gotten it working because some guy doesn’t like Xiaomi (and I don’t blame him). I like a lot of Apple stuff, but I’m not going to tell someone they’ve “kicked everyone in the balls” because they don’t like them and not to use them in a thread about getting HomePods working with HA. Again, just leave if you’re not going to add anything else.
To those who might’ve stumbled on this post and are actually looking for answers, if you do put an interface into that subnet to bypass the multicast routing issue, the HA config to activate listening for Xiaomi multicast advertisements on that additional interface (which it doesn’t do by default) is:
xiaomi_aqara:
interface: '10.9.8.108'
where 10.9.8.108 is the IP of your HA interface (NOT the actual Xiaomi Gateway IP) in the same subnet as the gateway . If you’re DHCP’ing on that subnet I’d suggest you static config that interface instead so you don’t inadvertently end up with two gateways, or start routing traffic out that particular subnet instead.
“kicked everyone in the balls” is NOT what i said.
Please just actually read what was said instead of putting your own spin on it because you disagree.
You literally said TO ME, about my comment about your splitting multiple networks as silly:
“Remarks like your last one its just a kick in the balls for all the people who have spent hours of their own time getting stuff like this working.”
That is apropos of nothing. No one was insinuating anything negative about the developers working on the Xiaomi module and my comment about tossing HA out the window was made as a sarcastic response to you. Go troll elsewhere and perhaps try losing your prideful ego.
@lidocaineus I don’t think your comments add anything to the topic. If you’re here to share information and help other HA users to solve issues you should stick to topic. Please find another way to get rid of some frustration which is clearly bothering you.
What do you mean here ? I have the Xiaomi gateway in a ‘IoT’ VLAN, filtered and isolated from Internet and the ‘Server’ VLAN where the HA resides. It works !
Only troubles I have with the gateway becoming unavailable, is when the WiFi is too busy : if sensors updates are missed, they will appear unavailable. But this will happen in a non-segmented network too in the same condition.
you need to open UDP port 9898 from the HA VLAN to the Xiaomi VLAN
you need to open UDP from Xiaomi VLAN to HA VLAN
you need to enable multicast forwarding from the Xiaomi VLAN to the HA VLAN, check that the TTL in packets from gateway isn’t set to 1 (I think they don’t), if so, set the firewall not to decrease TTL when forwarding.
And it’s fine ! No HTTP, no route to Internet. Of course, MiHome won’t see it, won’t control it, but HA will.
What do you mean here ? I have the Xiaomi gateway in a ‘IoT’ VLAN, filtered and isolated from Internet and the ‘Server’ VLAN where the HA resides. It works !
It doesn’t work for a lot of people, as you can see from above. I gave the reasons why (buggy multicast implementations, the default being off, assuming you can unicast instead due to the nature of the config parameters) as well as workarounds.
Xiaomi Gateway hits defined timeout in xiaomi_aqara.py: TIME_TILL_UNAVAILABLE = timedelta(minutes=150) and then becomes unavailable in HA.
I checked everything, and Gateway is on same VLAN as Home Assistant server, so multicast should work (checked with ngrep).
Finally I gave up and changed that value to high number e.g. 24 hours -TIME_TILL_UNAVAILABLE = timedelta(minutes=1440), and pair that with restart of home assistant server every 24 hours. Now everything works, so I can’t understand why TIME_TILL_UNAVAILABLE even exists because gateway isn’t unavailable and works despite that setting…
@lidocaineus Can you go into detail as to how this can be done? Would this be doable from hassio? I would really like to ‘bypass the multicast routing issue’ that I’m having, as that seems like it’s going to be the final solution. I’d much rather that than:
have to purchase a new router, or a bunch of new hardware for zigb2mqtt and set that up instead.
I do stand by my original comment that the Xiaomi ecosystem is a mess. Home Assistant integration aside (and huge props to the author and contributors to PyXiaomiGateway for doing what it does for so many), the native ecosystem itself leaves much to be desired. I can’t even count the number of times I opened the MiHome App after everything else failed, just to turn off a light, only to have MiHome also not work.
I cannot agree on library part.
For me it seems like ‘if it works for me then it’s abandoned’.
I’m ready to provide everything to get this debugged, but even PRs moving it forward gets rejected right now.
There’s fix waiting in HA repo for the 2.5hours unavailability, although even with this fix I encountered gateways going away (even if packets still gets to the HA machine)
