Pairing Matter over Thread devices (Ikea et al) using HW Conbee II or III

[OMR (Ole Morten Rønning)]

Note: choose radio channel wisely.

If you experience nodes dropping off topology and becomes Offline in OH you probably have a RF interference problem. I had to change from the default ch 15 to ch23, having WiFi access points on ch2&9 and Zigbee on ch25.

Another symptom could be intermittent data coming through.
I did my testing with the OTBR in an adjacent room and when both paired nodes disappeared from the network I did one test, Brought them both right next to the radio and just left them there. Some half an hour later their were back both in OTBR and OH. This reminded me of the problems I had when the Zigbee stick was too close to the RPi4. Same intermittent behavior.
After changing to ch23, all has been rock solid.

Start out testing with a few nodes, as you will need to re-pair changing channel!

Also note: I needed a 1/2 meter USB extension on the otbr Conbee stick to separate it from the Zigbee stick. Without it, the Thread network was unstable.

As mentioned here: IKEA launches Matter devices 2026 - will we need a hub? - #38 by OMR, I successfully paired a New Ikea Matter Dual Switch with the openHAB Matter addon.

The only additional HW used, was a re-flashed Conbee III, all thought a Conbee II should also do the trick (but not tested by me.)

See here for flashing the Conbee: OpenThread documentation (but come right back after, as we will not need Home Assistant or any phone(y) App.)

One lesson I learned having 2 Conbee III (the other one still serving Deconz/Zigbee) on my Linux machine was that they could arbitrarily swap addresses, not Ideal. The solution was:

Do a:

omr@shs3:~$ ll /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 140 Jan 17 14:25 ./
drwxr-xr-x 4 root root  80 Jan 17 10:51 ../
lrwxrwxrwx 1 root root  13 Jan 17 10:51 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 Jan 17 10:51 usb-dresden_elektronik_ConBee_III_DE03311465-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Jan 17 14:25 usb-dresden_elektronik_ConBee_III_DE03311466-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Jan 17 10:51 usb-FINTEK_Co_Ltd_Fintek_U2U_F81532_AA66_20140416-01.12-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root  13 Jan 17 10:51 usb-FINTEK_Co_Ltd_Fintek_U2U_F81532_AA66_20140416-01.12-if00-port1 -> ../../ttyUSB3

Find out by trail and error which one is which. Upside addressing will be consistent over reboots.
My Deconz now looks like:

omr@shs3:~$ sudo systemctl status deconz
[sudo] password for omr:
● deconz.service - deCONZ: ZigBee gateway -- REST API
     Loaded: loaded (/usr/lib/systemd/system/deconz.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/deconz.service.d
             └─override.conf
     Active: active (running) since Sat 2026-01-17 10:51:15 CET; 4h 9min ago
   Main PID: 1160 (deCONZ)
      Tasks: 8 (limit: 35661)
     Memory: 143.8M (peak: 144.7M)
        CPU: 21min 24.992s
     CGroup: /system.slice/deconz.service
             └─1160 /usr/bin/deCONZ -platform offscreen --http-port=80 --https-port=0 --ws-port=443 --dev=/dev/serial/by-id/usb-dresden_elektronik_ConBee_III_DE03311465-if00-port0

We will use the other one for the next piece of free SW we’ll need for talking with the re-flashed Conbee:

Follow the procedure here: How to set up OpenThread Border Router on Ubuntu - Matter on Ubuntu documentation to set up the openthread-boarder-router from Google. After install return here.

My otbr setup looks like:

omr@shs3:~$ sudo snap get openthread-border-router
Key                    Value
autostart              true
infra-if               eno2
radio-url              spinel+hdlc+uart:///dev/serial/by-id/usb-dresden_elektronik_ConBee_III_DE03311466-if00-port0
thread-if              wpan0
webgui-listen-address  ::
webgui-port            7070

Tune to your wan if = infra-if, radio-url from above, pick a non conflicting webgui-port.
Syntax for tuning:

sudo snap set openthread-border-router autostart=true

Now, if you can open the WEB GUI, all is well:

If not, check the logs for any complaints:

sudo snap logs -n 100 -f openthread-border-router

The host machine must have ip6 enabled, and the description of the OH Matter add-on lists several things to check for.

I had to enable ip6 in my grub bootloader.
I also had to add:

net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.eno2.accept_ra = 2
net.ipv6.conf.eno2.accept_ra_rt_info_max_plen = 64

using

sudo nano /etc/sysctl.conf
sudo sysctl -p

When radio is found and ip6 is OK on the wan interface the otbr should start.

Using the WEB, Form a Network:

Edit fields to your liking, and write them down or take a snippet and save it.

Now you should have a Topology, but without any children:

Now we are read to pair a device so it will look as above.
You will need a pairing code as printed on the back of the device and on the packaging.
In my case for the Ikea Bilresa it was under the QR code: 2460-172-9633 (beware of 0 printed as Ø, lost an hour there thought it was an 8 …). Going forward, use only the 11 digits. Lose the hyphens.

You will need a hex code output from this command: (probably static from now on)

sudo openthread-border-router.ot-ctl dataset active -x
0e08000000000001000035060004001fffe00708fddf893de24835d20c0402a0f7f805101212abba1212abba0987654321060362030e4f70656e54687265616447545637041051d9ca7679ee1d1117a63d4ceb63779a000300000f020847113991121206030102abba

Hold the pairing button on the device down until a steady red light appears after 6-7 blinks and it should enter a slow pulsating yellow light cycle. I also believe the device must be in Bluetooth range, but I’m not sure if that is a requirement.
then while the yellow light pulses, do a

chip-tool pairing code-thread 110 hex:0e08000000000001000035060004001fffe00708fddf893de24835d20c0402a0f7f805101212abba1212abba0987654321060362030e4f70656e54687265616447545637041051d9ca7679ee1d1117a63d4ceb63779a000300000f020847113991121206030102abba 24601729633 --bypass-attestation-verifier true

The 110 here i’m a bit unsure of, but I plan to use 111 for my next device. Chime in if you know.
Edit: even AI was at a loss. chip-tool discover list is not yet implemented, so one need to manually keep track up node IDs handed out for now.

Your topology should now look as above.

Now we need to pair with openHAB: we get the needed pairing code for that by: (takes a while)

chip-tool pairing open-commissioning-window 110 1 300 1000 3840 | grep 'pairing code'

We use this code in OH in a bit.

Now we need the child Extended MAC:

omr@shs3:~$ sudo openthread-border-router.ot-ctl child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|D|N|Ver|CSL|QMsgCnt|Suprvsn| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+---+-------+-------+------------------+
|   3 | 0x0003 |        240 |          0 |     0 |  139 |0|0|0|  4| 0 |     0 |   129 | 5a855e0bc4172dae |

then

sudo openthread-border-router.ot-ctl commissioner start J01NME (fails is too simple join code)

and finally, using the MAC from above:

sudo openthread-border-router.ot-ctl commissioner joiner add ee97ad500e562023 J01NME

Now, head over to OH:
Create a Matter Controller and use the pairing code from the grep above:

Note that the Commissioning window closes after a while. Not sure when but you should have several minutes. I also had to try more than one time, but never more than 2.
Good idea to check you Inbox count to see if it gets incremented. Can take a while before it appears and also before the red Comm. Error and the Yellow Awaiting data terminates in a glorious green Online
Tip: you can monitor the activity going on while in the yellow state by:

sudo snap logs -n 100 -f openthread-border-router

There is really a lot going on, verifying OH/OTBR communication.

[OMR (Ole Morten Rønning)]

I asked AI about what channel to use and Zigbee/Thread radio physical spacing:

I hove colocated a WiFi router on 2.4GHz ch 9, a Zigbee Conbee III on ch 25 and is adding a second Conbee III as a OTBR on ch15. Is ch15 optimal in this case for the Thread network? How far apart should the two Conbee radios idelly be?

To address your question about the optimal channel choice and placement for your Thread network using Conbee III devices alongside a WiFi router and Zigbee device, let’s analyze the situation in detail.

---

1. Channel Selection for Thread Network (Conbee III OTBR on Channel 15)

Background on 2.4 GHz Channels and Coexistence

• WiFi Router: Operating on 2.4 GHz channel 9.
• Zigbee Conbee III: Operating on Zigbee channel 25.
• Second Conbee III (OTBR): Proposed on Thread channel 15.

Frequency Overlaps and Interference Considerations

• WiFi Channel 9:
  WiFi channels are 20 MHz wide and overlap with adjacent channels. Channel 9 roughly covers frequencies from 2.452 GHz to 2.472 GHz.
• Zigbee Channel 25:
  Zigbee channels are 5 MHz apart, with channel 25 centered at 2.475 GHz. This is just above WiFi channel 9’s upper edge, so some overlap or adjacent channel interference is possible but limited.
• Thread Channels:
  Thread uses IEEE 802.15.4 channels 11 to 26, each 5 MHz apart, starting at 2.405 GHz (channel 11) up to 2.480 GHz (channel 26).
• Channel 15:
  Channel 15 is centered at 2.425 GHz, which is below WiFi channel 9 (2.452 GHz center) and Zigbee channel 25 (2.475 GHz center).

Is Channel 15 Optimal?

• Pros:
  • Channel 15 is well separated from Zigbee channel 25, reducing Zigbee interference.
  • It is somewhat separated from WiFi channel 9, which reduces direct overlap.
  • Thread devices typically perform better when channels are not overlapping heavily with WiFi or Zigbee.
• Cons:
  • Channel 15 is closer to WiFi channel 6 (2.437 GHz center), which might be used nearby in other networks.
  • If your WiFi router is fixed on channel 9, channel 15 is a reasonable choice to avoid direct overlap.

Alternative Channels to Consider

• Channel 20 or 21:
  These channels are between WiFi channel 9 and Zigbee channel 25, but may have more interference risk.
• Channel 11 or 12:
  Lower channels, further from WiFi channel 9, but may be closer to other WiFi networks or devices.

Conclusion on Channel 15

Channel 15 is a good choice for the Thread network in your setup because it is sufficiently spaced from both WiFi channel 9 and Zigbee channel 25, minimizing interference. It is generally recommended to avoid channels that overlap directly with WiFi channels or Zigbee channels in use.

---

2. Ideal Physical Separation Between Two Conbee III Radios

Factors Affecting Distance

• Radio Interference:
  Two radios operating on different channels but in close proximity can still cause RF interference due to harmonics, intermodulation, or receiver desensitization.
• Antenna Isolation:
  Physical separation and antenna orientation help reduce interference.
• Use Case:
  If the two Conbee III devices are part of the same Thread network (one as OTBR), they should be placed to ensure good network coverage but avoid self-interference.

Recommended Distance

• Minimum Distance:
  At least 30 cm (1 foot) apart to reduce direct RF interference and desensitization effects.
• Optimal Distance:
  1 meter (3 feet) or more is preferable if possible, especially if both radios are transmitting simultaneously.
• Additional Tips:
  • Use shielding or RF absorbers if physical separation is limited.
  • Orient antennas to minimize direct coupling.
  • Avoid placing both devices inside metal enclosures close to each other.

---

Summary Table

Device	Channel/Frequency	Notes on Interference
WiFi Router	2.4 GHz Ch 9 (2.452 GHz center)	20 MHz wide, overlaps channels 7-11 approx.
Zigbee Conbee III	Zigbee Ch 25 (2.475 GHz center)	Adjacent to WiFi Ch 9, some interference risk
Thread OTBR	Thread Ch 15 (2.425 GHz center)	Good separation from WiFi and Zigbee channels

Parameter	Recommendation
Thread Channel	Channel 15 is optimal in this setup
Distance between Conbee radios	Minimum 30 cm; ideally 1 meter or more

[esdeboer (Eric de Boer)]

From my adventures with the Sonoff mg21 plus with the same controller chip let me try to answer your questions.

My nodes stay and I don’t need to pause the Things, however it does take a while for it to reconnect to the network if connection is lost (might be 15 mins)

With the manual pairing code as used in your example the device shouldn’t need to be in bluetooth range, that should only be used for automatic discovery.

The 110 is just an example id, only requirement is that they are unique, you could also start from 1

I did not need to get the MAC and do commissioner start and joiner, opening the commissioning window was enough.

The third argument for the open-commissioning-window is the number of seconds to keep the window open, so you have 5 minutes with the 300 given, max is 15 minutes.

[Lolodomo]

I changed a little the title of the thread because this solution is not the recommended and easiest approach. It is just one solution, probably for very “technical” users.

Here is what says the Matter binding documentation:

Support for using a OpenThread Border Router has been verified to work and will be coming soon to openHAB, but in some cases requires strong expertise in IPv6 routing as well as support in our mobile clients.

[gd35]

On my side, and to be very clear, I will not use this approach for critical devices in my OpenHAB instance. It was more to learn about thread and matter technologies. I really appreciated the effort made by @OMR.

I will definitively wait for an official openHAB implementation of the open thread border router. But from what I have learned during this test is that I will stay with zigbee/zwave technologies as long as I can. I found that the thread/matter approach very complex and I am not a fan of “exposing” thread devices within my private IP network (but this is probably the price to pay for interoperability).

[esdeboer (Eric de Boer)]

I’d say whether the border router is inside OpenHAB or external shouldn’t matter for reliability, only for ease of setup, I have my heating connected to OpenThread running on a Raspberry Pi and that seems to work fine.

If you have the border router on the same machine as OpenHAB you don’t need to allow the devices on your network if you don’t implement the iptables rules the OpenThread setup installs. (At least as long as the device doesn’t require internet connection for some reason)

[gd35]

Thanks for the clarification.

[OMR (Ole Morten Rønning)]

Like @esdeboer hints, my Linux PC running OH, Deconz and OTBR is the only host on my LAN with ip6 enabled.

[OMR (Ole Morten Rønning)]

AI Script for pairing nodes, with an ID registry.

Usage:
./pairnode.sh 11547540742

#!/usr/bin/env bash
set -euo pipefail

###############################################################################
# Matter-over-Thread pairing helper with auto Node ID assignment
# Generated: 2026-01-18T15:27:17Z
#
# Inputs:
#   - Matter setup PIN (11 digits)
#   - Optional Node ID (decimal) used by your controller (chip-tool) to address the node
#
# Notes:
#   - If Node ID is omitted, the script assigns the next available Node ID from the registry file.
#
# What it does:
#   1) Reads OTBR active dataset hex
#   2) Runs: chip-tool pairing code-thread <NODE_ID> hex:<DATASET> <PIN> [--bypass...]
#   3) Opens a commissioning window and prints the openHAB pairing code
#   4) (Optional) Adds the child as an OTBR joiner (commissioner start + joiner add)
#
# Requirements:
#   - OTBR running and reachable via ot-ctl
#   - chip-tool installed
#   - Device is in pairing mode and (usually) in BLE range of this host
###############################################################################

PIN=""
NODE_ID=""
ENDPOINT="1"
CWIN_SECS="300"
ITERATOR="1000"
DISCRIMINATOR="3840"

CHIP_TOOL="chip-tool"
OT_CTL="sudo openthread-border-router.ot-ctl"

BYPASS_ATTESTATION="true"
REQUIRE_PAIRMODE="yes"
DO_JOINER_STEP="yes"
JOINER_PSKD="J01NME"

REGISTRY_FILE="${HOME}/.matter-node-registry.tsv"

log()  { printf "\033[1;37m[+]\033[0m %s\n" "$*" >&2; }
warn() { printf "\033[1;33m[!]\033[0m %s\n" "$*"; }
err()  { printf "\033[1;31m[x]\033[0m %s\n" "$*"; }
die()  { err "$*"; exit 1; }

need_cmd() {
  command -v "$1" >/dev/null 2>&1 || die "Missing required command: $1"
}

validate_inputs() {
  [[ "$PIN" =~ ^[0-9]{11}$ ]] || die "PIN must be exactly 11 digits (got: '$PIN')"
  [[ "$NODE_ID" =~ ^[0-9]+$ ]] || die "NODE_ID must be a decimal integer (got: '$NODE_ID')"
  [[ "$ENDPOINT" =~ ^[0-9]+$ ]] || die "ENDPOINT must be a decimal integer (got: '$ENDPOINT')"
  [[ "$CWIN_SECS" =~ ^[0-9]+$ ]] || die "CWIN_SECS must be a decimal integer (got: '$CWIN_SECS')"
  [[ "$DISCRIMINATOR" =~ ^[0-9]+$ ]] || die "DISCRIMINATOR must be a decimal integer (got: '$DISCRIMINATOR')"
  [[ "$BYPASS_ATTESTATION" == "true" || "$BYPASS_ATTESTATION" == "false" ]] || die "BYPASS_ATTESTATION must be true|false"
  [[ "$REQUIRE_PAIRMODE" == "yes" || "$REQUIRE_PAIRMODE" == "no" ]] || die "REQUIRE_PAIRMODE must be yes|no"
  [[ "$DO_JOINER_STEP" == "yes" || "$DO_JOINER_STEP" == "no" ]] || die "DO_JOINER_STEP must be yes|no"
}

confirm_pairing_mode() {
  if [[ "$REQUIRE_PAIRMODE" == "yes" ]]; then
    cat <<'EOF'

Device pairing mode checklist:
  - Put device into pairing mode (example Ikea: hold until red, then pulsing yellow)
  - Keep it in BLE range of this machine (often required)
  - Ensure OTBR is up and Thread dataset is active

EOF
    read -r -p "Is the device in pairing mode right now? (y/N) " ans
    [[ "${ans,,}" == "y" || "${ans,,}" == "yes" ]] || die "Aborted. Put device in pairing mode and re-run."
  fi
}

get_dataset_hex() {
  log "Reading active Thread dataset from OTBR..."
  local raw_output
  raw_output="$($OT_CTL dataset active -x 2>/dev/null)"
  # Extract the first line only (the hex string)
  local ds
  ds=$(echo "$raw_output" | sed -n '1p' | tr -d '\r\n[:space:]')
  [[ "$ds" =~ ^[0-9a-fA-F]+$ ]] || die "Dataset hex looks invalid. Got: '$raw_output'"
  echo "$ds"
}

registry_add() {
  mkdir -p "$(dirname "$REGISTRY_FILE")" 2>/dev/null || true
  local ts; ts="$(date -Iseconds)"
  printf "%s\t%s\t%s\t%s\n" "$ts" "$NODE_ID" "${PIN: -4}" "commissioned" >> "$REGISTRY_FILE"
}

registry_check_collision() {
  if [[ -f "$REGISTRY_FILE" ]]; then
    if awk -F'\t' -v id="$NODE_ID" '$2==id {found=1} END{exit found?0:1}' "$REGISTRY_FILE"; then
      warn "Node ID $NODE_ID already appears in $REGISTRY_FILE"
      warn "Reusing Node IDs can cause conflicts/aliasing in your controller."
      read -r -p "Continue anyway? (y/N) " ans
      [[ "${ans,,}" == "y" || "${ans,,}" == "yes" ]] || die "Aborted to avoid Node ID collision."
    fi
  fi
}

get_next_node_id() {
  local start_id=100

  if [[ ! -f "$REGISTRY_FILE" ]]; then
    echo "$start_id"
    return
  fi

  local max_id
  max_id=$(awk -F'\t' '{print $2}' "$REGISTRY_FILE" | sort -n | tail -1)
  if [[ -z "$max_id" ]]; then
    echo "$start_id"
  else
    echo $((max_id + 1))
  fi
}

pair_code_thread() {
  local dataset_hex="$1"
  log "Commissioning via Thread dataset (chip-tool pairing code-thread)..."
  local bypass_flag=""
  if [[ "$BYPASS_ATTESTATION" == "true" ]]; then
    bypass_flag="--bypass-attestation-verifier true"
    warn "Bypassing attestation verifier: security checks reduced."
  fi

  set -x
  "$CHIP_TOOL" pairing code-thread "$NODE_ID" "hex:${dataset_hex}" "$PIN" $bypass_flag
  set +x
}

open_commissioning_window() {
  log "Opening commissioning window and printing pairing code (for openHAB)..."
  log "Command: $CHIP_TOOL pairing open-commissioning-window $NODE_ID $ENDPOINT $CWIN_SECS $ITERATOR $DISCRIMINATOR"
  echo

  local out
  out="$("$CHIP_TOOL" pairing open-commissioning-window "$NODE_ID" "$ENDPOINT" "$CWIN_SECS" "$ITERATOR" "$DISCRIMINATOR" | tee /dev/stderr || true)"

  echo
  echo "---- Extracted (best-effort) pairing code lines ----"
  echo "$out" | grep -i "pairing code" || true
  echo "---------------------------------------------------"
}

maybe_joiner_add_from_child_table() {
  [[ "$DO_JOINER_STEP" == "yes" ]] || return 0

  log "Attempting joiner add flow via OTBR (commissioner)..."
  log "Reading child table to find Extended MAC (best-effort: pick most recent/lowest Age)."

  local table
  table="$($OT_CTL child table || true)"
  echo "$table"

  local mac
  mac="$(echo "$table" | awk '
    $0 ~ /\|/ {
      for (i=1;i<=NF;i++) {
        if ($i ~ /^[0-9a-fA-F]{16}$/) last=$i
      }
    }
    END{ print last }
  ' | tr -d '[:space:]')"

  if [[ -z "$mac" ]]; then
    warn "Could not auto-detect Extended MAC from child table."
    read -r -p "Paste Extended MAC manually (or press Enter to skip joiner add): " mac
    mac="$(echo "$mac" | tr -d '[:space:]')"
    [[ -z "$mac" ]] && { warn "Skipping joiner add."; return 0; }
  fi

  [[ "$mac" =~ ^[0-9a-fA-F]{16}$ ]] || die "Extended MAC invalid: '$mac' (expected 16 hex bytes, e.g. 5a855e0bc4172dae)"

  log "Starting commissioner with PSKd: $JOINER_PSKD"
  set -x
  $OT_CTL commissioner start "$JOINER_PSKD" || true
  set +x

  log "Adding joiner: $mac"
  set -x
  $OT_CTL commissioner joiner add "$mac" "$JOINER_PSKD"
  set +x

  log "Joiner add done."
}

main() {
  if [ $# -lt 1 ] || [ $# -gt 2 ]; then
    echo "Usage: $0 <11-digit PIN> [Node ID]"
    exit 1
  fi

  PIN="$1"

  if [ $# -eq 2 ]; then
    NODE_ID="$2"
  else
    NODE_ID=$(get_next_node_id)
    log "Node ID not provided. Using next available Node ID from registry: $NODE_ID"
  fi

  validate_inputs
  need_cmd "$CHIP_TOOL"

  $OT_CTL state >/dev/null 2>&1 || warn "Could not probe OT_CTL with 'state'. If commands fail, check OT_CTL value."

  registry_check_collision
  confirm_pairing_mode

  local dataset_hex
  dataset_hex="$(get_dataset_hex)"
  log "Dataset hex: ${dataset_hex:0:16}… (len=${#dataset_hex})"

  pair_code_thread "$dataset_hex"
  registry_add

  open_commissioning_window

  maybe_joiner_add_from_child_table

  log "Done."
  log "Registry: $REGISTRY_FILE"
}

main "$@"

I have tested out several thread channels and for each try I had to re-pair.
I have not yet managed two ‘clean’ pairings. I think it is wise to keep the node close to the radio.
I also had some clear indications that Bluetooth is used when pairing.
Often when script fails, the node needs to be reset, or the OTBR restarted.

[esdeboer (Eric de Boer)]

If you only rely on the IP6 network make sure that you don’t enable the nat44 that OTBR has on by default, otherwise it can also access your ip4 network and the internet

[OMR (Ole Morten Rønning)]

@esdeboer

My nodes stay and I don’t need to pause the Things, however it does take a while for it to reconnect to the network if connection is lost (might be 15 mins)

Turned out I didn’t lose them either. My battery nodes was just at the edge of radio coverage.
Adding a main powered router (bulb) made it stable.

I have experienced a bit with Disable/Enable the Matter Controller and see the same.
It can take up to 15 minutes for all nodes to reconnect, even the bulb. (but it was the quickest @ 7:30 min).

Now I’m wondering if this is how it is supposed to be or if something could be optimized somewhere?

I have a Matter add-on TRACE log of the reconnect process, but if it is as expected it is perhaps not worth raising a GitHub issue?

[esdeboer (Eric de Boer)]

I can’t find it, but battery powered Thread devices probably have window in the retries to to save the battery. Also I would expect the reconnect process to be at the device side, so I don’t know if you can do much about it at the OpenHAB or OTBR side.

[OMR (Ole Morten Rønning)]

@esdeboer

Also I would expect the reconnect process to be at the device side

Makes sense.
Tried to wake up the battery remote by clicking on it. Triggered nothing.
Pulled the batteries and re-inserted, came online within seconds.

[OMR (Ole Morten Rønning)]

Does Thread devices provide something similar to Zigbee binding?
So that a switch can control a bulb directly in addition to also being paired with an OTBR?
This is quite handy should the PC running OTBR and OH go down.

AI says it is WIP.

The BILRESA switch user guide states it can be paired directly with a bulb by pressing the pairing button 4x, 5cm from the bulb. Wonder if that can be done while still paired with the OTBR and OH.

A binding function similar to the binding box in Deconz without the need for any additional ‘touchlink’ style pairing would be ideal. Using CLI tools is fine too, but how to know what clusters to bind?

[riegelbrau]

In the first post I read:
”…I had to change from the default ch 15 to ch23…”
How can I change the channel? Is it in the Conbee or in OTBR?

[milo (M)]

Has some installed the otbr as docker?

[OMR (Ole Morten Rønning)]

It’s on the OTBR.
But it depends on your WiFi 2.4GHz and Zigbee situation. Your sweet-channel might differ:

You will need to repair all nodes.

Check with:

omr@shs3:~$ sudo openthread-border-router.ot-ctl dataset active
Active Timestamp: 1
Channel: 23
Channel Mask: 0x07fff800
Ext PAN ID: 4711399112120603
Mesh Local Prefix: fd04:f230:1503:538f::/64
Network Key: ***********************************************
Network Name: OpenThreadGTV7
PAN ID: 0x*****
PSKc: ********************************
Security Policy: 672 onrc 0
Done

I’m currently testing out both Conbees straight on the PC without any USB extension.
Has been stable whole day.

[riegelbrau]

Thanks for your reply!

I have a native installed OTBR on a Raspi 4B running opanhabian 64bit with openHAB 5.1.1. The ConbeeII is flashed with the Thread RPC image. It looks, as if IPv6 is configured well, but I don’t get the dataset in a state to set my system as a leader. From the log I see many ChannelAccesFailures:

Do you have any hints? Should I check my WiFi and Zigbee channels an change the channel for OTBR?

Actually ‘sudo ot-ctl dataset active’ shows this:

openhabian@oh-test:~ $ sudo ot-ctl dataset active
Network Key: ******************************
Network Name: OpenThreadGuide
PAN ID: ******
PSKc: ****************************
Done

[OMR (Ole Morten Rønning)]

OTBR refuses to start if the dongle is not found, or ip6 is not enabled.
Looks like your problem right now is the Conbee port.

Have a look in the OP where I describe

ll /dev/serial/by-id/

and make sure

sudo snap get openthread-border-router

shows the right radio-url and infra-if, your LAN port on the pi.

Use

sudo snap set openthread-border-router

to change setting as described here: How to set up OpenThread Border Router on Ubuntu - Matter on Ubuntu documentation