MatterJS Matter Server

[zinc pumice]

Any timeline for the new matterJS based server implementation? Having to pop open every device page for every thread matter device after every restart until it gets picked up is kind of a pain. Will be nice to see if it gets resolved with the move to MatterJS

[terse storm]

https://github.com/matter-js/python-matter-server/issues/1219#issuecomment-3675065559

Main dev @soft canyon said soon to same question on github. not exactly sure when or if full release or private/public beta though.

[soft canyon]

Yeahh soon still stays. I hoped to have a Christmas present for you but there were some road blocks while building the migration from the python configs to the new ones and ensuring full backward compatibility. I solved migration to matter.js just yesterday and had a first working version in my dev environment. Need to finalize some things still and ensure backward compatibility to allow switching back to python any time when needed during initial test phase.

So I might need 2-3 days more to finish that to have a first alpha you can test (first without docker as a installation on a raspi or vm and when that’s good also adding this to docker)
When unpublished the first alpha I will also put the repository snd all code open so that anyone can see and contribute (just decided to not do that now because then people try to install not-working things and it is more effort to clean that up than to wait a bit longer)

I hope that’s understandable

@zinc pumice what exactly you mean with „pop up every device page“? But yeah matter.js does some things differently with thread and also remembers the session timing values which I missed ringing while migrating the python server data. Connecting to thread devices - especially batter powered/sleepy devices) with default session timing values is a bit of a gambling game. So let’s see how it behaves with matter.js. The funnel be likely there also to get the devices connected initially. Follow up might work better. Let’s see what the result will show.

So goal is in any case to have a beta in January - to answer the initial question

[zinc pumice]

Nice thats exciting. The main issue is that restarting the server e.g. post update of haos results in a dice roll for which matter over thread devices reconnect. If you open the device status page for about 3 seconds they become available so it appears to just be an on startup problem with the server. Same as here from plynkus https://github.com/home-assistant/core/issues/152903

[soft canyon]

Interesting. Opening the page should not trigger anything from my knowledge - especially not when you do in HA (or do you mean the python server web ui). Yeah let’s see how it will be with matter.js. There will be a delay too because thread initializations are queued to not overload the thread network but in my test net and other implementations that use matter.js that works good. Will be interesting to see how it is. And if still issues I can at least better see what’s up in the logs 😉 so fingers crossed.

[candid tangle]

Thank you and Merry Christmas 🎄

[zinc pumice]

Yeah its weird right? All matter WiFi devices no problem but somehow thread devices like to hide as unavailable for days after a restart, but open up the device page for a few seconds and boom. Device shows up.

[open forge]

Which model of Thread router are you using?
It doesn't seem reliable.

[open forge]

Is your Threat router connected by cable to the same subnetwork as Home Assistant?

We need context to understand.

[zinc pumice]

Happens with just skyconnect or just nest border router or both.

(Skyconnect direct connected to HAOS running in VM). It is rock solid as long as I don't restart. Its just at start up any thread devices shows as unavailable until I go to the device info page

[open forge]

Nest BR is a WiFi device?

You should prioritize wired Thread border routers to ensure that the problem is not caused by Wi-Fi.
In principle, with the SkyConnect USB dongle, it should work as long as it does not transmit on a channel already occupied by another use such as Zigbee or Wi-Fi.

What type of hardware is your Home Assistant instance installed on?

[zinc pumice]

Why would that cause it to work once I go to the device info page?

[open forge]

I don't know.
We need to keep things as simple as possible to avoid problems.

No vlan, no weird ap like ubiquity (filtering enable by default)

[zinc pumice]

the google BRs are TV streamers on WiFi. I previously had the issue when I was just using skyconnect as well. everything same VLAN.

Its a HAOS VM running in TNScale.

Should be easy enough for me to restart the matter server and see what it spits out on start up

[open forge]

I recommend testing with HAOS freshly installed directly on a machine and connected via network cable.
The Thread stick should be connected via USB with an extension cable to avoid interference.

[open forge]

What’s this TNscale?

Start a new Thread network on a free radio channel and pair only one device. Check that it works stably before proceeding further.

[zinc pumice]

Everything works stably outside of restart. Thats the weird bit. TNScale = truenas scale

[open forge]

I provide advice to help it work. You are free to follow it or not. This installation on a NAS is not supported.

[zinc pumice]

Really? I though HAOS as a VM was supported generally. (Of course i'm then doubly screwed because I also have Unifi sigh). Maybe I'll get an HA Green* and see how that behaves w/ thread devices. I just wish I understood what opening the device info page was doing behind the scenes, then I could make some kind of automation that just looped through all my thread devices that were disabled and pop them online 🙂

[soft canyon]

I can check what the python code does there.

@zinc pumice Device Info Page in HA? Can Youngstown a screenshot that I know that I think the same.

We could start debugging connection issue now with python server. But I think maybe better to wait for next matter.js version 😉

[zinc pumice]

Yah that's why I wasn't too worried about fixing until matter js shows up. I've got a green on the way and the new zbt-2 just to remove any VM weirdness from the mix (and because I can hide the little guy where my kids won't power it off for fun).

