IKEA launches Matter devices 2026 - will we need a hub?

Lolodomo · January 1, 2026, 12:15pm

My understanding of Matter is that the pairing of a device is done with a Matter controller (openHAB, Google Home, …). During the pairing with the Matter controller, the device will be also connected either to a Wifi router or a Thread Border router, depending on the kind of the device. But this part is done transparently for the user.

The confusion for users can come from the fact that we have devices that are at the same time Matter controller and Thread border router. The openHAB server is a Matter controller but not a Thread Border Router. It is also a Matter bridge but that is another story.

I have not yet tested with Thread devices but for Matter over Wifi devices, I never had to select my Wifi router, this was done automatically and my Wifi router provided an IP in my local network to the device. So I just guess that it is exactly the same for Matter over Thread, a Thread border router is automatically found and it provides an IP for the device.

So any Ikea Thread devices could be paired with openHAB without being paired with the Dirigera hub as a Matter controller, even if the Dirigera hub could be used as a Thread Border Router in that case.

What I don’t know is how it behaves in case you have several Thread border routers. Which one is chosen ? The normal user probably can’t control that while a very advanced user has probably a way to control that through network setup.

@digitaldan could certainly add information and correct me if I am wrong.

digitaldan · January 1, 2026, 5:05pm

Correct, although you might need to pair it fist with the Dirigera using their app (i’m not sure here) as it would share the Thread credentials needed to joing its own TBR, but once that happens, you can pair to openHAB, remove the Dirigera matter pairing, and it should still use the Dirigera for thread. Thread 1.4 along with Matter 1.4 TBR clusters is suppose to solve that problem.

You got it right! But i’ll briefly answer your question here.

Thread Border Routers (TBRs) require an Operational Dataset in order to operate a Thread network. This dataset contains network configuration such as the Network Key, Network Name, PAN ID, Extended PAN ID, Channel, and related parameters. The dataset is TLV encoded and is often serialized as a Base64 string when transported or stored.

When the same Operational Dataset is provisioned to multiple Thread Border Routers, they will join the same Thread mesh network, providing redundancy. One Thread Router is automatically elected as the Leader, which is responsible for maintaining network wide configuration data (such as network parameters and partition management).

Thread nodes automatically attach to a parent router based on link quality metrics (for example RSSI and link margin)

If a Border Router fails or disconnects, the Thread mesh self-heals by rerouting traffic through remaining routers. If the Leader becomes unavailable, a new Leader is automatically elected from the remaining eligible routers without network disruption.

Finally, this is where Matter 1.4/1.5 with Matter TBR clusters are suppose to help, they allow sharing and provisioning of that data set, there is not a good way otherwise to share these config unless you use a proprietary, non standard way

If you have multiple TBR with different data sets (so say an Alexa TBR and a Apple TBR) , then the app who pairs the device (your phone) would need to be aware of all of those and allow the user to pick which thread network to use, and be able to access that network’s operational dataset in order to send the right keys to the device. There is some support for this built into IOS and Android, but its limited right now, and requires special permissions only granted to a handful companies that pay for membership to the Thread working group association.

Lolodomo · January 1, 2026, 5:34pm

I finally ordered few Thread devices and an Aqara M200 that I plan tu use mainly as TBR.

So I will test pairing these Thread devices to openHAB, either directly to OH or first to Aqara and then to OH

I will also buy the Ikea remote later and will confirm that it can work with a TBR that is not Dirigera. The only risk I see is that maybe I will not be able to upgrade firmware of the Ikea device.

Edit: I also don’t know if the Ikea app can be used without a Dirigera hub. I suppose it can’t.

To be continued

JoeBlu · January 1, 2026, 9:39pm

When you install the IKEA Smart Home app, at first it ask you to add a dirigera hub.

As far as I can see, there is no way to skip this step.

Lolodomo · January 2, 2026, 12:40am

Ok. Using this app is not a necessity for me. But then I doubt I can update the device firmware for example.

digitaldan · January 3, 2026, 3:56am

