Commissioning Matter Devices - Inconsistencies

Configuration Matter/Thread
1

Hi folks,
The new IKEA stuff is out, so I opted to pick up a little Bilresa to give it a try. I admit I prefer the switch feel of the Roderet (and the old metal backplates for wall attachments they used to have), but it’s not awful and is a nice little thing.

I already have a single Matter device. A Tado Smart Thermostat X. Bad purchase, wouldn’t recommend, could have done what it’s doing far better with a Shelly after examining my wiring. Whatever, I’m rambling.

Have some real trouble with Commissioning.

Android commissioning has never worked (or it didn’t with the Tado anyway). I hence (when I initially got the Tado working) commissioned it directly in Python Matter Server with the Thread dataset and the commissioning code. The current error is that it can’t connect to the network. This is true even if I lower the firewall on my PC. I have got my network somewhat segregated using OpenWrt (different firewall zones), but I don’t think it’s separate VLANS (the definitions escape me here). In any case, the phone and the machine running the docker containers are on the same subnet and in the same firewall zone and are otherwise allowed to chat (and were in totality when I lowered the docker running computer’s firewall anyway). Both have static IPv6 addresses.

After getting IPv6 and a stable OTBR image/docker configuration it was all good. And still is. It paired instantly when I commissioned it to the new Thread network in the hope that that might get this working.

The Bilresa does not work with this with a very vague error log:

2025-12-20 02:26:32.578 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 77.
2025-12-20 02:26:32.579 (Dummy-2) CHIP_ERROR [chip.native.CTL] Error, Long discriminator is required
2025-12-20 02:26:32.579 (Dummy-2) CHIP_ERROR [chip.native.CTL] Failed to start commissionable node discovery over Wi-Fi PAF: src/controller/SetUpCodePairer.cpp:271: CHIP Error 0x0000002F: Invalid argument
2025-12-20 02:26:35.285 (Dummy-2) CHIP_ERROR [chip.native.CTL] Found unconnected device, removing
2025-12-20 02:26:36.627 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2025-12-20 02:26:39.865 (Dummy-2) CHIP_ERROR [chip.native.CTL] Error on commissioning step 'ThreadNetworkSetup': 'src/controller/CHIPDeviceController.cpp:3118: CHIP Error 0x000000AC: Internal error'
2025-12-20 02:26:39.865 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to commission: src/controller/CHIPDeviceController.cpp:3118: CHIP Error 0x000000AC: Internal error
2025-12-20 02:26:39.865 (MainThread) ERROR [matter_server.server.client_handler] [132363379736752] Error while handling: commission_with_code: Commission with code failed for node 77.

