Found the thread on the unifi forum again:
The gist of it: The Xiaomi Gateway using a mix of Multicast and Unicast thats why a igmp proxy seems not to work. Using an aqara hub seems to work though
Thanks. Seems the best answer is to depreciate the Xiaomi Gateway which is a shame as I use the speaker and RGB light feature a lot. I might move the Xiaomi Gateway back to the LAN until I can replace it with another light/sound solution. I have alreadymigrated 95% of my Zigbee devices to DeCONZ/Conbee but I have 6 x smokes still on Xiaomi as the integration is a lot better.
One last thing you could try… not sure anymore if i tried it in the past with the gateway or already switched all to the zigbee2mqtt. Basically i added my HomeAssistant to all of my VLans.
Wow, sounds like I might have bitten off more that I can chew!! My networking understanding is OK but not in-depth so playing around with all this stuff makes me nervous. I’ve just switched the Xiaomi Gateway back to the LAN and for now, everything is working again until I start adding firewall rules!
I appreciate the last post as that looks like it might be the golden egg to get everything working. I think I’ll only attempt that though when I have Home Assistant back on actual hardware as having it sit atop Proxmox just adds another layer of complexity, point of failure and another device to manage/update.
On mine, I’ve added adapters to HA to allow it to access both the internal LAN and the IoT LAN. This allows HA to talk to IoT gear without forwarders (e.g. IGMP). An option to consider if you run HA in a venv.
Thanks for the tip. Are they actual physical adapters?
No just another VLAN, you would need a smart switch.
I have a full UniFi setup. Could you explain your process?
I have smart switches connecting everything up, IoT devices are in IoT VLAN, and the Raspberry Pi running HA I’ve created a 802.1q trunk on the physical NIC and created two VLANs on it; one untagged (native) and one in the IoT VLAN.
I also have two access points trunked to the smart switch, and IoT wireless devices sit on the IoT VLAN (I have IoT SSIDs as well as other SSIDs for normal computers). The two VLANs are connected back to my router which only allows new connections from regular network -> IoT not the other way around. IoT devices that need internet access have it and I’ve blocked the rest.
With the two NICs on the HA Pi, HA can access both simultaneously, but I’ve also put iptables on it and only allowed specific ports required by IoT devices on the IoT adapter.
Thanks @callifo, but that all sounds above my pay grade. I’ve got IoT in one VLAN and Media in another but have left the Xiaomi gateway in the LAN for now. I think I’ll pay someone to remote in at some point and make a few tweaks as I fear that if I start playing with it, I’ll make things worse.
Hello,
someone solved the problem about to move xiaomi gateway into IoT network with VLAN in unifi without soldering the xiaomi gateway only changin configuration in Unifi?
thanks
I have managed to discover Xiaomi Aquara Gateway in Home Assistant using auto-discovery, but entities are not being updated.
I have multiple VLANs, and I used the trunk to connect RPI with the home assistant and configured sub adapters on RPI.
When I sniff traffic in home assistant container with TCP dump, I can see that gateway is sending multicast updates, but aqaura intergration does not update entities accordingly.
root@home-assistant:/home/pluskal# tcpdump -i eth0.11 'port 9898' -vvv -X
tcpdump: listening on eth0.11, link-type EN10MB (Ethernet), capture size 262144 bytes
21:06:15.785318 IP (tos 0x0, ttl 255, id 3909, offset 0, flags [none], proto UDP (17), length 138)
lumi-gateway-v3_miio259435924.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 110
0x0000: 4500 008a 0f45 0000 ff11 5817 0a0b 69c9 E....E....X...i.
0x0010: e000 0032 10e1 26aa 0076 5373 7b22 636d ...2..&..vSs{"cm
0x0020: 6422 3a22 7265 706f 7274 222c 226d 6f64 d":"report","mod
0x0030: 656c 223a 2273 656e 736f 725f 6d6f 7469 el":"sensor_moti
0x0040: 6f6e 2e61 7132 222c 2273 6964 223a 2231 on.aq2","sid":"1
0x0050: 3538 6430 3030 3538 3237 3638 3322 2c22 58d0005827683","
0x0060: 7368 6f72 745f 6964 223a 3138 3438 2c22 short_id":1848,"
0x0070: 6461 7461 223a 227b 5c22 6c75 785c 223a data":"{\"lux\":
0x0080: 5c22 3131 335c 227d 227d \"113\"}"}
21:06:15.787792 IP (tos 0x0, ttl 255, id 3911, offset 0, flags [none], proto UDP (17), length 144)
lumi-gateway-v3_miio259435924.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 116
0x0000: 4500 0090 0f47 0000 ff11 580f 0a0b 69c9 E....G....X...i.
0x0010: e000 0032 10e1 26aa 007c d09a 7b22 636d ...2..&..|..{"cm
0x0020: 6422 3a22 7265 706f 7274 222c 226d 6f64 d":"report","mod
0x0030: 656c 223a 2273 656e 736f 725f 6d6f 7469 el":"sensor_moti
0x0040: 6f6e 2e61 7132 222c 2273 6964 223a 2231 on.aq2","sid":"1
0x0050: 3538 6430 3030 3538 3237 3638 3322 2c22 58d0005827683","
0x0060: 7368 6f72 745f 6964 223a 3138 3438 2c22 short_id":1848,"
0x0070: 6461 7461 223a 227b 5c22 7374 6174 7573 data":"{\"status
0x0080: 5c22 3a5c 226d 6f74 696f 6e5c 227d 227d \":\"motion\"}"}
21:06:20.449830 IP (tos 0x0, ttl 255, id 3918, offset 0, flags [none], proto UDP (17), length 164)
lumi-gateway-v3_miio259435924.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 136
0x0000: 4500 00a4 0f4e 0000 ff11 57f4 0a0b 69c9 E....N....W...i.
0x0010: e000 0032 10e1 26aa 0090 ec24 7b22 636d ...2..&....${"cm
0x0020: 6422 3a22 6865 6172 7462 6561 7422 2c22 d":"heartbeat","
0x0030: 6d6f 6465 6c22 3a22 6761 7465 7761 7922 model":"gateway"
0x0040: 2c22 7369 6422 3a22 3034 6366 3863 6636 ,"sid":"04cf8cf6
0x0050: 6164 3335 222c 2273 686f 7274 5f69 6422 ad35","short_id"
0x0060: 3a22 3022 2c22 746f 6b65 6e22 3a22 7646 :"0","token":"vF
0x0070: 694b 7239 364c 5479 7756 5747 6366 222c iKr96LTywVWGcf",
0x0080: 2264 6174 6122 3a22 7b5c 2269 705c 223a "data":"{\"ip\":
0x0090: 5c22 3130 2e31 312e 3130 352e 3230 315c \"10.11.105.201\
0x00a0: 227d 227d "}"}
It is simillar to https://github.com/home-assistant/core/issues/38286 but I have triple check the network configuration that seems fine.
EDIT:
I have managed to make it to work. The integration asks for a interface and defaults to any. No interface name worked for me, but when I passed an IP address assigned to virtual interface belonging to the IoT VLAN, it magically started to work.
2 Likes
Hi. Could you please elaborate a little bit more? You saying that in you HA instance you have two network interfaces, one for your main LAN and another different one for your IoT VLAN? I have the same problem as all ppl here, but I’m trying to understand what you did to have the interface talking to the IoT VLAN directly. Thanks
Hi, just use the IP address of the interface facing the IoT VLAN in the configuration of Xiaomi integration instead of the any string that is the default option.
Thanks. I understand correctly you are saying your hass instance is connected directly to the IoT vlan right? In my case hassio is connected in main vlan and hass access the devices on IoT vlan via routing, so I don’t have any direct interface to IoT on hass… I guess I’m stuck there
Yes! You need to be L2 connected, because as best to my knowledge, Xiaomi uses multicast or broadcast, so routing will not work.
I used trunk on the switch to pass all VLANs I needed to the HASS, and on the HASS instance, I modified network settings and added multiple virtual interfaces according to the VLAN tags I needed.
Works like a charm. Settings are persistent across HASS updates.
Thanks for the tips. I’m keen to give this another try and wondering if you could elaborate a bit more on how to create the virtual interfaces?
Well, I am not sure how I managed that exactly. It is a bit different on each Linux distro, but you can look for a “VLAN Linux”.
There is a thread describing the approach on HASS
Or, just generically, if there is an ip utility present, you can use 10.4. Configure 802.1Q VLAN Tagging Using the Command Line Red Hat Enterprise Linux 7 | Red Hat Customer Portal otherwise, write the /etc/sysconfig/network-scripts/ifcfg-device_name by hand.
I was playing with the same problem for several weeks now. Aqara HUB M1S in IOT VLAN subnet and HA in home LAN (sitting in KVM-QEMU). IOT cannot access LAN, LAN can access IOT. So HA can see IOT VLAN, but thanks to multicasts cannot acccess Aqara. And I do not want to put HA into both those VLANs (LAN and IOT).
I have read many posts about this topic and they have different infos here and there, so I tried my own inspection with tcpdump to see, how the communication is going.
In my case it looks like Aqara is shouting multicast to 224.0.0.251 (mDNS port 5353) “hey, I am here” and avertising services endpoints and ports (ports seems to be random), eg.:
Aqara-Hub-M1S-A343._hap._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 49283, target Aqara-Hub-M1S-A343.local
Aqara-Hub-M1S-A343._aqara-setup._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 33686, target Aqara-Hub-M1S-A343.local
Aqara-Hub-M1S-A343._aqara._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 47897, target Aqara-Hub-M1S-A343.local
HA is catching this mDNS packet, picking _hap_ service and then opening TCP connection to it. All events and data is then using this connection.
So I have installed Avahi on my OpenWrt router and configured /etc/avahi/avahi-daemon.conf this way:
[reflector]
enable-reflector=yes
[server]
allow-interfaces=br-lan.100, br-lan.25 # looks it needs space after colon (!)
Enable and restart service on OpenWrt
/etc/init.d/dbus start
/etc/init.d/dbus enable
/etc/init.d/avahi-daemon start
/etc/init.d/avahi-daemon enable
Avahi is sending mDNS from one VLAN to all other subnets (listed in config).
Then I opened firewall hole to allow mDNS between those VLANs
from any, to this device, UDP, 224.0.0.251:5353, allow
And thats it. HA can discover Aqara HUB. I can see all zigbee devices and can read their states and values as before. Maybe something will pop up, I am testing it for a week, but it looks good so far.
Hope it can help someone.
1 Like
Unfortunately, this does not work for the lumi.gateway.v3 version.