[zinc pumice]

Hope you're having a good time eating treats
Happy holidays

[open forge]

Let us know how the tests go once you've received the whole package.

[zinc pumice]

Looks like the green and zbt-2 will get here tuesday so I'll report back then but in the meanwhile I've been doing some debugging (dropping all other OTBRs/Turning on Off IPV6 on my network/Adding extra MDNS firewall rules etc).

So far > Dropping the google TV Streamers off as OTBR immediately fixed flakiness on some battery devices. The fact they are still stuck on thread 1.3 is pretty awful there. Other changes had no impact. I'm going to play around with re-adding a smart things station since that's at least thread 1.4+ (Might even have matter 1.5 now I think thats rolling out currently)

One thing I did note is somehow my baudrate is incorrectly set to 460800 instead of 115200 (ZBT-1). Not sure if that could cause it? I'll test tonight. Edit : although now I'm seeing conflicting information on the correct baudrate for zbt1... Edit2: Ok OTBR fails to start with 115200 so thats definitely not right. That is kind of confusing giving the product page for ZBT-2 lists the 4x baud rate as a selling point but I suppose thats for Zigbee or dual purpose firmware as opposed to thread only.

Edit3: After resetting the baudrate to 460800 and restarting OTBR/Matter addons everything popped back up after a min or two without me needing to do anything. TV streamers thread OBR definitely was a problem. Not sure what the previous issue I had with ZBT-1 alone was but I'm monitoring for now (that was when thread first came out so maybe it was early days bugs from all the nanoleaf junk I had). It will be interesting to compare to home assistant green/zbt-2. Worst case I made a HA donation and have back up hardware squirreled away 🙂

[open forge]

I'm glad to hear that there have been improvements.

We have also identified a bug and there will be a fix that corrects an error message in the OTBR logs. However, this only occurs with multiple BR threads.

[soft canyon]

Interesting. Yeah multible BRs can make fun issues. But re enable IPv6 in any case

[open forge]

Number of modern 15.4 SoCs are capable of supporting 460800 baud rate. This is the expected value to reduce latency between the OTBR host and the the Network/Radio Co-Processor (NCP/RCP).
https://openthread.io/platforms/co-processor

[zinc pumice]

It's kind of funny how in any other deployment you'd think redundancy is good but multiple BRs is just a congested mess. I'll re-evaluate that stress case on matterjs later but definitely sticking to min thread 1.4

[gleaming dirge]

Glad to read here that there is a matter.js Beta planned already for January! Thanks, @soft canyon for your hard work on it. Speaking of timelines - is there also one for Thread 1.4+ in the HA OTBR Addon?

[soft canyon]

No yet. We evaluate what it means because thread 1.4 has some advanced features (like credential sharing) that require more work than „just“ updating the otbr version. It also contains changes on how IPv6 communication is managed and which ips are used so requires deep understanding of the consequences. If anyone can share knowledge here feel free to contact us or join the matter community syncs we have monthly

[soft canyon]

Yeahh there also seem to be some pitfalls with multiple BRs and practical issues. And yes could also be that some of the changes in thread 1.4 simplify that.

[gleaming dirge]

I see. Thanks for the update and the insight! Looking at Ikea flooding the market with dirt cheap Thread devices some of those advanced features would just come handy I guess.

[zinc pumice]

Yah everything has a true ipv6. Everything can route any which way. I imagine you already basically have a routing table cached somewhere it just gets more complicated understanding when you want to hop thread to BR - usual network - BR - back into thread

[bronze steeple]

