Unsuccessful matter device pairing using HA Container (Synology NAS) & Python Matter Server (RPi)

Configuration Matter/Thread
1

Disclaimer: I have already successfully paired a low energy matter device (Bosch Door/Window Sensor Contact II +M) successfully via my GL-S20 OTBR and Pi-/Docker-based Python Matter Server.

BUT I am failing and desperately trying to pair and integrate into my HA a nous device (smart power plug A8M). It supports matter over wifi, so I thought this should be a no-brainer with my python-matter-server on an RPi 4 Model B Rev 1.1.

Pairing of the plug via OTBR works fine.

Bluetooth is enabled on the matter server as per Pi OS and also docker-compose:

services:
  # python-matter-server
  home-matter-server:
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    container_name: home-matter-server
    restart: unless-stopped
    # Required for mDNS to work correctly
    network_mode: host
    security_opt:
      # Needed for Bluetooth via dbus
      - apparmor:unconfined
    volumes:
      # Create an .env file that sets the USERDIR environment variable.
      - ./data:/data #${USERDIR:-$HOME}/docker/matter-server/data:/data/
      # Required for Bluetooth via D-Bus
      - /run/dbus:/run/dbus:ro
    # If you adjust command line, make sure to pass the default CMD arguments too:
    command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0
    deploy:
      resources:
        limits:
          memory: 250M
          #cpus: "4.0"

However, upon pairing, the matter server docker logs -f reports:

2025-04-25 10:31:45.495 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning using Node ID 12 and IP 192.168.1.139.
2025-04-25 10:31:45.496 (Dummy-2) CHIP_ERROR [chip.native.CTL] Found unconnected device, removing
2025-04-25 10:31:47.464 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2025-04-25 10:32:20.816 (Dummy-2) CHIP_ERROR [chip.native.DIS] Timeout waiting for mDNS resolution.
2025-04-25 10:32:34.806 (Dummy-2) CHIP_ERROR [chip.native.DIS] OperationalSessionSetup[1:000000000000000C]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout
2025-04-25 10:32:34.808 (Dummy-2) CHIP_ERROR [chip.native.CTL] Session establishment failed for <000000000000000C, 1>, error: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout.  Next retry expected to get a response to Sigma1 or fail within 60 seconds
2025-04-25 10:33:05.821 (Dummy-2) CHIP_ERROR [chip.native.DIS] Timeout waiting for mDNS resolution.
2025-04-25 10:33:19.813 (Dummy-2) CHIP_ERROR [chip.native.DIS] OperationalSessionSetup[1:000000000000000C]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout
2025-04-25 10:33:19.816 (Dummy-2) CHIP_ERROR [chip.native.CTL] Session establishment failed for <000000000000000C, 1>, error: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout.  Next retry expected to get a response to Sigma1 or fail within 60 seconds
2025-04-25 10:33:50.833 (Dummy-2) CHIP_ERROR [chip.native.DIS] Timeout waiting for mDNS resolution.
2025-04-25 10:34:04.817 (Dummy-2) CHIP_ERROR [chip.native.DIS] OperationalSessionSetup[1:000000000000000C]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout
2025-04-25 10:34:04.818 (Dummy-2) CHIP_ERROR [chip.native.CTL] Error on commissioning step 'kFindOperationalForStayActive': 'src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout'
2025-04-25 10:34:04.820 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to commission: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:123: CHIP Error 0x00000032: Timeout
2025-04-25 10:34:04.822 (MainThread) ERROR [matter_server.server.client_handler] [548190228448] Error while handling: commission_on_network: Commissioning failed for node 12.

I have spent hours searching this forum and chatting with Google’s Gemini to no avail. Gemini probably rightfully points in the direction of mDNS failing, but its configuration proposals for my Pi didn’t really solve the problems.

Could it be that pairing just with a matter-server just doesn’t work? Do I need a specific, bluetooth-capable “dongle/router/hub” such as an Aqara M3, a GL-S20, or such? I mean how does HA know anyway whether to use the OTBR for pairing or “just” the matter server?

Gemini’s recommendations (mainly aimed at trying to fix mDNS problems)

  • /etc/avahi/avahi-daemon.conf
    • Set use-ipv4=yes
    • Set use-ipv6=yes
    • Set publish-aaaa-on-ipv4=yes
    • Set publish-a-on-ipv6=yes
  • Restart Avahi daemon - Apply configuration changes
  • /etc/nsswitch.conf - Ensure mdns4_minimal and mdns6 are listed before dns in the hosts: line
  • Restart network services (NetworkManager, systemd-resolved, nscd) - Apply nsswitch.conf changes
  • Firewall (iptables)
    • Allow incoming/outgoing UDP traffic on port 5353 from/to Matter device IP 192.168.1.139
    • Allow incoming/outgoing UDP traffic on port 5353 from/to Matter device IPv6 ::3a2c:e5ff:fe3f:8e49
    • Temporarily set FORWARD policy to ACCEPT (for testing)

Hardware Setup

  • Network:
    • AVM Fritz!BOX 4060 router as mesh master
    • AVM Fritz!BOX 7530 router as mesh slave
    • Powerline adapters from apartment to basement
      • AVM Powerline Adapter
      • Devolo Powerline Adapter
  • HA-relevant Devices:
  • Special conditions worth mentioning
    • The OTBR is in my basement, connected to the mesh-slave directly by cable (wifi deactivated)
    • The slave router is connected to master router via PowerLine (devolo>Fritz!Powerline>master)
    • The Python-Matter-Server is connected to master via cable>switch>repeater>wifi>master

Again, the setup IS working for my door/window sensor (low energy matter) in the basement (connected to HA via OTBR, PowerLine, Python-Matter-Server).

2

OTBR is routing software, in other words it just takes packets from one subnet, looks at their destination address, and forwards them to the next-hop subnet accordingly. It is no different than your WiFi router from HA’s perspective, in that it’s just network infrastructure.

In the first phase of commissioning (sometimes called pre-commissioning) the Matter server (or mobile app) uses Bluetooth to communicate with a device to send it the proper credentials to get on your (Thread or WiFi) network. Once it has an IP address on the network, further communication takes place with the python matter server. This part requires mDNS, which is an IP multicast protocol, for discovery.

When troubleshooting commissioning, it’s important to specify which method you’re using (server Bluetooth, or mobile app and which one). You can determine if pre-commissioning worked by running a mdns discovery app (on the same subnet as the device), such as Flame for iOS/macOS, to show all the announcements on that subnet, which should include _matterc._udp (commissioning service) from your new device or _matter._tcp (matter service) for fully commissioned devices.

Once precommissioning succeeds, usually WiFi Matter is more straightforward than Thread because it doesn’t require the extra router hop through the border router. You shouldn’t even need Avahi unless you have multiple wifi vlans? Be sure the Matter server is on the same subnet (broadcast domain) as the new device being commissioned.

3

Hi @peterxian, thanks for the reply.

for pairing, I used my Android mobile HA app which let me scan the QR code. BT on the Matter Server (RPi 4) was enabled as per docker-compose, but I guess not used for commissioning.

Executing an avahi-browse -a on the matter server revealed that the new device is listed as _matter._tcp item., Still, no luck.