Actually I’m about to open a PR that upgrades us to matter.js v0.16 which is in its final release candiate. This brings Matter 1.5, but also brings over the air updates (OTA) for devices which relies on a public ledger maintained by the CSA that publishes firmware releases for devices. This is what Apple, Google, Alexa and others will use to provide OTA upgrades, and we will use as well. I already have the plumbing in openHAB to support this, so will be available soon. I am very excited about this feature.

OMR · January 4, 2026, 1:33pm

My Zigbee journey started back when Ikea Trådfri was introduced.
I started out using the Ikea Hub and the OH Ikea addon.
After several mishaps requiring re-pairing to the Ikea Hub, I moved over to Phoscon deconz/conbee(I) and the deconz addon and that has served me well since.

I have now started looking into Matter over Thread and I have noticed that Phoscon now offers a conbeeii/iii OTBR firmware. Asking AI it said:

As you see, it refers to the SW layer talking to the conbee stick that on an Ubuntu PC that I’m using will need this SW: How to set up OpenThread Border Router on Ubuntu - Matter on Ubuntu documentation

Is this the correct way to go, or will the OH Matter binding (or other) be able to talk to the conbee Radio Co-Processor (RCP) directly offering the same service as the OBTR Daemon?

pacive · January 6, 2026, 9:14am

I don’t think the OH Matter binding has support for using a thread radio directly (like the z-wave and ZigBee bindings), and not sure if there’s any plan to add that either.

Z-wave/ZigBee is simpler in this regard, since all the communication layers are handled by the same stack. Matter has support for several different protocols at the physical and data-link layers (thread/WiFi) that may require different hardware. But it has a common protocol for the network layer (IPv6), which is handled by the OS. Then there is the matter-js component that the binding uses, that manages device pairings etc. On top of that are the matter clusters (application layer) that is handled by the binding. (Correct me if I’m wrong here @digitaldan but this is how I have understood things)

So there’s a lot of moving pieces here, and while not impossible, having the binding handle two separate things in different network layers, with other components responsible for things between those, would likely be more confusing for users.

gd35 · January 6, 2026, 9:57am

I was a user of conbee II. Since I did not use it anymore, I decided to flash it with the thread RCP firmware (thanks by the way to have pointed out this possibility!). Unfortunately, I was not able to configure OpenThread correctly to make it a functional thread border router.

I bought recently a SMLIGHT SLZB-MR4U configured with Home Assistant (as a thread border router) and I successfully added the IKEA TIMMERFLOTTE to OpenHAB. However, I am not very happy with this solution… I do not need 2 smart home systems running at the same time. My home is managed by OpenHAB for several years now and I am more than happy with it.

EDIT: I made some progress with the snap OTBR package. I successfully create a thread network with the conbee II controler with my desktop linux machine running Ubuntu. I just had a problem with the inclusion of the TIMMERFLOTTE device (I reset it with the factory setting). When inspecting the log file, I had the following errors:

[1767717126.178] [474177:474210] [-] Unable to find PAA, err: src/credentials/attestation_verifier/DeviceAttestationVerifier.h:252: CHIP Error 0x0000004A: CA certificate not found, PAI's AKID: 6B:31:8C:FC:E9:99:20:D7:32:8F:5F:43:6D:5E:A3:32:B8:B7:5D:9A
[1767717126.178] [474177:474210] [CTL] Error on commissioning step 'AttestationVerification': 'src/controller/CHIPDeviceController.cpp:1338: CHIP Error 0x00000020: Failed Device Attestation'
[1767717126.179] [474177:474210] [CTL] Failed verifying attestation information. Now checking DAC chain revoked status.
[1767717126.179] [474177:474210] [CTL] Commissioning stage next step: 'AttestationVerification' -> 'AttestationRevocationCheck'
[1767717126.179] [474177:474210] [CTL] Performing next commissioning step 'AttestationRevocationCheck' with completion status = 'src/controller/CHIPDeviceController.cpp:1338: CHIP Error 0x00000020: Failed Device Attestation'
[1767717126.179] [474177:474210] [TOO] Starting commissioning stage 'AttestationRevocationCheck'
[1767717126.179] [474177:474210] [CTL] Verifying the device's DAC chain revocation status
[1767717126.179] [474177:474210] [-] WARNING: No revocation delegate available. Revocation checks will be skipped!
[1767717126.179] [474177:474210] [CTL] Failed in verifying 'Attestation Information' command received from the device: err 101 (PAA not found in DCL and/or local PAA trust store)
[1767717126.179] [474177:474210] [CTL] Error on commissioning step 'AttestationRevocationCheck': 'src/controller/CHIPDeviceController.cpp:1385: CHIP Error 0x00000020: Failed Device Attestation'