Just curious - what is the bug you are referring to when using multiole OTBRs? I use several OTBRs as I thought that having them do backhaul by TREL would reduce network traffic (I also found that on a large thread network, when I tried to use only one OTBR, the network wouldn't converge). But a problem I have had for a long time is if I control any devices at once (e.g., turning on or off all my lights - about 75), the network frequently crashes. Hopefully, the bug you found might help address this!

[open forge]

I wasn't the one who identified the implementation error.
https://github.com/home-assistant-libs/python-otbr-api/pull/208

The wakeup channel is not supported either, which doesn't help.

[bronze steeple]

Oh, I had seen that one. Looking at the timestamps on my logs, the last group of number (which I think are the ticks) never seem to go over 1000 so still under the 2048 provided by 11 bits, so I'm guessing this isn't the cause of any issue I've had. Still, might help others and nice that this was caught. I'm guessing that on RPi (which I use for OTBRs), ticks are equivalent to milliseconds which is why i don't see numbers more than 1000.

[bronze steeple]

Out of curiosity: when you say the wakeup channel is not supported, are you talking about thread wake-up frame support? Is that an OTBR issue or a Python Matter Server issue? Is that something to be fixed by the new matterjs server?

[bronze steeple]

Regarding the thread 1.4 OTBR, if you weren't already aware - I think the only "commercial" Thread 1.4 OTBR is the SmartThings hub. Even thought Apple TVs report that they are Thread 1.3, you can use the SmartThings app. to join it to an Apple thread network. However, it won't join to a Home Assistant OTBR network. I no longer use mine, so if somone at HA needs one for testing (when HA actually starts on a OTBR 1.4 update) , I could probably mail it to someone.

[open forge]

I don't see how the Thread coordinator can tell sleepy devices to wake up Thread nodes.
I think some features are missing for it to properly support sleeping devices.

These SED devices work well with other ecosystems. That's why there is a difference.

[open forge]

The add-on code dates back to January 2024. There have probably been patches since then as well.

[zinc pumice]

What do you mean won't join to HA otbr network? I guess I technically joined my ha to Google and then joined smart things to Google as well.

[tall merlin]

The IKEA Dirigera Hub is also running Thread 1.4 OTBR. And they both support Thread 1.4 credential sharing.

Re: 1.4 Credential sharing. They only recently added two helper Functions to the API so generating/validating the 9 digit sharing code is now supported directly:
https://github.com/openthread/openthread/pull/12188

[tall merlin]

Actually the main branches of openthread/ot-br have been pretty stable for the last year or so. I do run a 1.4 OTBR on an RPi (compiling it about once a month or so) in conjunction with 5 Nest Hubs to cover an area of about 300m² with roughly 130 MoT devices. To my experience there are no real backwards compatibility issues -- depending on the set-up. I ran into a couple of issues because I decided early on to switch to the new native OT mDNS module (in order to get rid of avahi and more importantly Apple's mDNSResponder). They both have their issues and I didn't want to have them in my border router instance. These issues were related to the work-arounds they had to implement in order to compensate for some mDNSResponder quirks in a backwards compatible manner. But then: You don't have to do that...
What I learned on that journey is that it's probably way easier to run a self-built 1.4 BR than it ever was to run a 1.3 BR. It is just way more stable and it plays nicely with existing 1.3 BRs in the field. My guess is that it's a big win to replace the existing HA OTBR with a current build (as a drop in replacement) even if you don't have the credential sharing UI in place right from the start.

[soft canyon]

Thanks for the details and insights. Als my feeling was that it should already be better without thee ui-relevant things. I als wanted to upgrade my own otbr next.
I think stefan was curious about that change which IPv6 address it uses by default. There was a change. Need to what what he wrote

[tall merlin]

Hmm, you possibly refer to (DHCPv6) prefix delegation when it comes to provider commissioned v6 address ranges? Admittedly, I don't use that feature right now and rely on NAT here. I don't personally have a use case for my IoT devices being v6 reachable from the internet.
On the other hand though (and possibly switching topics here), HA (OS) still doesn't seem to reliably support BR RA updates. Meaning MoT devices cannot be pinged from HA every once in a while, while this is possible from my local linux box (with network manager 1.5.2). But I also don't see a difference here taking the 1.4 OTBR out of the mix. ip route simply behaves quite different wrt the thread network prefixes inside HA.

[soft canyon]

Yeahh likel that but I am not fit enough in networking topic to judge things here (or even understand anything) ;-)) if you have time on second Monday in January 7pm CET could be worth discussing in person in the matter community call.

[tall merlin]

Plus, that probably also isn't going to change with a matter js based matter server, so I am actually getting off topic with this...

[soft canyon]

Also if other network enhancements could be shone in HA OS

[soft canyon]

Me too ;-). Was a momentum on the topic somehow 😉

Or maybe let’s open a thread in the matter channel on this.

[bronze steeple]

What I meant is that if you have an exisitng HA OTBR network formed using the HA OpenThread add-on, let's call it "ha-thread-923d" and then want to add a SmartThings hub (which is updated to Thread 1.4) to act as another OTBR / TREL-capable-router on the ha-thread-923d network, from the SmartThings app you can select an option to join the SmartThings hub to an existing Thread network. For the HA OpenThread network you'll get an error that the SmartThings hub is unable to join the HA network. On the other hand, if you had a network formed using Apple TVs as OTBRs, you can join the SmartThings hub to that thread network to act as another OTBR / TREL-capable-router. I believe its a credential sharing error that prevents the SmartThings hub from joining the HA-formed thread network. Apparently, credential sharing is something that got standardized and mandated in 1.4 but apparently Apple has it in their 1.3 OTBRs while the HA OTBR does not. So, its a capability to look forward to in HA at some point.