Just to complicate things, this is a Home Assistant running in docker. As is OTBR (using the Package hass-otbr-docker · GitHub image because regular OTBR (while I did get it working) was relatively unstable and stopped doing so after an update (which I didn’t really fully diagnose as the below worked). As is the Python Matter Server.

Docker host is an x86_64 Ubuntu 22.04 machine. I believe it uses Network Manager. The OTBR’s network appears up there as wpan0. Using a Zigbee Dongle (Sonoff Dongle E) with the darkxst Thread firmware flashed.

 otbr:
    hostname: otbr
    container_name: otbr
    image: "ghcr.io/ownbee/hass-otbr-docker:latest"
    privileged: true
    network_mode: host
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
      - NET_ADMIN    
    environment:
      DEVICE: "/dev/ttyUSB1"
      BACKBONE_IF: enp4s0 #enp3s0
      FLOW_CONTROL: 0
      FIREWALL: 1
      NAT64: 1
      BAUDRATE: 460800
      OTBR_REST_PORT: 8081
      OTBR_WEB_PORT: 7586
      AUTOFLASH_FIRMWARE: 0      
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /opt/openthread/thread:/var/lib/thread
  matter-server:
    container_name: matter-server
    image: ghcr.io/matter-js/python-matter-server:stable
    restart: unless-stopped
    environment:
      - TZ=Europe/London
    security_opt:
      - apparmor=unconfined
    privileged: true
    volumes:
      - /opt/matter-server:/data
      - /run/dbus:/run/dbus:ro
      - /dev/hci0:/dev/hci0
    network_mode: host
    command:
      --storage-path /data
      --paa-root-cert-dir /data/credentials
      --bluetooth-adapter 0
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /var/home-assistant:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
      - /dev/serial/by-id:/dev/serial/by-id
    restart: unless-stopped
    privileged: true
    network_mode: host
    environment:
      - TZ=Europe/London
      - PUID=800
      - PGID=1002
      - UMASK=007
      - PACKAGES=iputils

Relevant parts of the docker compose file I’m running off there.

No idea where to start. I do recall spending hours trying to get the thermostat to pair, but this was a year ago, so I honestly don’t remember what I did. I think the clincher was kernel parameters. I don’t know where to start, so any/all guidance appreciated.

I do wonder if the simplest thing would be to move towards virtualising Home Assistant, but I am comfortable on Docker so would rather not move over unless I absolutely have to. I’m quite fond of IKEA’s smart home bits, and don’t really want to have to give up using them because of the Thread transition (although even better would be if I could turn them into Zigbee devices; they can do Zigbee Touch Link; not found any guides like which I assume would exist if this were possible?).

Thanks :slight_smile:

2

Your setup is too complicated for me to diagnose.
What I do know is that the IKEA Matter devices can not do Zigbee.
They come with IKEA’s touchlink protocol-only, besides Matter.
There are no Zigbee functionality otherwise.

3

Some reports on github suggests that at least the Kajplats bulbs are pairing with Z2M. [New device support]: Ikea Kajplats Bulb (not working) · Issue #30211 · Koenkk/zigbee2mqtt · GitHub

4

True, but there are no function and features available.

5

Did you look at the link?

image
image4934×1962 402 KB

6

i can’t help but notice that you haven’t map ttyusb on host to otbr docker located on your compose file. try to add devices entry of ttyusb like on the compose file in ownbee github repo and provide logs of otbr after that

7

So, really bizarre, I guess the issue was something up with the version of the Thread border router I was using. Swapped the image for a fork (Package hass-otbr-docker · GitHub) listed on a blog (Part 4 - Thread border router - Home Assistant Connect ZBT-1(image: "ghcr.io/d34dc3n73r/hass-otbr-docker")) which seemed more up to date and the Android commissioning process worked… semi-perfectly. First time it said it was done but didn’t show. Second time it actually paired and is now showing up in Home Assistant. Wouldn’t pair through the Python Matter Server interface though.

I will say Thread/Matter is janky as hell for me as a Docker person. Not sure if there’s any plans to work on this - I guess Docker is kinda not really what’s recommended for Home Assistant, although would be nice for it to have parity with the OS (if possible). I kinda like having a single home server (so don’t want to sacrifice it to HAOS solely) and not too familiar with virtualisation.

Interesting about the bulbs. A Zigbee firmware option would be nice (or just a choice; the hardware can do both insofar as I understand; for less power users if your house is currently full of Zigbee devices Thread network is likely to be weaker/not extend as far - this is only my second Thread device and I have 96 Zigbee devices floating around of which 1/3 are routers).

Immediate criticism of the device - bottom button (clearly intended to be used to flick between lighting circuits) doesn’t register anything in Home Assistant directly (instead influences what the other three “buttons” do).

Just re: the TTY being missing; I find it odd it is working like this actually. I took it out temporarily for some reason some time ago, it had grabbed the Zigbee Dongle due to the ttyUSBX changing when I repositioned the dongles and hence was failing to run. But this didn’t actually make any difference. I have no idea quite why it’s behaving this way (does Privileged: True allow it to break out of the container?).

8

Yea… privileged container has all access to device in host, my bad. maybe the mapping is just to make the interface stable and docker aware of device availability ? just a guess.

afaik only ownbee and d34dc3n73r that has made hass compatible otbr, even then i still cannot change the channel from homeassistant. It kept saying it will change in 5 minute but it never changes. the only official image of otbr from homeassistant require supervisor. made me wonder is there any difference between homeassistant otbr and ownbee otbr for the api side

9

Bilresa, it appears, can do Zigbee within ZHA (ie. can fully integrate into a Zigbee network rather than just using touch link). Ish.

https://www.reddit.com/r/tradfri/comments/1plqavn/bilresa_on_zigbee/

I managed it with a full reset (hold pairing button in battery compartment till red lights go off). Four presses of button. Then 8 presses of button. LEDs on device then switch off. ZHA picked it up straight away.

What works/makes a zha_event:

  • Scroll wheel left/right registers
  • Top button registers

What doesn’t work/make a zha_event:

  • Bottom button does nothing (it also doesn’t register anything in Matter either; but here it also doesn’t change how the other buttons register)
  • Long presses/double presses/triple presses on the top button.
  • Pressing the top button is required to wake the device.
  • Moving the scroll wheel too fast for the device still results in it not registering all movements (eg. a rapid full turn will only result in it registering 1 or 2 events, this seems to be a problem in Matter also).

It seems to behave as if it’s giving instructions to a light directly, providing a number on the scroll wheel of 1 - 255 (under params/attributes). Button presses register as on/off events.