I probably made a mistake in the following command line:

chip-tool pairing code-thread 110 hex:00112233445566778899aabbccddeeff XXX

I am not sure what should be mentioned in the “hex:” parameter… XXX is the id printed on the IKEA device.

OMR · January 6, 2026, 8:39pm

Exiting! …
You are a bit ahead of me. My Conbee III is in the mail.
By the look of it it seems you got the OBTR Daemon to talk to the stick?
The Daemon is still in Beta, and there could be a support forum over there for help perhaps?

I still don’t have a mental image of all players involved, but I need to enable IP6 on my pfSense LAN router and perhaps the WiFi access points for Matter over WiFi.

The OH Matter binding must also be able to talk to the OBTR Daemon I guess, most likely over IP6?

OMR · January 10, 2026, 12:20pm

I cant get the OBTR Daemon to talk to my stick.
Did you tune anything?

Here is my current config:

omr@shs3:~$ sudo snap get openthread-border-router
Key                    Value
autostart              false
infra-if               eno2
radio-url              spinel+hdlc+uart:///dev/ttyUSB3
thread-if              wpan0
webgui-listen-address  ::
webgui-port            9090
omr@shs3:~$

Error:

2026-01-10T13:16:08+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:30.195 [W] Platform------: Wait for response timeout
2026-01-10T13:16:08+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:30.195 [I] Platform------: Software reset RCP successfully
2026-01-10T13:16:08+01:00 otbr-agent[12908]: 49d.17:17:30.195 [W] Platform------: Wait for response timeout
2026-01-10T13:16:08+01:00 otbr-agent[12908]: 49d.17:17:30.195 [I] Platform------: Software reset RCP successfully
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [W] Platform------: Wait for response timeout
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [C] Platform------: Failed to communicate with RCP - no response from RCP during initialization
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [C] Platform------: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [C] Platform------: - Make sure RCP is running the correct firmware
2026-01-10T13:16:10+01:00 otbr-agent[12908]: 49d.17:17:32.196 [W] Platform------: Wait for response timeout
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [C] Platform------: - Double check the config parameters passed as `RadioURL` input
2026-01-10T13:16:10+01:00 openthread-border-router.otbr-agent[12908]: otbr-agent[12908]: 49d.17:17:32.196 [C] Platform------: HandleRcpTimeout() at radio_spinel_impl.hpp:2052: RadioSpinelNoResponse

gd35 · January 10, 2026, 1:22pm

Did you flash your conbee III USB stick with the thread firmware ? The error means that the USB stick does not respond correctly. Did you check that the /dev/ttyUSB3 is really associated with the conbee III ?

I did several experiments with the openthread-border-router either on my desktop machine with snap or on a raspberry rpi5 with openthread-border-router as native. But I never succeeded to pair an IKEA thread device (TIMMERFLOTTE) using chip-tool. I got the following error:

[1768050017.800] [9460:9490] [CTL] Commissionable node discovery over BLE failed: src/platform/Linux/BLEManagerImpl.cpp:883: CHIP Error 0x00000032: Timeout
[1768050017.800] [9460:9490] [-] src/platform/Linux/BLEManagerImpl.cpp:883: CHIP Error 0x00000032: Timeout at src/controller/SetUpCodePairer.cpp:522
[1768050027.600] [9460:9490] [CTL] Discovery timed out
[1768050027.600] [9460:9490] [CTL] Stopping commissionable node discovery over DNS-SD
[1768050027.600] [9460:9490] [TOO] Secure Pairing Failed

I will continue to investigate…

OMR · January 10, 2026, 2:24pm

