Adding previously working matter device failed (stuck in 'Setting Up')

Configuration Matter/Thread
1

Hi,

I’m trying to add a matter device (Aqara P2 motion) to my Home Assistant but it keeps getting stuck at ‘Setting Up’ and eventually ends up in ‘Unable to add accessory - Home couldn’t connect to this accessory’.

I’m running a dockerized setup and all docker containers are up-to-date. I’m using the Home Assistant companion app on iPhone (running latest app version and latest iOS).

What I’ve done so far:

  • I’ve reset the sensor (long press 5 seconds or 10x short press) but the result remains the same.
  • I’ve shared credentials with companion app (and vice versa)
  • I’ve cleared browser cache
  • I’ve re-installed the home assistant app
  • I’ve rebooted all the containers

The home assistant container and matter-server container are not reporting anything out of the ordinary. The matter-server is ‘chatty’ as always and home assistant doesn’t bother to output anything that seems matter / tread related.

The OTBR docker is outputting the below. Not sure what this means though.

00:00:38.115 [W] DuaManager----: Failed to perform next registration: NotFound
00:00:38.412 [W] P-RadioSpinel-: Error processing result: NoAddress
00:00:38.412 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:00:43.054 [W] P-RadioSpinel-: Error processing result: NoAddress
00:00:43.054 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:00:43.611 [W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
Default: mDNSCoreReceiveResponse: Received from fe80::2cd9:a4ff:fe47:88a9:5353   14 9.a.8.8.7.4.e.f.f.f.4.a.9.d.c.2.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 9.A.8.8.7.4.E.F.F.F.4.A.9.D.C.2.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from fe80::74b6:35ff:feec:78b2:5353   14 2.b.8.7.c.e.e.f.f.f.5.3.6.b.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 2.B.8.7.C.E.E.F.F.F.5.3.6.B.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from fe80::80b6:d0ff:fe17:4813:5353   14 3.1.8.4.7.1.e.f.f.f.0.d.6.b.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 3.1.8.4.7.1.E.F.F.F.0.D.6.B.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from 172.10.0.1:5353   14 1.b.e.2.d.5.e.f.f.f.5.6.a.e.c.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 1.B.E.2.D.5.E.F.F.F.5.6.A.E.C.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from 172.10.0.1:5353   14 1.0.10.172.in-addr.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 1.0.10.172.in-addr.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from 172.17.0.1:5353   14 1.0.17.172.in-addr.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 1.0.17.172.in-addr.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from 192.168.1.73:5353   14 73.1.168.192.in-addr.arpa. PTR rpi4-6.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 73.1.168.192.in-addr.arpa. PTR rpi4.local.
Default: mDNSCoreReceiveResponse: Received from 192.168.1.73:5353   14 c.9.3.2.c.9.7.9.e.3.a.e.d.7.3.4.1.d.c.d.4.3.0.c.d.9.2.9.5.9.d.f.ip6.arpa. PTR rpi4-9.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   12 C.9.3.2.C.9.7.9.E.3.A.E.D.7.3.4.1.D.C.D.4.3.0.C.D.9.2.9.5.9.D.F.ip6.arpa. PTR rpi4.local.
00:04:54.390 [W] P-RadioSpinel-: Error processing result: NoAddress
00:04:54.390 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:05:02.101 [W] P-RadioSpinel-: Error processing result: NoAddress
00:05:02.101 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:05:03.489 [W] P-RadioSpinel-: Error processing result: NoAddress
00:05:03.489 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:05:17.347 [W] Mle-----------: Failed to process Child ID Request: Security
00:05:17.536 [W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
00:05:18.003 [W] P-RadioSpinel-: Error processing result: NoAddress
00:05:18.003 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:05:18.835 [W] Mle-----------: Failed to process Parent Request: Duplicated
00:05:21.203 [W] P-RadioSpinel-: Error processing result: NoAddress
00:05:21.203 [W] P-RadioSpinel-: Error waiting response: NoAddress

All already connected matter devices (sensors and light switches) are working just fine so matter seems to work. The sensor i try to add used to work before…

Any suggestions where to look to solve this problem?

2

Okay, small update:

I’ve tried adding a brand new Matter sensor to rule out any problems with the one I’m trying to add (I know, bit of a long shot but hey…). The new sensor didn’t work either so it’s definitely a problem in my setup.

The mDNSCoreReceiveResponse: Unexpected conflict discarding .... error seems to be solved by disabling the avahi service.

sudo systemctl stop avahi-daemon.service
sudo systemctl stop avahi-daemon.socket
sudo systemctl disable avahi-daemon.service
sudo systemctl disable avahi-daemon.socket
sudo systemctl mask avahi-daemon.service
sudo systemctl mask avahi-daemon.socket

Now chatGPT believes that the failure of adding the sensor is caused by the ZBT-1 firmware not matching with the OTBR version. Not sure if this makes sense but I did update the docker container recently though so might be worth checking out.