This may be because you are using the ipv6 prefix from your provider. Change your internet router settings so that Unique Local Addresses (ULA) are used instead of Global Unicast Addresses (GUA).
Temporarily disable the 5 GHz network to ensure that all devices are using the 2.4 GHz network. It is crucial that all devices (smartphones, hubs, border routers) are on the same network.
Does your device get an IPv6 address when it is connected to Wi-Fi and Bluetooth is enabled? Are you using the same smartphone and user account that you used to create the Thread network?
Can you connect the P2 in HA and Aqara with the Matter code via Multi-Admin?
I ensured that all devices are on the same network. 2.4ghz. All 5ghz radios are disabled.
I have basically tried majority of what you suggested and it fails. When it connected to Aqara i could see the IPV6 address so I cant see that being the issue?
Which Aqara Hub or other border routers do you use?
Don’t get me wrong; this isn’t the cause of your current problem, but it’s probably why the sensors were originally disconnected. There must be a way to set the prefix in the router. Which internet router are you using?
The screen shot above shows WAN and LAN and all set to auatomatic. Like I said previosly I could see an IPV6 address for the sensor, I can see 1 for my mobile device also so not to sure if this is the fault.
I’m not sure how to test what you asking about all the other hubs, but the device has connected to other controllers but then becomes un - responsive
I have also tried creating a new thread network but that did not work either
Below is a screen shot of the error in the Aqara home APP - which does point to IPV6 error. I am going to move my M3 today to the main router and see if that makes any difference. If not, I am going to order another P2 and see if that works OK - If so, I will return the other
You must be able to set the IP addresses somewhere, even for IPv4. I think the settings are somewhere else.
What options do you have for the DHCP server, apart from automatic? You may need to change this setting first in order to specify the IP addresses elsewhere.
Check the network settings of the P2, as well as the Wi-Fi settings of your smartphone and under “More Functions” on your Huawei AX3 for the IPv6 addresses and see if the addresses begin as follows:
fe80:: → Will work with Wi-Fi but not with Thread
2xxx:: → Will work, but from time to time the sensors may lose connection
fdxx:: → should work without any problems
Have you restarted all hubs/routers and your smartphone as instructed?
And try pairing when all devices (smartphone, P2, and hub/border router) are as close to each other as possible.
Thanks for the support, I have now moved to M3 direct to the main router coming into the house (this was the only device I could verify IPV6 was on)
My theory is that each router in AP mode does not carry down the IPV6 setup from the main router connected to the modem.
It is now connected to the network. Looks like a reset of some hubs to verify IPV6 is on these. Hopefully moving the Hub to the loft has not knocked any devices offline.
Just hoping that now the sensor stays online and I will add it to HA and report back in 24hrs
Glad to hear you got it working! Based on your description, I have a theory about why flipping the UPnP switch solved it, even though Matter doesn’t use UPnP directly.
The “Hidden” mDNS Block I suspect the root cause was that mDNS (Multicast DNS) wasn’t being routed correctly between your main router and your Access Points. That explains why it worked when you connected the M3 Hub directly to the main router. By enabling UPnP, you likely forced the router (and APs) to open up Multicast traffic. Even though Matter doesn’t need UPnP, it absolutely needs mDNS. So, enabling UPnP just happened to unblock the necessary Multicast pathways as a side effect.
A note on IPv6 Addresses. My other theory is related to how your APs were handling IPv6 (possibly getting stuck on Link-Local addresses, which don’t route across segments). Toggling UPnP might have forced a configuration refresh that pushed the correct IPv6 prefix down to all devices.
One recommendation to prevent future dropouts: Check the IPv6 addresses of your Matter devices if you can:
Starts with fdxx::: This is great (Unique Local Address). It’s stable.
Starts with 2xxx::: Be careful. These are Global Addresses assigned by your ISP.
If your ISP forces a disconnect/reconnect (changing your IP prefix), devices relying solely on 2xxx addresses might drop offline until the new routing tables update, which can take a while. If you see this happen, try to configure your router to assign ULA (Unique Local Addresses / fdxx) as well.
Im installing the app now, well an andriod version.
Are we talking IPV4 or 6?
If 4 i should be fine, 6, I have never delved into them
So,
I have now brought the M3 from the main router in and connected to an AP
I have now prefixed IP4 addresses that may be needed.
Got the sensors back online and setup a automation to trigger some lights regardless of time of day.
Lets see how this goes
Edit:
So, around 1 hour ago I had both sensors online. I setup routines in HA for them to trigger my stair lighting with motion, no motion turn off…
The original has now stopped talking to HA completly. Not reporting back any LUX changes or triggers. I have now changed the batteries and got it back online. All the pairing etc when fighting with the network could have drained them.
The new sensor is still online.
I will report back again in 24hours but I am now failrly confident after doing the following:
Restting main router and a AP
Enabling IPV6 on main router
Enabling UPNP and all AP and main router
Gave all my hubs etc a static IP4 address
IPv6 is mandatory for Thread. Your Thread border router passes the IPv6 prefix (the first part of the address) to the P2, which then assigns itself an address. This does not work with IPv4.
