Adding thread device to HA via Android app ends with 'Something went wrong' (aqara Door and window P2)

Configuration Matter/Thread
, ,
1

I’m trying to connect to the Aqara P2 door and window thread device. I’ve been struggling a lot with this. I went through various issues so far:

  • I come from a conbee stick and upgraded to the skyconnect.
  • this failed and I ultimately resorted to creating a fully new zigbee network
  • Next the matter add-on wouldn’t work since I had a 32 bit rapsberry pi os.
  • next the radios were off (thread channel 15, zigbee channel 25), even when I just resettled everything.

Now finally, all the networks seem without error, but I can’t get the device connected.
Via the Android app, I choose ‘Add matter device’. I scan the code and it goes through various steps (connecting to device, generating matter keys, connecting to network, connecting device to home assistant). This final step never succeeds and ends with ‘something went wrong’.

63e9d4e14494836b18a9bae0207fba8c957b2be1
63e9d4e14494836b18a9bae0207fba8c957b2be11080×2084 35.7 KB

I’ve enabled debug logging for all relevant addons (Matter server, multiprotocol) & integrations (Thread, Thread Open Border Router, Matter). I don’t get any system errors, but I get the following errors in the Matter & multiprotocol addon.

Matter logs

2024-01-08 19:51:16 core-matter-server matter_server.server.device_controller[126] INFO Starting Matter commissioning on network using Node ID 5.
2024-01-08 19:51:46 core-matter-server chip.CTL[126] ERROR Mdns discovery timed out
2024-01-08 19:51:46 core-matter-server matter_server.server.client_handler[126] ERROR [547789116944] Error handling message: CommandMessage(message_id='bce8b7c9771347XXXXa03be5XXXX6fb5', command='commission_on_network', args={'setup_pin_code': 42XXX91, 'ip_addr': None})
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/client_handler.py", line 188, in _run_handler
    result = await result
             ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 261, in commission_on_network
    raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission on network failed for node 5

Multiprotocol logs

[21:34:43:137796] Info : Endpoint socket #12: Client connected. 2 connections
Listening on port 9999 for connection...
Accepting connection.
Accepted connection 7.
otbr-agent[307]: 05:50:46.596 [W] SrpServer-----: Send fail response: 5
otbr-agent[307]: 05:51:03.893 [W] Mle-----------: Failed to process Parent Request: Duplicated
otbr-agent[307]: 05:51:03.893 [W] Mle-----------: Failed to process Parent Request: Duplicated
otbr-agent[307]: 05:51:03.893 [W] Mle-----------: Failed to process Parent Request: Duplicated
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::78d4:10ff:fef0:4176/vethbe30783/40
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::78d4:10ff:fef0:4176/vethbe30783/40
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::78d4:10ff:fef0:4176/vethbe30783/40
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::78d4:10ff:fef0:4176/vethbe30783/40
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::78d4:10ff:fef0:4176/vethbe30783/40
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c18:41ff:fe65:73b3/veth152e1fb/42
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c18:41ff:fe65:73b3/veth152e1fb/42
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c18:41ff:fe65:73b3/veth152e1fb/42
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::9c18:41ff:fe65:73b3/veth152e1fb/42
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::f85b:8eff:fef7:457a/vethe3704fc/44
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::f85b:8eff:fef7:457a/vethe3704fc/44
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::f85b:8eff:fef7:457a/vethe3704fc/44
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::f85b:8eff:fef7:457a/vethe3704fc/44
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::f85b:8eff:fef7:457a/vethe3704fc/44
otbr-agent[307]: 1d.04:02:54.888 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:766, chksum:7dbb, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-48.625
otbr-agent[307]: 1d.04:02:54.901 [N] MeshForwarder-:     src:[fd04:49d7:ae2c:31e2:e22e:6dcc:7c05:ffcf]:49154
otbr-agent[307]: 1d.04:02:54.901 [N] MeshForwarder-:     dst:[fd04:49d7:ae2c:31e2:54c2:f335:d0a:3e90]:53538
Socket connection has been closed, restarting...
Listening on port 9999 for connection...
Accepting connection.
Accepted connection 7.
Restarting
[19:54:55:812808] Info : Endpoint socket #12: Client disconnected. 1 connections
[19:54:55:819984] Info : Client disconnected
[19:54:56:872225] Info : New client connection using library v4.3.1.0
[19:54:56:878218] Info : Endpoint socket #12: Client connected. 2 connections
Reusing socket from previous instance.