[tall merlin]

Not sure if that is what you are observing, but: By now most "vendors" (HA OTBR, SmartThings, Aqara, Tado and possibly others) can join their TBRs to an Apple or Google Thread network, just because Apple/Google offer propriatary APIs to share Thread network credentials. That is not the same as the Thread 1.4 credential sharing procedure. It's just that these two eco systems were large enough so everyone else just implemented their specific APIs. So I guess that SmartThings just implemented to join Google/Apple if present and then default to the now "official" standard which is not implemented by HA OTBR 1.3

[zinc pumice]

So on this note. I just reactivated my smartthings hub and added it back to my thread network (so just skyconnect BR + the smartthings hub). Almost immediately everything started dropping.

Bunch of "2025-12-29 14:30:27.267 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000071, 1>. Current state was 1" and
2025-12-29 14:29:40.606 (MainThread) WARNING [matter_server.server.device_controller] Node:117 Setup for node failed: Unable to establish CASE session with Node 117

Restarted matter server and same deal. Everything just super unstable.

Edit: Disconnected the smartthings hub and restarting matter server now. Fingers crossed for my marriage that it all just comes back.

Edit2: Yep all slowly reconnecting now. So either TV stream or smart things multiBR just seems to bomb out. I kinda want to try what happens if I do just the smart things hub. Maybe tomorrow I'll test that

[soft canyon]

see the Matter channel ... if you like join the Matter community sync on next monday to get more news on the status and upcoming tests for the new Matter server

[dark nacelle]

What exactly do you mean by Matter community sync? How can I participate?

[terse storm]

#1346944149303066711 message

[soft canyon]

Cross-Linking the recording and transcript here too: https://docs.google.com/document/d/1pdNgnH29vxdEQmP91fOKR9j97fvX3nYnYd6tdyGWoBo/edit?tab=t.nf8wv7v14rw4

Additionally The new Matter Server is now available for Alpha testing (NOT yet as an Addon Beta, this will come sooinn too). All details available at https://github.com/matter-js/matterjs-server/blob/main/ALPHABETATESTS.md and I also released the 0.2.1 including a "JavaScript only docker container" for it. today.

We will get a own channel for discussions around, but lets use this plce for the time being for anyquestions.

[soft canyon]

I also invite anyone that tried the new alpha server to share what he did (als hearing success stories is cool 😉 ) thanks

[rose wolf]

Do you want us to file issues in the repo? 1 of my four devices didn't come back the first two starts of the new container, but then did a while later 🤷

I have logs

It was otherwise a smooth transition from the Python server to the JS one, each in its own container

[harsh swift]

Can someone please post a link to the monthly call schedule? Can't seem to find this after searching around.

Marcel van der Veldt announced that the Matter Monday community sync calls are public and that the Open Home Foundation Devs calendar contains access to these calls and future calls for other projects (01:09:52). Julian Zadow posted a link, and Joost Lekkerkerker was able to confirm the calendar link's functionality.

[keen mist]

Calendar is on https://developers.home-assistant.io/ on the far right, it has a + button to add it to your own calendar.

[harsh swift]

Awesome - thank you!

[rose wolf]

How should I enable debug logging for the matterjs container? I see that there's --log-level debug when running standalone, but I don't know the best way to pass that into the container

[rose wolf]

I added this to my docker-compose.yaml service and it seems to work (based on the existing Dockerfile command):

    command: ["--storage-path", "/data", "--log-level", "debug"]

[soft canyon]

In fact on first start we discover any device via MDNS ... so depending on the device that migtht be it ... (but the pythin server did the same any start - matter,js remembers the last address and tries that first on restart). Sure Logs are always good. share or open an issue. I have a look

[soft canyon]

I am about publishing 0.2.3 version and there I added a environment variable for the docker container to set the loglevel. see docker docs in repo ... as soon as release is there should be easier.

[soft canyon]

So guys, 0.2.3 of the Matter Server is released, all currently known issues should be fixed.
Changelog see: https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#023-2026-01-15

[soft canyon]

Alright, new place is there ... we move to https://discord.com/channels/330944238910963714/1461119138713047274

[dark nacelle]

How/where do I find this channel/thread without your link?

[rose wolf]

From the suggested channels list at the top, or by customizing your channel list and selecting it

[dark nacelle]

Ok, I found it. But I do not see the suggested channels list at the top. How do I customize my channel list. I know it’s offtopic… But I really want to follow all these new Matter things... I am using the iOS Discord app. Maybe that’s my problem?

[dark nacelle]

Perfect! Didn’t know about this functionality. Thanks 🙏