Yes, used the standalone gcfflasher4.11.0 flashing ot-rcp-cb3_0x01000900.GCF using /dev/USB3

But, just realized it has changed port:

omr@shs3:~$ GCFFlasher -l
Path              | Serial      | Type
------------------+-------------+---------------
/dev/ttyUSB1      | DE03311465  | ConBee_III
/dev/ttyUSB0      | DE03311466  | ConBee_III
omr@shs3:~$

Must take the advice from AI:

Linux: It is recommended to use the /dev/serial/by-id/ path, as it is persistent across reboots (e.g., /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_III_...-if00).

updated my Conbee I to III for my Zigbee network as well …

Yes, this setting did the trick …

omr@shs3:~$ sudo snap get openthread-border-router
Key                    Value
autostart              false
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

gd35 · January 10, 2026, 6:37pm

You should now be able to create a thread network.

OMR · January 10, 2026, 9:05pm

I get another flavor:

chip-tool pairing code-thread 110 hex:1212abba1212abba0987654321060362 24601729633
(PIN from back of BILRESA device 2460-172-9633)

gd35 · January 11, 2026, 8:50am

Are you sure about what you mentioned after hex: ?
I was not on my side until I read somewhere that it should be the data retrieve by this command (assuming you use snap).

See Working with the CHIP Tool — Matter documentation

sudo ot-ctl dataset active -x

DK_Homy · January 11, 2026, 2:03pm

Continuing the discussion from IKEA launches Matter devices 2026 - will we need a hub?:

I’ve implemented IKEA Dirigera Hub and 2 window sensors Myggbett as well as one temp/hum sensor Timmerflotte, which are all Thread devices. In first step I connected the sensors to the Dirigera hub via IKEA Smart Home app. Then I installed in Openhab 5.1.0 the Matter Binding followed by creation of the controller thing. In the controller thing, I added the sensors via “pair a matter device” and by searching for the pairing code for each device which I created before with the IKEA app (a new pairing code needs to be created as the initial one was already used to pair with the IKEA hub). Everything worked well, devices were found in the scan, things were created and added to the inbox and went online. Then I created the corresponding items from the channels offered.

The Timmerflotte temp/hum works well and frequently updates temperature and humidity items. Instead, the 2 window sensors have problems and status updates are with significant delays between 5 and 20 mins. In the IKEA app status changes (removing the magnet) are shown immediately without any delay. Thus, there seems to be something in the connectivity between Dirigera Hub and Matter Binding.

What I see from time-2-time in the log is that a window sensor thing is going from Online to Offline(Communciation Error):Node reconnecting, then from Offline:Node reconnecting to Unknown:waiting for data. Then the contact change made few minutes before changes the item state and the thing goes online. When I change the sensor states (magnet) right after the thing went online in the log, the following item changes also come without any delay. See log excerpt below. But then disconnects after some time and changes come with big dely again.

14:43:37.986INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node Reconnectinginfo_circle 
14:43:41.239INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from OFFLINE (COMMUNICATION_ERROR): Node Reconnecting to UNKNOWN: Waiting for data 
14:44:14.924INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue) 
14:44:34.401INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from UNKNOWN: Waiting for data to ONLINE 
14:45:20.990INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from ON to OFF (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue) 
14:45:27.247INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue) 
14:45:33.495INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from ON to OFF (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue) 
14:45:37.036INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)

Would anybody have the same experience or an idea what the root cause could be?

OMR · January 17, 2026, 12:35am

With the great help from @gd35 and AI I finally succeeded in pairing an Ikea Bilresa Dual Switch on the OTBR and also pair it to the Matter Binding in OH:
Only HW needed was a re-flashed Conbee II/III USB Dongle …
Only SW used was OTBR CLI tools + OH. No phone App.

The next one will go a lot faster …
It was quite a journey …

milo · January 17, 2026, 6:21am

Hello, can you describe how??

gd35 · January 17, 2026, 8:15am

Would it be better to open a new thread dedicated to the setup of an OTBR for OpenHAB ? I am sure several users will be interested by the process. A new thread with an adequate title will help others to get access to this knowledge.