I’m using the following system

  • Home assistant 2024.1.2
  • Home Assistant OS 11.3
  • Supervisor 2023.12.0
  • Matter server 5.0.2
  • Silicon Labs Multiprotocol 2.4.2
  • Unifi wifi network
    • mDNS on
    • Multicast enhancement on/off → gives same error in both cases
  • Android phone for commissioning the devices
2 Likes
2

Does Home Assistant have IPv6 enabled?

3

Where could I check this?

4

Under settings > Network, I have the following settings:

image

Note that WLAN0 has it disabled, but also for IPv4

5

Scroll right down to the bottom of that page where it actually lists the IP addresses under the heading “Networking Adapter”

6

image

7

Right so you haven’t got a public IPv6 address from your router. Though I am not sure that matters too much, you do have a local network IPv6 address.

You should note however before going much further, the official advice from the HA Team, is that they don’t support (officially) connecting devices directly to Home Assistant, you should add it to Google or Apple first, and then share it to Home Assistant’s matter network from Google/Apple

8

Ah, I got that this was only the iOS advice. I didn’t know it was also valid for Android.
Anyway, happy to help debug things if that’s useful. I bought a Skyconnect and that’s currently my only Thread border router. So I don’t really have an alternative.

9

The last I heard on a github request for help, was that they won’t provide help for the Skyconnect when it is operating in multi protocol mode, because that’s very much still a work in progress.

10

Alright, that’s fair. I’ll try to set it up thread only in that case.

11

Found this related ticket by going through the Github Matter tickets (somehow it didn’t show up via Google). It is not per se multiprotocol but has the same errors that I’m experiencing.

I will track the progress over there.

12

Yes I just had a long read and saw the 2 main points, one I was aware of:

the only thing not possible is using your own OTBR (such as skyconnect) for thread based matter devices but that is experimental/in development anyways.

( Adding matter device failed · Issue #105790 · home-assistant/core · GitHub ) from the developers.

and the one I did not know about:

Are you all -by any chance- using Android to commission the device ?
We have a bug/issue with the Android app currently so using that to commission devices will fail. A new Android app update will be launched as soon as possible.

For the time being, the best way to work around this, is using the iOS companion app OR if you want to use Android: Commission the device first to Google home and then share it from there to HA.

( Adding matter device failed · Issue #105790 · home-assistant/core · GitHub ) Also from the developers.

1 Like
13

I guess this is exactly what goes wrong. The fix is released, but not yet available in the app store. I guess I’ll wait a few more days.

Thanks for the help!

14

Oh, that makes a lot of sense, and of course the more often you try to commision within that ~2h window, the more stale entries will be left behind.

15

Same issue. I ended up using Google home then shared the device back to home assistant. Even with Google home, it stuck at adding to Google home page. I ended the adding device process manually. Suprisely, the device already in my Google home.
Either google or home assistant can add this cheap Aqara sensor without issue. Guess cheap comes with price…

16

There is absolutely no logical consistency in this. Driving myself mad trying to get a bunch of devices connected.

It seems like I can add 2 devices then it just stops working. Then you give it like 12hrs and you can add some more.

Even having HA Beta android app and beta enabled on the HA server makes no difference.
Cannot add direct or by sharing from google home or any other way.

The only thing I have been able to cross reference is when they add fine, there is no logs of this:

2024-01-19 13:46:52 core-matter-server chip.DIS[223] ERROR OperationalSessionSetup[1:000000000000000D]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout

Then when that starts, none of the matter devices can be added.

No idea how to clear that error out, it seems after leaving it overnight it was just ok and i could add a couple again. Going to see if again leaving it for a number of hours then trying again works.

Just makes no sense, if it was consistent I could accept it, but work then not work is driving me crazy