It looks like a network issue frankly. Your wifi may be dodgy.
Don’t forget too that mixing wifi and zigbee is tricky, they both use 2.4GHz spectrum. As someone said in another thread, its physics!
I should mention, I ordered my gateway from eBay, and the CN-to-US ‘universal plug adapter’ shipped with it was an extremely poorly-built item. It would not remain plugged in, due to lack of friction/contact. The US plug blades were too thin and not spaced nearly correctly. Even being quite careful with it, the gateway was prone to dying and restarting frequently. I immediately ordered and swapped in a better plug adapter, and now it’s rock-solid reliable. It is in the same room with line-of-sight to a wireless access point, though.
I am lucky, NZ sockets take chinese plugs.
If I have to choose a foreign plug, I go for UK plugs and use a UK - NZ adaptor. They are bulkier than US plugs, but are very “positive” in their connectivity, much better than the US rubbish.
uk plug - the most over engineering power plug in the universe 
I am lucky, NZ sockets take chinese plugs.
I assume you have the same issue we have - the chinese plugs are actually upside down, and so frequently block the socket swtich…
"Its seeing the gateway, and I can toggle the gateway light on and off. So its being recognized. It even see’s the two sensors. A motion detection, and a ‘cube’. All are working via the Android app, none via HA. "
I see the exact same symptoms after resetting my Xiaomi hub. My HA install has been working for over a year with a number of Xiaomi sensors. The reason to reset the hub was to move it to another network. Only change to the HA config was to update the IP address of the hub to reflect the new network (to which HA is directly connected). The hub and sensors now show up in the HA log during restart and HA can turn the hub light on an off. Via the Xiaomi app I can confirm that the hub is seeing sensors change state 100% reliably but HA sees nothing. There are no events in the HA log when the sensors change state. Tried many times, inc multiple hub resets and generation of new keys.
Does anyone know of any means to see at a lower level than the HA debug log what if any comms is taking place between Xiaomi hub and HA?
Any network monitoring tool.
When you say reset, do you mean a full reset?
Have you checked using nmap that all the ports are still open?
Is your new network handled by the same equipment as before (and supports multicast)?
The reset of the Xiaomi hub was done by holding the button until the light flashes yellow and it starts shouting, then deleting it from the Xiaomi android app. It’s not entirely convincing: The hub shows up on the app as a new device. However, once the hub is re-added on the app, the devices that were hanging off it before the reset come back. I’m not sure whether this is down to the hub itself not actually being reset or if the app/account is keeping a record and re-adding the devices onto the hub. It seems to be well known judging by other Xiaomi discussion threads.
The networks are all on the same router which is a standard home hub from one of the ISPs. HA is running on a pi3 connected to the router by both ethernet and wifi.
- The pi ethernet connection is in the same subnet as the first wifi network on the router.
- The pi wifi connection and second wifi network on the router are in a different subnet
The hub is being moved from the first to the second wifi network, with its IP address being changed in the HA config accordingly. In both situations, the Xiaomi hub is on the same subnet as an interface on the pi.
Multicast - don’t know and there isn’t a setting for it on the hub. Best guess, it’s probably going to be the same as both nets are on the same hub.
(btw, I’m doing all this is to create a migration path for the Xiaomi kit onto a completely separate private network with the same SSID)
The reason for my question about logging was the hope that there might be more detail available from HA itself, that shows what HA is actually seeing at a very low level, before getting into Wireshark, tcpdump etc.
The point that I find confusing is that HA can clearly still see the hub after the move. The HA log shows that the hub is discovered during restart and HA can still control the light on the hub. I don’t know how events from the Xiaomi devices are communicated back to HA and if/how this would differ from the mechanism that still allows hub discovery and control to take place. (perhaps this relates to the multicast question?)
Since my original question I gave up and moved the hub back to the original wifi and the devices came straight back up on HA. Some guesses:
- The hub is retaining some incorrect config on how it should communicate with HA
- HA has problems working with two IP addresses on the pi
- The network comms with which HA sees device events from the hub is different to that which allows it to discover/control the hub, and is being blocked somewhere in my router
… or something completely different.
mutlicast is required for the hub to broadcast regular state updates:
it also uses direct point to point for event updates.
But if you are using the same wifi AP both times, I would presume multicast support is there and isn’t the issue.
Strange.
Assumption is the mother of all f*** ups.
true. but my assumption was based on it working on the same AP in the original configuration.
But maybe thats wrong as you say.
In that same thread they say that events from devices are sent unicast which is the test that I was doing using a door switch:
“The Xiaomi Gateway publishes the current state of the ZigBee devices periodically via multicast. In addition there is a unicast message (gateway ip -> home assistant ip) on each event (if you open a window f.e.).”
So it’s at least partly not a multicast issue. Presumably the hub picks up HA’s IP after HA contacts it during discovery?
Time for that network trace. Will post if I find anything useful.
1 Like
Hi *,
my HA (still 0.113) is not able to discover my new Aqara hub.
Manual configuration from Lovelace also does not work. I shall choose a network interface. Neither “any” nor the HA IP address are working.
Then I tried adding the component in yaml as follows:
xiaomi_aqara:
discovery_retry: 10
gateway:
- mac: AQARA_HUB_MAC
key: AQARA_HUB_KEY
But no success either.
The hub is on the same subnet as HA.
The ping integration successfully reaches the hub.
I added log events, but I cannot find anything related to aqara in the logs:
logger:
default: warning
logs:
homeassistant.components.mqtt: debug
homeassistant.components.xiaomi_aqara: debug
homeassistant.components.sensor.xiaomi_aqara: debug
homeassistant.components.switch.xiaomi_aqara: debug
homeassistant.components.binary_sensor: debug
xiaomi_gateway: debug
Any Idea what’s going wrong?
Best
Ck
can you run the following against the IP that your hub has:
nmap -sU -Pn IPADDRESS -p 9898,4321
(assuming you have a machine that can run nmap)
1 Like
I am on the same boat and done your nmap, and both ports appear to be closed :-(. The pity is that I have no idea how to open, I have open on my router, like other ports, but I don’t know if I am doing correctly.
If they are closed either you have a device which is locked and requires you to open it and do stuff), or as a minimum haven’t enabled the device for local access.?
there is a link somewhere on here about unlocking - i can’t find it right now.
Thanks a lot @walaj, It sounds to me that on the last days full time trying to solve this, I have seen something about that, but I want to remember that I would have to weld, what is not my strongest point, jajaja. Thanks anyway
No weld, solder.
Frankly I would ditch it and use a more generic zigbee solution.