new-matter-server

[fringe fjord]

Interesting.

How long did you wait? In fact such updates (especially removals) can take hours (2+)

[deep drift]

I can confirm that.

[azure finch]

Sorry if this is redundant, I could not find any hint on GitHub
I am running the python matter server for now. A few matter Devices are connected and working fine.

Can I simply start the container with the new matterjs image?
Or is there a Migration path?

[raw veldt]

At least 13 hours. I powered off the apple thread network this morning and left it all off (everything unplugged) for the day. Right up until I reset the devices, the refresh button kept showing battery devices being solely children of the apple border routers that were long gone. They were not updating, even after a matter server reboot, or the entire system (including thread and the radios). The graph showed a single connection to the "External router" (which was gone), and no other neighbors. They were fully in communication so they were obviously talking to something else. After rescanning the powered core devices (and their neighbors) a few times, some of the battery devices showed an additional connection - but the ghost remained.

What I did: I looked at the thread graph and identified a battery device showing a ghost; pulled its battery for 10 seconds; watched them power back up; walked back to the graph and it had already updated. The ghost was gone within seconds.

[deep drift]

Just activate the Beta switch. The new matter server is downloaded automatically as well als the migration automatically started. If all works fine you just continue using the new matter server.

[azure finch]

Thank you @deep drift. I forgot to mention that I am running this on docker. But I simply replaced the image (took a backup prior to the switch) and running new container with image ghcr.io/matter-js/matterjs-server:latest. All Matter devices are visible, that was a smooth migration sailing.

[junior sedge]

if you have a lot of matter devices and slow storage, the initial migration can take a while, but it should be better on future restarts.

[grizzled burrow]

Is there any target date/release for Matter 1.5 with full camera support?

[fringe fjord]

The readme and the docs pages - especiallyy those for the alpha/Beta test shoukd contain all details and differences

[fringe fjord]

great, that was the plan 🙂

[fringe fjord]

On one side we need the matter server supporting Matter 1.5 and TCP ... and then we need Home Assistant to have proper camera support, so the combi is the challenge if you do not mean Matetr-Server alone

[silk plover]

https://x.com/csaiot/status/2033634407337366000?s=20 Congrats to @fringe fjord on the award, much deserved.

Connectivity Standards Alliance (@csaiot)

The Alliance is pleased to announce the recipients of the 2026 Annual Awards, recognizing their exceptional contributions and support. These individuals help advance the mission and work of the Alliance both within the organization and across the industry.

Congratulations to all

X · Mar 16, 2026, 8:00 PM

[pallid lodge]

My home assistant instance Is currently up, so right in time, im trying to create a matter server on my android tablet, so when i finished i can add the matter integration or the matter server integration.

[manic lichen]

This channel is for testing and development of the next Matter server. Not for general Matter support.

[pallid lodge]

Oh ok thanks

[chrome haven]

Hello. I can't get Matter Server to start. I've tried both stable and beta versions. I already created a thread here - https://discord.com/channels/330944238910963714/1480685196620726423 - and I was advised to enable the beta version. If it doesn't work, I should submit the logs here.

Judging by them, my HA can't access the certificates, as the logs constantly show a 500 Timeout error. Can anyone suggest the best way to get it up and running?

I'll attach the startup logs to this message.

[grizzled burrow]

I wake up this morning and the Matter server is unable to basically reach any Thread device (two matter over WiFi are up). In the logs I see @1:3b udp://[fd38:723b:537f:1:2c66:3911:5d65:8fc4]:5540 General connection error (retry in 2m): [network-unreachable] send ENETUNREACH fd38:723b:537f:1:2c66:3911:5d65:8fc4:5540 and @1:ce udp://[2600:xxxx:2ec0:dc48:56ef:44ff:fe9b:ad55]:5540 General connection error (retry in 2m): [network-unreachable] send ENETUNREACH 2600:1700:2ec0:dc48:56ef:44ff:fe9b:ad55:5540. I did a full Proxmox host reboot, full HAOS VM reboot, and rebooted my two AppleTVs. It happened over night I'm not aware of any changes to cause this apparent networking issue?

Thread devices that are multi-admin'd to Apple Home appear to work just fine in Apple Home. Only the Matter server seems to be having the connectivity issue.

[elfin hull]

This seems unlikely to be related to the new matterjs-server given (a) your matter over WiFi devices are still functional and (b) ENETUNREACH is returned by syscalls like connect() and whatever the cause, your HA host doesn't believe it has any route to that address. I would look at your network configuration, particularly ipv6, multicast, could be a problem with the proxmox bridge interface? But unlikely to be the matter server.

[grizzled burrow]

Ya just looked at my IPv4/IPv6 settings. It had an IPv6 address (private), but seems like the IPv4 was missing...was weird. I so I literally just reconfigured IPv4, toggled IPv6, and now doing a HAOS VM reboot to see what happens. But what is weird is that it was working 100% before bed, then died over night and there were no updates or changes.

Ok nope....after a refresh reboot it's still broken with the same error. When I disabled IPv6 it also wiped out my IPv4 address. So that's weird.

[elfin hull]

Ya just looked at my IPv4/IPv6 settings

[fringe fjord]

You need internet access to initialize the certs. I think the python server does not start without it. The beta one should start even without internet but yes log these errors. But it should be available and also is according to the logs. So with beta you should be fine in general for now. But something seems to block web queries to the matter dcl and you should figure out what.

[fringe fjord]

I agree with @elfin hull when you should restart the border routers.

[chrome haven]

Could this be geoblocked by IP address? And can I download the certificates myself and upload them to the system?

[grizzled burrow]

Ya didn’t help. HA didn’t get router advertisements. Had to reboot core switches and Firewalla.

[fringe fjord]

Geoblocked? In fact you can reach npmjs because it installs the server. That works. When dcl access is blocked then also software updates are not working. Soooo you would limit yourself if you not get that working. Unless you want that. We plan to pre-fill that cert cache but that’s not yet done. As said: the beta server will work even without it currently.

[chrome haven]

And yet, can I download these certificates myself from my PC and upload them to HA so that they are pulled from the cache?

[fringe fjord]

WTF but yeah fun 😉 glad you solved it

[fringe fjord]

Not that easy. But see my last post. The beta server does not use them right now (but will change). So in beta ignore the errors

[chrome haven]

Is there anything I can do now? Matter-server itself isn't working at all, I can't add devices, and when I try to add them manually, the setup window says "failed to connect" and exits.

[fringe fjord]

<As said with the beta enabled - and seeing your log above - it should work. in fact I see that server starts up, yes there are isues in updating the certs, but there are 72 certs loaded (so somewhen it worked) ... what exactly is the issue when you want to use the beta? how log looks when you say what you said

[tender warren]

I have a problem with the docker image matter-server. I have a Synology server with a homeassistant and matter-server image installed via docker, and everything was working fine for almost a year, but after a recent reboot, the matter-server stopped working and is not being read on port 5580. I spent the entire day trying to fix the issue, but to no avail. Please help me understand what information I need to provide.

[manic lichen]

Are you using the matter.js beta?

[tender warren]

stable,

  matter-server:
    image: ghcr.io/matter-js/python-matter-server:stable
    container_name: matter-server
    restart: unless-stopped
    network_mode: host
    security_opt:
      - apparmor:unconfined
    volumes:
      - /volume1/docker/matter-server/data:/data/
      - /run/dbus:/run/dbus:ro
    command: --storage-path /data --paa-root-cert-dir /data/credentials

[manic lichen]

You are in the wrong channel. #1284966617670881350 with the "Matter" tag.

[tender warren]

sorry, thanks!

[grizzled burrow]

I think I found a bug in 2026.3.3 and the new Matter firmware version detection logic. I was on the first release of Inovelli 1.1.5 and updated all but 2 switches. Today 2026.3.3 notified me of the two lagging switches. I performed the update on both, but the two switches were still listed as needing an update, even after they rebooted. I had to go into HA "System" and re-check for updates. At that point the two update alerts disappeared. Normally after a firmware update they automatically disappear from the list of devices needing an update.

[fringe fjord]

Hm.. a former matterjs server version had an issue here but I would assume you use a more recent version … so we would need logs for that or a way to Repro because things. Also there is still an issue in HA side that uses the string and not number version do could still be that. I think there is an issue for that somewhere?!

[slim sigil]

I can not get matter to work at all through a sky connect device. Nothing wrong with zigbee. Matter seems over engineered and over complicated

[manic lichen]

If you aren't using the beta Matter version, you are on the wrong channel.

[slim sigil]

I think I might be. I will however install the beta. Might get more luck

[fringe fjord]

Matter seems over engineered and over complicated

let me think ... no. It has its purpose and want to solve a certain amount of topics and in this regard it is good ... happy to discuss (not here but on other channels), but only with details and openness 🙂

[compact root]

It's not really Matter's fault, tbf. Networking in general can be complicated for those new to it, and Matter relies heavily on networking knowledge.

[silk plover]

Since nothing works, you may want to set the zbt-1 with the https://discord.com/channels/330944238910963714/1467964294837833859 and latest firmware, then setup the Matter server beta.

[silk plover]

IPv6 exacerbates the misunderstanding for users, especially enthusiast with vlans, mdns relay and such. Prosumer gear (or just those that use it) seem to have a worse time than flat network basic router folks. longterm right choice by thread/Matter, but forcing folks to address things they otherwise could ignore.

[compact root]

I saw that secondhand when @reef smelt had to rework his entire network for Matter support.

The industry made wifi "magic" and it kinda backfires in this way.

[silk plover]

Ikea KLIPPBOK water leak sensor Test net firmware update 1.0.13 out this morning, no issues updating mine 1.0.11. Not sure if these follow the weird 3 attempts and several restarts process that 0.5.7 Matter server put in optimizations for with other Ikea Battery devices or not. took about 10 minutes to complete though.

[rigid bone]

Got an HA update notification for Eve Energy Plugs (Test-net DCL). HA says currently using "3.5.0" and latest is "3.5.0 (9095)". Did the upgrade on one of them and seemed to work. The BasicInfo cluster shows the software version string as "3.5.0" and the software version as 9095, but a minute or so after the upgrade HA came back with the same update notification for the device that was just upgraded.

I also did a restart of Matterjs (now on 0.5.7) and HA Core to see if the problem cleared but its still there

[reef smelt]

The biggest issue for me was that I had a network bridge enabled on my main Linux box for no good reason (used to run HAOS in a KVM there, now I just run container), and I missed a key bit of config there. Without that, I think it would have "just worked"

The problem, of course, is that most of my house & services, including my reverse proxy and even services for my TV remote control, ran on that server, so when it didn't work, nothing worked

[reef crane]

My Eve Energy all remain on 3.5.0(9082). I also use matter.js 0.5.7. Have not gotten any upgrade notification. Firmware entity says "up-to-date).

[rigid bone]

I'm just trying to figure out why the notification did not go away after the upgrade. BTW I have test-net DCL enabled in my configuration and that is where the update is coming from

[silk plover]

Recent Home Assistant upgrade, made some changes to the version checking to allow Home Assistant to present upgrades when the Major version was the same, and a minor revision was made as these were ignored previously. Those adjustments may have resulted in what you’re seeing.
Does not sound like a matter server issue but a Home Assistant issue.

[rigid bone]

I think I found the change you are referring to (made it into 2026.3.3) which says it changed to checking for version number and not string. https://github.com/home-assistant/core/pull/165509 I was running 2026.3.3 during the Eve plug upgrade so this should have worked (now on HA 2026.3.4). hmmmm

[rigid bone]

A bit odd, but I finally was able to get the Update notification to acknowledge that things were up-to-date by clicking the "Update" button 3 times (after the actual update suceeded). I went ahead and submitted an issue on it anyway in core: https://github.com/home-assistant/core/issues/166392

[elfin hull]

For me the big discovery was that Proxmox VE has multicast snooping enabled by default on the virtual bridge device, which was wreaking havoc when running OTBR as an app in HA as a guest in PVE. Once I disabled that I finally had reliable Thread and could build from there.

[deep drift]

For me the big discovery was that

[fringe fjord]

There is a known issue in HA (i gzuess some workaround might be in next Beta) where updates with the same version string ("3.5.0") but different numeric version number (9095 in your case) is not correctly didplayed by HA ... So maybe that causes it? (PS: what vesualis also said) 🙂

[fringe fjord]

Maybe you could post that in the thread channel that the docs and troubleshooting could be enhanced or such?

Soooo ... I am preparing a new Matterjs server version that I will release tomorrow with some fixes and optimizations - nothing big yet but more logging to maybe also understand some IP-Change topics better.
I am also still checking all the logs and networking experiments I got sent, but would be great to hear your "with which settings you stayed so far" from anyone that tested in the above thread. Thanks!

[buoyant nova]

It's an issue with the bugfix/workaround implemented in core#165509. That one was merged into a patch release and causes some issue after updating. It should eventually clear up but still something we should fix.
So before, the issue was that updates didn't show at all if the strings are identical. Now, they'll still be shown as available for a while after the install 😅

[raven harbor]

Hi I countered an issue with the new credential management feature with both two Xthings lock I have. node_id: 288

[fringe fjord]

Good morning, Th eOHF Matter Server Beta 0.5.8 was just released and is now available. It focusses on optimizations and bugfixes mainly and should behave as the versions before. https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#058-2026-03-26

[fringe fjord]

hm ... interesting... we get a response but return "null" as result of the command. checking

Create issue please

Ok, not issue needed, reason found ... was a wrong assumption. I will just do a 0.5.9

[fringe fjord]

@ward 0.5.9 fixeds the issue. please try again.

And for all: 0.5.9 also released ... https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#059-2026-03-26

[raven harbor]

@fringe fjord thanks, it now reads and writes new users successfully.

[elfin hull]

@fringe fjord just restarted to upgrade from 0.5.7 to 0.5.9 and that has to be the smoothest one yet. 90 seconds from startup to all 41 nodes online with no timeouts, retries or errors to be seen.

[fringe fjord]

cool to hear, how many ndes you have?

[elfin hull]

41, all thread, 17 on mains power and the rest are sleepy

[fringe fjord]

then if you like grab 10k logs from teh server and send me as file as DM here in discord ... I can also have an analyzing look at it

[sinful moth]

Does the new matter lock pin feature works with every matter lock/keypad?

[compact root]

You'll want to ask this in #beta. 🙂

[sinful moth]

I did yesterday. 🤪

And the topic (in this chat) this morning was the new feature so I just asked here.

[compact root]

This is about the server, though, not things currently in beta.

[sinful moth]

Ok. Nvm.

[devout nest]

For those who get the "Something went wrong" generic message, make sure you are doing the following, I fought a lock until I figured it out.

You will need to reset the matter device so it's as a NEW device to be paired (At least I did and it is a brand new lock for me).
Next, scan the QR Pairing Code (I found that the scanner really just looks for movement, and I was able to scan my DESK! with the woodgrain and it found the lock) so I think it's relying on the Matter code Broadcast
Then, if you are using an Android like I am, it will ask you if you want to use "Google Home" or other , select the "Other" and choose Home Assistant.
It will go through the process and after it Prepares the device, it will ask you if you want to connect it to your Home Assistant server answer yes.

• If you get an Error code 1 You will need to ensure that your Primary network your Home Assistant is on has IPV6 enabled. This was where my battle ended. After I enabled it, it paired flawlessly.

I was also able to re-connect my Nuki Lock to this which was my pain the behind for about a year now to get paired!

[grizzled burrow]

78 Matter devices, only 3-4 minutes to bring all of them online!

[flint compass]

102 Matter/Thread devices, upgraded from 0.5.7 to 0.5.9, took 10 minutes for all devices to come back online. It would have been 8 minutes, but just one device lingered for the last 2 minutes. @fringe fjord I have logs to DM you!

[fringe fjord]

with the default networking, feel free to send me another log 🙂

[deep drift]

The issue was just marked as stale for the third time. Any suggestions?

[junior sedge]

complain about the stale bot in the ticket and hope someone applies a label to it that prevents the stale bot from running? that has worked for me once :/

[deep drift]

Last time I tried a little poking. Didn't work. 😉

[fringe fjord]

🚩 I just released 0.5.10 of the server (https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#0510-2026-03-27) ... it optimizes the server shutdown

[compact root]

Someone asked a question in #beta yesterday but didn't post it here like I suggested.

After you're finished with this server migration, will we be implementing Matter 1.5?

[fringe fjord]

there are high chances that we will upgrade the matterjs server to Matter 1.5(.1) even before declaring it as stable version ... lets see how all stuff goes, but we already have Code PRs for Matter 1.5 and TCP which are the "big topics" from 1.5 (not yet merged and iterating, but ... majority done)

[compact root]

Awesome to see!

[hollow cloak]

@hardy juniper I converted your message into a file since it's above 15 lines :+1:

[slim sigil]

@fringe fjord @manic lichen @silk plover
Sorry for my negative comments. I posted the messages on pure rage since I couldn't get it working. I'm used to dealing with Zigbee via a skyconnect dongle which worked straight out of the box.
I'm firstly frustrated since I purchased the skyconnect stick which at the time before thread was fully released was sold as a stick that could do both Zigbee and thread, only to find that this isn't the case anymore.
Since that I've bought a separate Zigbee stick, moved my network onto it and I've flashed the original skyconnect stick to open thread.

If someone could point me in the right direction of which channel I can go to for support that would much appreciated. Since I'm using a openthread stick I'm unsure why a ipv6 network would have anything to do with my issues? Also even though I have a plugin running as a openthread boarder router but when I'm trying to onboard a IKEA door sensor it tells me that it couldnt find it.

[manic lichen]

#1284966617670881350 with the "Matter" tag.

[slim sigil]

Thank you

[chrome oxide]

Did you just restart your Matter js server or HAOS or did you also restart all your Apple Thread Border Routers?

I am still using the Matter Python Server. When my 75 Matter over Thread devices have an established connection to my Thread network (7 Apple Thread Routers) and I restart HAOS or the Matter Python server it’s already under 5 minutes.

But when I shutdown all my TBRs it takes between 15 min to 1 hour for my 75 MoT devices to reestablish the connection.

I am in hope that this scenario gets better with Matter.js.

Is Matter.js still alpha or already beta? I guess, I will try my luck in some weeks.

[silk plover]

Matterjs server hit Beta quite a while back when HA Matter server App 8.2 (now at 8.3) was released with a beta switch available in the config Menu.

[chrome oxide]

Yeah, it’s available via the beta switch. But is the software already beta or still alpha? 😃

[silk plover]

It’s beta, and imo already faster, more stable and robust (for me) than the Python server ever was.

[grizzled burrow]

<5 minutes recovery time is just a HAOS Matter server restart. ATVs are untouched.

[silk plover]

If I remember correctly you only use apple TBR and have no OTBR so restarting all apple home TBR will take as long as apple takes to reestablish the thread network for itself then connect with HA matter server. That was my setup prior to the OTBR beta on a zbt-1 with latest firmware, which was the first time I could use the OTBR without frequently destroying the apple thread network. Most of us had much longer than 5 minute to working times after restarting Matter server alone with the Python server, like 15 - 60 minutes.

Multiple Apple TBR while robust once working are not fast to get back to working, not much matter server can do there.

[grizzled burrow]

Yes, prior to the new Matter server, it could take up to 45 minutes with an HAOS reboot to get all Matter devices back online. <5 minutes now. I have an Aqara G350 and W200 that are now also OTBRs.....can't disable that functionality. So technically 4 OTBRs....2 ATVs plus the Aqaras.

I was afraid the G350 and W200 would destroy my Thread stability, but so far, they are fine.

[silk plover]

I have an aqara M3, when or if I restart my apple TBR’s (10 or so) for updates or otherwise, I still proactively take the aqara offline until the apple TBR have re-established themselves. Not sure if that is still necessary, but it was what worked best for me in the past.

[flint compass]

Wow, under 5 for a Python Matter Server restart? I have 102 Matter over Thread devices and I never had that performance. I remember one time it took only about 15 minutes, and I was suppressing tears of joy. It would routinely take about an hour for me. And if I wanted to update any TBRs, we're talking another hour per each. On top of that I'd have "storm" where a bunch of devices went on and offline about 4 times a day on their own. The Matter.js server has been life-changing. Everything only takes mere minutes now to recoup. I rebooted all of my Apple TBRs the other day one at a time and the activity was barely registered in my devices. A full reboot of the Matter.js server took about 10 minutes to recover -- counting the minute while it was restarting, and it would have been ever faster, but one device lingered offline for about 2 minutes at the end. Since upgrading, I have not looked back.

[chrome oxide]

@grizzled burrow @silk plover Ok, thank you guys. So, you use Matter.js in your production without major issues? If so, I am going to update my Python Matter server to Matter.js next week. At the moment I am on holiday. 😃

[grizzled burrow]

I was literally on the first beta of Matter.js and it was life changing. You could NOT PAY ME enough money to revert back. Life was so painful back then.

[silk plover]

@chrome oxide the first restart after selecting the beta takes longest to migrate everything over, but for most of us not really any longer than a stable python server restart. Restarts after that are where things go quicker. Plus the python Matter server will still be there, just a restart away from back to where you are now.

[flint compass]

Ask my spouse. I'm a much happier person since moving over. I spent hours and hours over months trying to optimize the Python Matter server, my network, my TBRs etc. to improve my Matter over Thread setup and nothing helped. In the end, it was the Python Matter Server all along. I've had essentially zero issues since moving to the beta. I have a sensor that tracks offline devices and I rarely see a blip anymore. Be aware that the initial transition can take a while, so if you try the beta, give it time the first time.

[chrome oxide]

Yes, that’s true. Only if I updated my Apple TBRs to the latest tvOS, it took between 20 and 60 minutes. But when I restart HAOS or Matter server only reconnection is really fast.

[grizzled burrow]

I'd love to know more about your offline sensor. Details?

[craggy veldt]

@fringe fjord . I wanted to say thank you again. I remember being here active for quite a while cause of my issues but not anymore. Everything is still working stable without any issues.

Thank you!

[chrome oxide]

Ok, so I did the update to Matter.js remotely. The start of Matter.js took 8 minutes, all 75 MoT devices reconnected within 5 min. Well done! 😃👍

[silk plover]

If you want to waste more of your holiday time, now you can manually label the nodes to something sensical then stare at the Thread and/or Wi-Fi node dashboard map. 🙂 or enjoy your self and wait until you get back home.

[chrome oxide]

No, definitely not. I am on my smartphone. 😉 But is it possible to view that map via smartphone? I already tried it via companion app and web browser, but do not find it.

[deep drift]

No, it is only available via desktop browser.

[chrome oxide]

Thanks! Then I’ll carry on enjoying my holiday. 😃

[opaque panther]

I dont think that the options page on the matter panel should list the set wifi and thread credentials stuff without mentioning that it's just for manual add. And even thread is that needed as we should get the preferred credentials from HA?

[strong hazel]

Yes, it is possible to view the node and thread map on iPhone. The node shows on IPhone easily. To view the thread map, switch your phone to landscape mode on iPhone.

Editing can be done on IPhone as well.

[strong hazel]

It is possible to view the node and thread map/topology in the landscape mode on iPhone. Editing is also possible.

[deep drift]

You are right! That’s new to me, thanks for the hint!

[silk plover]

Wrong channel, not sure where this feedback should go, but that Matter panel is separate from the new Matterjs Server which is what is discussed here. Maybe here: https://discord.com/channels/330944238910963714/1346944149303066711

[compact root]

(lol that's the founder of Home Assistant 😆)

[silk plover]

Ha, i have well developed foot mouth syndrome, although don’t think matterjs can fix that.

[opaque panther]

sorry, too many matter channels 😄

[verbal iris]

Hi together, I use a SMLIGHT as a OTBR. After each Firmware update I got an additional Ghost Border Router in the Mesh. How can I remove the ghosts, since new devices also try to connect to them and become OFFLINE. I am not sure it this Channel fits or the otbr-beta. Please advice if I am in the wrong channel

[verbal iris]

I use Beta option in Matter Server App and Open Thread Border Router App

[deep drift]

Thanks for the "ghost busting" hint. Works for me too. 👻

[fringe fjord]

Restarting the whole network is a complete different topic and lots of things depend on devices and how they react to such changes. Not sure if this will get really better when it is caused there. But feel free to try the matterjs server and send me a log of your second startup (the first one might take longer and pot show devices that are no longer on mdns and so need a restart or such).

[fringe fjord]

a come on ... a bit risk while being away gg
Joke aside: Please be patient on the first start after enabling Beta because adds time for data migration and need to really discover and fully interview all nodes, so this will take a lot longer than any subsequent starts. so "the first starrt does not count" 🙂 (and I think i stop writing ... because when I read further @silk plover answered exactly the same already gg great ... thanks

[fringe fjord]

when you are back please do a restart and wait till all are back agein and fdrop me the 10k info log as DM ... i like to check such "bigger networks" ... sometimes I spot things to optimize

[hardy juniper]

If you enable test-net-dcl ( i wanted for 1 device) and then disable it after updaing that one device, how do you remove the notifications in home assistant that there are updates to other devices that have new firmware in test-net? Is there some matter-js directory files that need to be deleted?

[worthy swift]

Hello, can you please add Voice PE flasher url to the Voice PE setup page? Spent a lot of time to figure it out on my own
https://esphome.github.io/home-assistant-voice-pe/

[raven harbor]

wrong channel? #documentation

[deep drift]

It seems that a Matter binding cannot be deleted from Node #1 if the bound Node #2 is not existing anymore because it has been removed from Matter.js. I see following error in the log:

2026-04-01 12:48:05.595 ERROR WebSocketC~erHandler [38] Failed to handle websocket request Node 11 does not exist
at Function.nodeNotExists (/opt/matterjs/node_modules/@matter-server/ws-controller/src/types/WebSocketMessageTypes.ts:115:16)
at Nodes.get (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/Nodes.ts:52:31)
at Nodes.clusterClientByIdFor (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/Nodes.ts:145:27)
at Nodes.clusterClientFor (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/Nodes.ts:172:21)
at ControllerCommandHandler.setAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:1252:36)
at WebSocketControllerHandler.#handleSetAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:968:43)
at WebSocketControllerHandler.#handleWebSocketRequest (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:460:41)
at WebSocket.<anonymous> (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:313:31)
at WebSocket.emit (node:events:519:28)
at Receiver.receiverOnMessage (/opt/matterjs/node_modules/ws/lib/websocket.js:1225:20)

Is there a way to force the deletion of the binding to the missing Node?

It is possible to add a second binding to Node #1 and the newly bound Node #2 also works as intended. But the old, orphaned binding can still not be deleted from Node #1.

[silk plover]

No delete orphaned (or overwrite) bindings option at the moment, been asked about a couple times. Doesn't look the Matter Bindings Helper dev has the interest or the time to help integrate, so maybe its something @fringe fjord can look into eventually.

#new-matter-server message
#new-matter-server message

[deep drift]

Thanks for confirming the issue. 🙏🏼

[fringe fjord]

🚩 0.5.12 of the server has just been released (https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#0512-2026-04-01) whcih many optimizations in the background. The new version should optimize memory usage "a lot" (you tell me the reality) and fix some bugs. It also starts to optimize I/O a bit already - more to come.
Please check all functions that all stuff still works!

[deep drift]

Download and install are smooth.
During startup I see 15 warnings for OTA files like this:
2026-04-01 17:36:31.549 WARN MatterServer.Ota Failed to import OTA file 1: Error: EISDIR: illegal operation on a directory, read

Further following warning:
2026-04-01 17:36:56.813 WARN AttributeDataDecoder Error decoding attribute 2/0x91/0x5: decodeTlvInternalValue should never be called

[fringe fjord]

Good question ... likely they will stay unless other updates come because HA caches that when I remember right ... Open issue or question for the integration please because that should be the same with the python server already

[fringe fjord]

Open issue please with a debug log ... need to seewho tries to send which websocket messages here. But basically - which UI you use? The matetr server dashboard or that other thing? So moooore context needed

[fringe fjord]

As said ... open issue and lets iterate there. I need more context for that, ideally with screenshots and such information

[fringe fjord]

issue please for the EISDIR ... need to check .. but likely it is a config thing.

And one issue for the other issue ...

@deep drift for the second one: please click in the device structure of the affected mode and endpoint 2 and energymeasurement clister and add a screenshot

[deep drift]

@silk plover and @raven harbor , please check the issue and add your comments if needed:

https://github.com/matter-js/matterjs-server/issues/474

[rigid bone]

FYI, I get the Failed to import OTA file X: Error: EISDIR: illegal operation on a directory, read errors all the time. Just did a restart to pull in 0.5.12 and this error shows up for around 7 files. I'm also using Test-net DCL.

[deep drift]

@rigid bone , please check the issue and add your comments if needed.

https://github.com/matter-js/matterjs-server/issues/475

[grand kite]

FWIW I just restarted matter for the first time in a lil' bit. I think I was on 0.5.7 before now on 0.5.12. Startup time appears to be meaningfully slower than before. I will send logs.

[outer basalt]

Initial impression: new matter server seems a lot more stable

I have a level lock that likes to disconnect for days at a time for no reason

Seems like that’s not happening anymore

Though I’ve only been running it a day

[grand kite]

over 30m so far and network still hasn't come online fully. much slower than before.

I might restart my thread & matter servers. sometimes that helps

[grand kite]

that def helped. still seemed quite a bit slower than before but network came up without nearly so many errors in the log

[fringe fjord]

🚩 Matter Server 0.5.13 is just released ... https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#0513-2026-04-02 .. mainly fixing all reported things from yesterdays version ... i hope 🙂

[grand kite]

Startup with 0.5.13 was much improved over 0.5.12. Back to how it was with earlier versions. 🙂

[deep drift]

3 of 4 issues are fixed for me. Thanks a lot! 🙏🏼

[deep drift]

I have just seen, that issue #4 - Delete orphaned Matter bindings - is planned for the next release. 👍

[compact root]

@fringe fjord It was noted during yesterday's live stream that the Aqara lock (in particular) doesn't have the new user management feature using the new js server, but it does on the current server. Just wanted to flag it to you in case you weren't aware.

[fringe fjord]

yeahh ... but change is already committed, just came a bit too late ...

[fringe fjord]

Then people should open issues and share logs or should come here and provide details ... there should be no reason for it to work just on one ... and no was not known and also unexpected for me ... and I also do not have such a lock so can not try

[compact root]

I wish I knew who was bitching about it in YouTube chat and if they were here.

If anyone in here has a Matter lock, maybe they can help us nail it down.

But there are a few locks that don't support it at all right now - Nuki and Switchbot being the 2 I know of.

(Some details are in #1488186784532664412 )

[fringe fjord]

I only know about the bug with errors that ward reported and thats now fixed since 0.5.9 (2026-03-26)

[grand kite]

I have an Aqara U200 Matter Lock. I can try to help! I haven't looked at the new user features yet.

[compact root]

That's exactly the lock the guy in chat was complaining about because it's the one we demoed on the live stream.

[fringe fjord]

I would love to see more details because I think there is something strange ... Matter wise ALL locks needs to have USR feature at least and also i think at least one of the others ... so would love to see more details

[grand kite]

I defeinitely have some users set up on this lock and they aren't showing up in the UI here when I look.

@compact root I don't know if it is even possible, but the thing that I would love get get from my lock that I don't currently get is an indication of which user unlocks the lock. I can get unlock events, but I don't know who they are from. Would love to have automations that behave differently for different family members.

[fringe fjord]

@grand kite Can you show me a screenshot of the matter server dashboard when you klick down to the DoorLock cluster of that device? ideally all the attributes

[compact root]

I love that idea. But same as you, I don't know how possible that is right now. XD

[grand kite]

One day maybe! 🙂

[fringe fjord]

Matter should send events with this information

@grand kite and also look at the log if you see any errors when ypu open that "users view" because it shlould request data live from the server ...

[grand kite]

I have 7 users setup in the aqara app.

[fringe fjord]

enable debug log in matterserver dashboard temporary (upper right the settings icon) and then do again. need to see what we send back ... but for now it seems zhat it at least reda one user index and gets back data but all empty data does not look that meaninful to me tbh

In generla it is the usual thing "vendor apps might not speak matter with the devices themselves"

[deep drift]

Nuki doesn't support it at all? All Nuki locks? I was planning to get two of them...

[compact root]

So far I have only seen people report the Smart Lock Ultra not working (which is the one I have).

I just noted in the thread I linked to above that Level also doesn't have the funcationality.

3 WWHA partners not having this is, uh

[deep drift]

Argh, I was also homing in on the Ultra... 🫠

[compact root]

Give us a bit to see if we can get these working the same as other locks.

[silk plover]

I have a couple Aqara Smart Lock U400’s if similar data might be helpful to you Apollon. Haven’t attempted any HA lock setup though. Setup in Aqara app or Apple Home.

[fringe fjord]

Ok, so two issues, right?
1.) Locks that claim to have Matter Users but do not have them and so have proprietary user management (in both Matter sevrers the same), right?!
2.) Soemthing might be wrong in the matter.js server to fix .

Rigth?

[compact root]

I haven't tested with the new server myself, so I can't confirm on point 1. But 2 is accurate, yes.

[fringe fjord]

you cutted the log exactly befire where it shows the response

i need the websocket response

[grand kite]

oops, sorry. My bad!

Lemme try again

[fringe fjord]

Ok so we respond the data ... so it is the question then what the integration does with it in that case ... But in general it seems that matter tells "yeahhh. I have that user id ready to be set up" ... so when you already have users that still feels strange

[buoyant nova]

Hmm, I have the same U200 lock and all Aqara-defined users show up in HA for me using Matter.js server 0.5.13. But in my getUser responses, all fields are populated by the device, not just null.

[fringe fjord]

All null means basically that "the slot is available" aka "not yet assigned to anything"

[grand kite]

What firmware version are you on for the lock? I'm still on 077 and I know an update is available. Could be that?

[buoyant nova]

Oh, yeah. I'm on 085

[grand kite]

Could be that. Unfortunately I can't upgrade right now because my front door (where the lock is) is not currently usable (long story). But that's def something different between you + me.

[deep drift]

Which Matter/Thread version comes with 085?

[buoyant nova]

Shows Matter 1.2.0, Thread version attribute is 0.

[hollow cloak]

@thin swift I converted your message into a file since it's above 15 lines :+1:

[fringe fjord]

I can not see any image. But when whole HA is failing you should address this first, or?! Then this channel might not be the right one ?!

[wide charm]

When I tell Siri to raise the blinds, all covers go up exactly simultaneously, but when I use hass and the matter.js server there is massive popcorn…what does Apple implement which Hass doesn’t (yet?)?

[proven plover]

anyone tried deploying matter in a docker and integrating to home assistant running in docker?

[reef smelt]

I'm doing that

[fringe fjord]

Enable debug log of the matter server in the dashboard upper right. Then do such a control and post the log. I can have a look. Also … what kind of devices we talk about?

[deep drift]

Are the custom "Node Labels" supposed to "survive" the power-cycling of Matter devices? I recently labeled all my devices and after power-cycling an Ikea Alpstuga and an Eve Thermo both of the node labels were gone.

[silk plover]

Yes, but from my understanding the label is stored on the device itself not in Matterjs Server, some devices seem prone to losing that label on restart. Another possibility is that in a multi-admin set-up the other ecosystem could overwrite the manual input.

[silk plover]

My 2 IKEA Bilresa consistently lost the manually added node label on restart of Matter server or if their batteries pulled, after an IKEA Test-Net firmware update for them, neither has lost the node label since.

[glacial knoll]

The beta server is working well for me. However I have a lot of devices that generate energy reports every few seconds. I’m happy to have the energy report data in HA statistics however the volume of reports is essentially “Spamming” the logs with the result that it is hard to see if there is anything actually going on that needs attention.

The Python matter server did not log this type of event (even though they were recorded for stats purposes correctly) or at least did not output them in a default setup.

At present, just about all of the matter.js logs are marked as 'INFO" so raising the default log level suppresses the energy reports but also suppresses just about all of the other logs also.

Is there a way to filter the matter.js logs to exclude specific log types?

Here is an example of a matter.js energy report:

2026-04-06 07:19:42.116 INFO ClientEventEmitter Received event electricalEnergyMeasurement.cumulativeEnergyMeasured on server-2-134b.@1:3a.ep7 energyImported: { energy: 155825490 } energyExported: { energy: 155825490 }

Any thoughts appreciated.

[proven plover]

Did you followed some guide here on how to make the HA and Matter communicate?? From what i Understand I need to run the Matter as a separate container and read somewhere here that he was having a connections problem

[proven plover]

You cannot currently use Google’s official Cloud‑to‑Cloud Smart Home API with Home Assistant manually (without Nabu Casa)

Is this true? This was ChatGPTs response. I am having a problem exposing my entities from local server(with domain) to Google Home. Thats why Im trying this matter

[fringe fjord]

Known issue that some devices fail to persist them correctly. So especially eve and some IKEA are basically „known“ issues on device side

Ikea will fix that in updates

[fringe fjord]

Increase loglevel to warn? ;-))

[fringe fjord]

But this question has no relations to the matter server beta?! Then wrong channel here

[proven plover]

my bad cant find the right channel to confirm

[glacial knoll]

<Increase loglevel to warn? ;-))> If I do, I essentially get no logs at all. I will try it again in the latest version to be sure.

[glacial knoll]

A more worrying issue appears to be that HA Core is not getting a message that it "understands" to mark a device as "Unavailable"

[grand kite]

First time I've ever had matter.js crash and restrart:

  at ClientNodeStore.storeForEndpointNumber (/opt/matterjs/node_modules/@matter/node/src/storage/client/ClientNodeStore.ts:83:19)
  at LocalWriter.persistInTransaction (/opt/matterjs/node_modules/@matter/node/src/storage/client/LocalWriter.ts:35:31)
  at DatasourceCache.flush (/opt/matterjs/node_modules/@matter/node/src/storage/client/DatasourceCache.ts:147:41)
  at ClientCacheBuffer.#doFlush (/opt/matterjs/node_modules/@matter/node/src/storage/client/ClientCacheBuffer.ts:110:29)
  at async <anonymous> (/opt/matterjs/node_modules/@matter/general/src/util/Mutex.ts:85:29)
/opt/matterjs/node_modules/@matter/node/src/storage/client/ClientNodeStore.ts:83
            throw new InternalError(`No endpoint store for endpoint ${endpointNumber}`);
                  ^
InternalError: No endpoint store for endpoint 0
    at ClientNodeStore.storeForEndpointNumber (/opt/matterjs/node_modules/@matter/node/src/storage/client/ClientNodeStore.ts:83:19)
    at LocalWriter.persistInTransaction (/opt/matterjs/node_modules/@matter/node/src/storage/client/LocalWriter.ts:35:31)
    at DatasourceCache.flush (/opt/matterjs/node_modules/@matter/node/src/storage/client/DatasourceCache.ts:147:41)
    at ClientCacheBuffer.#doFlush (/opt/matterjs/node_modules/@matter/node/src/storage/client/ClientCacheBuffer.ts:110:29)
    at async <anonymous> (/opt/matterjs/node_modules/@matter/general/src/util/Mutex.ts:85:29)
Node.js v22.21.1
[16:22:42] WARNING: matter-server service exited with code 1 (by signal 0).```

FWIW I just swapped out an invelli dimmer (the device failed) with a new one. But that was like half an hour ago. Things seemed to be working fine.

[fringe fjord]

Known bug. Will be fixed in next version

[reef smelt]

I followed older instructions for using the original Python matter server in a container, and then changed the image for the new matter server. This is the docker-compose.yaml file that I use:

  matterjs-server:
    image: ghcr.io/matter-js/matterjs-server:latest
    container_name: matterjs-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.
      - ./matterjs-server/data:/data/
      # Required for Bluetooth via D-Bus
      - /run/dbus:/run/dbus:ro
    command: ["--storage-path", "/data", "--log-level", "debug"]

Then I just point HA to the server like this: ws://serveripaddress:5580/ws

[hollow cloak]

@shut loom I converted your message into a file since it's above 15 lines :+1:

[silk plover]

@fringe fjord this could be a Matterjs Server issue and not a core issue. https://github.com/home-assistant/core/issues/167530

@glacial knoll posted the Matterjs server log from this event just up above here. #new-matter-server message

[fringe fjord]

Thats a topic of definition. The python server from m knowledge is trying up to 3 times to reestablish the session before he reports „offline“. So it never becomes offline directly.
Matter.js does it not the same. As long as mdns announces an ip we assume the device still connectable. But yes that might lead to longer „assumed online“ times than just 3 tries. Maybe I need to optimize here again because thread could announce IPs even if device is offline for some time.

But Yeahh better having an issue on matterjs server repo

[glacial knoll]

Reposted to matterjs server repo

[chrome oxide]

Hi, where do I label the nodes? I do not find that option. Thanks

[chrome oxide]

Hi Apollon, more than an hour ago, I restarted my Matter.js server. Round about 5 minutes later, 74 of 75 Matter over Thread devices reconnected, except one device (EVE Motion, Node ID 11, @1:b). The device was unavailable in Home Assistant, while it was working in Apple Home. So I used the HA web interface to ping the device (time stamp: 2026-04-07 12:05:54.090). It had an ip address starting with fd61, while all other device IP addresses start with fd10. After pinging the device HA found the new ip address and the device reconnected immediately.

Here is the log: https://pastebin.com/bvqGb849

Any idea?

[proven plover]

Can I expose my home assistant entities to google home using matter??

[silk plover]

It’s buried: Matter Server WebGUI/Node Detail/End point 0/Basic Information/Nodelabel (toward top of the page above the cluster info).

Have a feature request in to make it visible and easier to use when naming several nodes.

https://github.com/matter-js/matterjs-server/issues/369

[silk plover]

Yes, thru multi admin, if native matter device entities. If not matter devices, it’s way off topic for here, but search for Matterbridge and/or MatterHub.

[chrome oxide]

Thank you 😃👍

[fringe fjord]

@shut loom This question is wrong here in this channel because it also uses the python matter server, that sounds in general better suited in the matter channel

[fringe fjord]

Ok, seems that the IP of the devices changed - this can happen when you have multiple Border routers then they can do routing changes somewhen.
So in this case the matter server had fd61 as "the old known address" and so we tried to connect to it and xyes was not reachable but also MDNS did not (yet reported a new address. MDNS simply did not reported any address. Then basically as you ping'ed (but we also discovered ourselves before since "10:51:59.157", so I would guess really "luck"...
Also because it seems you ping'ed already 10:56 and there we only had the one address. Then you ping'ed again 12:05:54.090 ...
And 12:06:36.004 the new IP appeared in MDNS and was reconnected directly

[chrome oxide]

Yeah, that’s true. I already pinged the device without success. EVE Motion and EVE Door & Window still use Matter spec v1.0 firmware. So maybe that was the issue. However, I updated all my HomePods and AppleTVs to the latest version some days ago and everything was working as expected. At least, I had no disconnected/unavailable MoT device in HA. After the restart that one EVE Motion became unavailable. Maybe it was already unavailable before the Matter server restart, but HA didn’t recognize it. I saw that there is an issue reported on GitHub. Who knows.

[raven harbor]

Oh that explained a lot for my case. Such issues happened a lot, I thought it was my devices not working well across network switches.

[frozen river]

Hello! I thought it’s maybe good to reach out via a different medium: The new matter server, as packaged in the home assistant app, managed to destroy my SSD a few weeks ago. I made a issue outlining the problem and the relatively easy work-around, but I think the issue got missed or the gravity underestimated. Could you maybe have a look at https://github.com/home-assistant/addons/issues/4502, and maybe suggest things I could do to move this further?

[junior sedge]

Regarding that, if you set a different matter storage driver, will it handle migrating your previous storage?

[silk plover]

Might be better to open the issue with the MatterJS server github directly instead with HA addons generically.

[frozen river]

Yes, it did that just fine.

[frozen river]

For me this looked more like a configuration issue than that matterjs had a bug. But I guess I could reach out and ask them to guard this backend for „development only“ or such. 🤔

[junior sedge]

well, the matterjs server default storage driver should be switched if a different one is more suitable for how it's normally used.

out of curiousity i tried the (apparently experimental) sqlite storage driver, and it doesn't enable WAL mode on sqlite, which hurts performance quite a bit (especially for the migration)

huh. looks like the way it does storage access relies on the blocking from the locking behaviour of non-wal sqlite. crashes on startup if wal is enabled :)

[frozen river]

Guess I was lucky then to use wal from the options, which worked immediately

[fringe fjord]

Commented on issue and same here.

New storage system already planned and will come in next 1-2 weeks ... the current version 0.5.13 already has significant improvements for io because we write much less often (every 20 min). Stay tuned.

Already using the above mentioned env vars is highly experimental because not fully finished and if they were ready to use I would have announced that. So please do not use them right now!!!! I will not support any issues with them currently! And a final change that I currently prepare might make things incompatible to the current ones. Bad idea to use that without asking beforehand.

So again: DO NOT use them right now. The time will come. Switch back NOW and wait till I announce it.

[fringe fjord]

Yes when we come to it we will have automatic migration. But guys give me time to throughly test it PLEASE

[fringe fjord]

For now ensure to use the latest matterjs version which has the above mentioned optimizations and will write device data less often. Which should fix the majority of of the current io issues even with the old storage system.
More to come. Follow changelog and discord.

[frozen river]

Thanks for the heads-up! But, to make this clear: The beta notes didn’t say „if you enable this you need to buy a new disk in a few weeks“, and when it happened that my disk was dead I decided to to skip the asking and drove directly into the code. The ask wasn’t just „support me“ but „hey, this setup can destroy your system“

Switching back means going back to megabytes of I/o per second … my disk won’t survive that.

I hear you though. Will watch out for releases, and make sure to apply them knowing I’m way out of safe waters.

[fringe fjord]

Yes we got aware of the issues but in fact your report is the first of bigger consequences and as soon as we got aware we worked on solutions. And again: the latest version is doing it differently already and save the majority of the data only every 20 mins.

You can stay on „wal“ and good to know that works for you stable but I can only repeat myself: my personal testing is not yet finished so I will not propose this until I did what I want to do. Point.

[frozen river]

Fair!

[fringe fjord]

Now knowing that there are users that are even more experimental with a beta than a beta (!!) I can try to allow also such migrations for the coming change still left to do. But promising nothing

[elfin hull]

@fringe fjord I have an odd situation where one of my Bilresa remotes completed a firmware upgrade, and is somehow both marked as offline in the matter server and also maintaining a subscription and receiving events according to the matter server logs. Is this interesting (I can grab logs)? I saw there were some recent commits about status reporting, so I'm not sure if this is likely already resolved.

[fringe fjord]

Yes the online/offline report "out of sync" is already on my investigation list ... I need to test that locally ... we tried logs and they don't help ... so need to do myself, but thatnks

[fringe fjord]

🚩 0.5.14 (soon 15) of the Server was just released with latest fixes and optimizations https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#0514-2026-04-10 ... (0.5.14 just went out to npm, so ok for addon users, 0.5.15 will also be again on python and docker 🙂 )
Scope are mainly fixes for things reported, see changelog.
The Offline state should be now better reported and more consistent. Please report.

The new version also should allow a better cleanup of bindings when nodes are gone and ask how to continue in some inconsistency cases

[grand kite]

You getting close to making matter.js the official matter server for HA and deprecating the python server? Seems like it!

[fringe fjord]

yeahh https://github.com/OpenHomeFoundation/roadmap/issues/89

[grand kite]

nice

[fringe fjord]

And that brings me tooooo ...

🚩 Reminder/Announcement: Coming monday (13th april) 7pm CEST we have the~~ State of the Matter Home~~... Matter Community sync again ... wanne hear the latest and greatest around matter.js, the OHF matter server and the upcoming plans for Matter device types in Home Assistant ?! Join and hear it 🙂

[silk plover]

New 1.1.3 Test-net DLC firmware for Ikea MYGGBETT door/window sensor from 1.0.9. Takes a long time and appears the contact sensor restarts at least a couple of times during the update. Matterjs server hangs through some of those restarts, but did not complete the install on the first or the second attempt. Using the latest Matterjs server above.

MYGGBETT
Firmware 1.0.9 reported matter 1.3.0 spec
Firmware 1.1.3 reports matter 1.4.1 spec

[elfin hull]

New 1.1.3 Test-net DLC firmware for Ikea

[fringe fjord]

Grab info long and create issue. What does „hangs“ mean?

[silk plover]

Will do.

Hangs - Download/install starts, then stalls at some percentage complete (30% for example), then the percentage may disappear and it restarts the process at 1% again. All of this over a 5-10min time frame.

In addition to just quitting the attempted install completely.

[elfin hull]

I think that is normal or at least expected for these IKEA devices, see the changelog note for 0.5.6 https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#056-2026-03-12

[silk plover]

Agreed that was my assumption as well, but then the process quits completely on 3 different sensors. I realize ikea makes these thread updates pretty difficult. Wasn’t sure if it worth an issue, just another of those keep trying till it works scenarios with thread OTA.

[fringe fjord]

Yeahh that’s the device reboots where it sticks till device queries again and such. So usually 4 parts they do. So if it was that then all expected

[silk plover]

https://github.com/matter-js/matterjs-server/issues/527

[rigid bone]

FYI, just updated two IKEA Myggspray devices (testnet-dcl). Easiest firmware upgrade I've experienced. Each took only one try and around 13 minutes to complete (incl seeing the device after it reboots).

[wide charm]

Ok narrowed down the issue: if I use the areas selector for the aqara shutter switches, they go asynchronous / simultaneously, but if I use a cover group they are controlled one after the other. Probably not a matter server issue

[fringe fjord]

If you like grab a log and it should show what’s up and then you can maybe have more infos to create issues in core or such

[deep drift]

Same here! My Myggspray only needed one try to upgrade from 1.1.2 to 1.1.3, while all five of my Myggbetts took several attempts. The main difference is that Myggspray was already running Matter 1.4.1 firmware before the upgrade, whereas all my Myggbetts had Matter 1.3.0. Could Matter 1.4.1 be the reason for this difference?

[heavy dirge]

I don't recommend this update. I tried to install it for my MYGGBETT (1.0.9 to 1.1.3), and my sensor stopped working even after a factory reset.

[silk plover]

We can all hope ikea firmware devs and/or matter 1.4.1 in general make the OTA update process less painful going forward. It will be an exercise in frustration and negative feedback/publicity for a lot of customers with original firmware.

[silk plover]

Sorry to hear that, All 7 of mine ultimately updated and work well now.

[fringe fjord]

It was an issue from the chipset vendor they chose for some devices and I think also ikea was surprised about it

[heavy dirge]

Software or hardware issue?

[fringe fjord]

Good question. In fact it is about hardware components and how to to update multiple of them „together“

[silk plover]

I’ll give ikea this, they jumped in with volume and price point that moved markets. And so far they are actively iterating on firmware improvements instead of waiting years (take notes Eve) instead of ignoring and just moving to the next hardware item to sell. Fully believe IKEA, at least in small part, helped HA move faster with matter and thread/otbr.

sorry off topic for here

[deep drift]

Same here with my five. All good.

[raw veldt]

I grumbled a while ago about some Zigbee devices refusing to re-parent to a better router device. Somebody mentioned that their IKEA Matter-over-thread devices were doing the same and that they seemed to prefer to go offline when losing contact with the parent that they were provisioned with rather than switching to the new router close by.

I came across some settings in the openthread stack related to this. It seems that somebody, in their infinite wisdom, decided to turn OFF by default the mechanism to select a better parent by for MTD (battery operated) devices. It seems that they're relying on manufacturers to notice this wording:

This feature is enabled by default on FTD builds. It is recommended that it also be enabled on MTD builds. This may require the platform integrator (device vendor) to select appropriate configuration values for this feature,
sigh. Without making this change, battery devices just go offline if they're moved away from their original parent. Think remotes, like the Ikea BILRESA etc. Or a door/window sensor if you provision it at your computer then wonder why its not working when moved to the door/window.
The docs: https://openthread.io/reference/config/group/config-parent-search
Presumably this default is lurking in openthread forks embedded in chipset maker SDKs etc.

TL;DR: provision Matter-over-thread battery devices in-situ. Don't count on Thread roaming to work unless you've seen it happen - the device maker might have missed the hint to turn on the roaming feature for battery (MTD) devices.

IKEA devices seem particularly afflicted by this. At least with the initial firmware. If anyone has contacts at Ikea, it might be helpful to ask if they've looked at this in their chipset sdk (assuming it's an openthread variant).

I know it's not exactly new-matter-server material, but I'm sharing it here because people (including me) seem to hit these problems when their ikea devices arrive right when expanding their new-matter-server network.

[left rose]

Sigh, we can only hope that IKEA doesn't have the same Chip/SDK vendor for these devices as Aqara has. We probably all remember how firmware upgrades for the 1st gen. thread contact sensors just bricked most devices.

[lofty moth]

The Issue with the MOT is also having issues with commissioning Eve devices, I have three Eve devices that were working. Then something happened between the last update that now I cannot commission IKEA devices nor Eve. However, I have two Matter over WIFI devices that do connect to HA.

Needless to say, I'm frustrated.

Gonna walk away and come back later to it.

[silk plover]

If you recently lost the ability to commission thread devices it could be a bug in the HAOS 17.2 update with IPv6. Running "ha docker options --enable-ipv6=true" and then "ha host restart" could be a fix.

https://github.com/home-assistant/operating-system/issues/4630

[lofty moth]

Thank you, I did do this previously. Will try again has I went half nuclear on my HA.

[lofty moth]

Still not commissioning, I may have to burn the house down.

[raw veldt]

I am still on HAOS 17.1 and can't commission thread devices any more either. I think something more must be going on.

[compact root]

The only solution.

[raw veldt]

My pending updates / versions. Commissioning just times out and fails.

[fringe fjord]

With newest matterjs server? Via BLE or ip network? We found some mdns discover issues in the latest matterjs server and I work on optimizations. But BLE should work and the other is mainly just a mattering multiple tries likely. I work on an update for that too

[raw veldt]

iOS HA companion app right next to the device in question. At first I suspected ikea grillplats weirdness, but Eve Energy won't pair either.

It used to be a hybrid homepod x 6 + OTBR network but the homepods got evicted about 4 weeks ago. OTBR is the sole gateway - it can't go via the homepods any more.

[fringe fjord]

That’s then the question about how far it comes. If you do not see any log in the matter server then it should be ble not working or thread not connecting or mobile app not seeing the operative announcement.
Or is the matter server doing anything or getting any websocket call?

[fringe fjord]

How you did that?

[raw veldt]

I last tried a few days ago and the server was updated since. 0.5.13? -> 0.5.15. I've been super busy with $spouse's health and upcoming surgery needs and haven't been paying attention for over a week.

Let me try again with everything updated and see for sure what's going on and that I'm not distracting you with an old problem.

[fringe fjord]

Sure. Wait for 0.5.0 likely next days

[raw veldt]

It was The Wrong Way™ I'm sure. HA was using the apple MyHome thread network via an original credential import. What I did:

• Removed homepods from home network so that the sole apple controller was an appletv with thread
• deleted the home entirely from apple
• created a new home
• HA kept using the old thread network credentials, while apple is now on a new one.
• homepods are not visible on the thread network map at all
• shared HA devices selectively via homekit bridge to apple, apple sees zero thread/matter devices
• ran into trouble trying to provision a new device via the companion app as the phone reported that the credential had been blocked in the keychain. (known issue, apple taints the key in keychain on network decomission and HA app hit this)
• Marked the key as no longer blocked in keychain on a laptop
• was able to successfully commission Matther over Thread devices 10+ times since then
• at this point the state was: HA + matterjs as the sole occupant/admin of the orignal apple thread + matter fabrics, using the old thread network key.; new apple network has zero matter / thread devices or awareness.
• at some point, weeks after that, comissioning stopped working. I wasn't paying attention closely enough, I think there were some updates in the HA side of things.

The Right Way™ was probably to reset all devices, delete OTBR and start a new one. That sounded like actual work - which I'm not a fan of.

I saw the OTBR app grew a new feature to report if ipv6 isn't configured correctly. Perhaps something similar could be added to the matterjs UI?

[queen tree]

I've been having problems trying to get the new ikea devices (bulb, outlet, button) shared to HA.
Current setup was HA and python-matter-server in separate docker containers running on my server. This has been working for an older Thread bulb. A google nest hub is the Thread border router.

I'm trying to test the matterjs server to see if it allows sharing of the devices from google home to HomeAssistant. However, I cannot get the docker container to start; I keep seeing an Error: EACCES: permission denied, mkdir '/data/config' error in the logs and it crashes a few seconds after starting.

If I manually create /data/config folder, it then returns the error Error: EACCES: permission denied, open '/data/config/matter.lock' .

Ideas? Or just give up until release someday in the future?

[raw veldt]

Minor nit in the OTA UI. I'm seeing this regularly (trimmed):

OTA update status for node @1:5a changed to Downloading for version 1151
OTA update status for node @1:5a changed to WaitForApply for version 1151
OTA update status for node @1:5a changed to Applying for version 1151
Clearing in-progress update for node @1:5a due to software version change. Last State was Applying
Software version changed to 1151 (expected 1151) for node @1:5a, removing from update queue
The UI stops at "Downloading (99%)" most of the time. Sometimes it switches to Applying, but usually not on the faster devices. The common case is 99% -> screen refresh after the full reinterview.
It's not affecting functionality but I figured I'd mention it as a possibility for tweaking later?

[raw veldt]

I've updated everything, rebooted everything, and had multiple attempts to commission two powered devices: one Eve Energy, one Ikea GRILLPLATS. Both have been factory reset. The eve energy used to be a member of my home's fabric, the ikea is new.

The HA companion app scans the code, connects over bluetooth via the phone and switches to "Setting up" state, then that's it. I can't see anything obvious in the serverjs server log, even on DEBUG. I don't see anything new at all that I recognize beyond the usual background chatter. That said though, the network is busy with lots of energyreport s.

I just don't see anything that I recognize as related to pairing. Maybe I should be looking at the OTBR side of things? Maybe apple Did Something™ to the old thread network credential? I'll poke around at that again.

[hollow cloak]

@raw veldt I converted your message into a file since it's above 15 lines :+1:

[raw veldt]

Short version: I see it connecting to the thread mesh. They even become Routers and show up as External Router on the thread map. But matterjs won't talk to it.

[lofty moth]

Not commissioning and when I take a look at the logs for Matter Server the addresses=[] never resolves and CM: 0 not in commissioning mode even after factory resset (this is both the Ikea Timmerflotte device and Eve Energy outlet).

I take that back, Eve Energy does report CM: 1, will investigate further tomorrow.

[raw veldt]

One change I did make that I forgot. I did accept an update for the python/chip matter app version. It didn't appear relevant as it seemed to be mostly about stopping the passing of matterjs args to the python/chip version.

[fringe fjord]

Check the changelog and docker doc. There was a change some versions ago with docker user the new container runs on. Needs a one time perm fix.

[fringe fjord]

What you mean? Because it never reaches 100% or what? The percentages are from the device. We just show them.

[fringe fjord]

Wait. If it do not see any log in the mater serve log the. It can also be that you phone does not talk to it because the operational mdns discovery and initial Apple fabric commissioning fails. Because that’s first step before it is handed over to the matter server with a new opened commissioning window.

[raw veldt]

In the UI, about once per second, the percentage is updated. On slower devices, it goes from Querying -> Downloading (percentage ticks along) -> Applying -> ... On devices with fast downloads, it rapidly progresses through the downloading percentage sweep and stops at 98 or 99%. The LOG shows it completed and went into applying state, but the UI didn't show that. I assume it just happened too quickly for a periodic UI refresh to catch the Downloading (100%) -> Applying -> restart jump

[fringe fjord]

A factory reset might remove thread data from device or leave them. That’s manufacturer decision. When it removes then discovery is ble only. Else it might be still mdns on ip network.

[fringe fjord]

Or the device just rebooted and the state update got lost to be pushed out. That’s all device side stuff. The whole update process is device side driven. So the server can only do a best effort approach to show what he gets.

Ok for the commissioning a bit structured:
via companion app intus a two step thing. First is Apple only and sets up a first fabric. Then Apple opens a new commissioning window and hands that details over to the matter server. If there is no commissioning start on the server in the logs (debug) then the issue is within Apple and the device and setting up the first fabric. Then it is mdns and UDP comm apple mobile to device. If matter server starts doing something then we can look there

[raw veldt]

That's fair enough. Its just that the matterjs server log showed the usual complete transition from Download complete -> Applying -> reset/full_interview/etc. I was just curious about why the logs got the complete state and applying state but the UI didn't.

And super unimportant.

Unrelated, I have impressively broken things in the apple universe. I've made the companion app angry.

In theory, we can use an actual BLE device and avoid the companion app, no?

[fringe fjord]

Ok then that might be arching to check create a core issue. Yeahh maybe too fast

[fringe fjord]

If the device is near your HA host and you have a ble stick attached to the HA the you can do ble directly.

Soon also via esphome ble proxies but need to finish that

[raw veldt]

I have esp32 bluetooth proxies but I was aware it's not an option yet. I was looking for clues as to what kind to get. Is there a list somewhere? Just pick something from the HA hardware lists?

[fringe fjord]

I guess most Linux compatible usb ble adapters should work

[raw veldt]

Time to go and power cycle the entire apple universe in the home.

Otherwise it's time to burn it to the ground 🙂

Ahh crap, the appletv with thread and ethernet got the 26.5 beta because I forgot to turn that off. That might have been what broke everything

[raw veldt]

Well crap (again). I'm baffled. My last provisioned MoT device was on April 4th, but I know for sure that it was on out-of-date HA packages. I don't recall which versions though. It was using obtr-beta, and either high version 0.4.x or low 0.5.x matter-js server.
I've "fixed" the apple thread stuff. Purging keychain credentials and power cycling the ecosystem solved it. I can provision thread devices using the companion app on ios just fine.
Except.. it joins the thread mesh and that's it. I can ping its ipv6 addresses just like any other thread device. The device will promote from REED->Router just fine.
I tried switching otbr from beta back to mainline - no change.
I've done the ha docker options thing as mentioned in the issue tracker - no change.
I fully updated everything - no change. Of note, I exercised the OTA system on about 20 devices (inovelli and ikea battery devices), all were successful. Connectivity seems fine.
Just not provisioning.

Or more specifically, not Matter provisioning for thread devices. They join the thread mesh fine, but matter.js server won't see them.

[raw veldt]

It's been running with otbr-beta from day 1 with matter.js so it shouldn't be that. The core network and other servers have not been changed in months. I'm trying version rollbacks to see if I can find the old behavior. I tried 0.4.3 - no change. It still joins the OT mesh but the matter side doesn't see it.

[raw veldt]

FWIW, this is the Eve Energy that I was messing around with. It will provision to the openthread mesh but not to matter.js

[deep drift]

I also had issues with Eve Energy plugs lately, while growing my fabric. They are suspected by the community to cause issues in larger fabrics. As soon as my local Ikea had Grillplats plugs on stock, I exchanged all Eve Energys against Grillplats‘ which resulted in an improved mesh and fabric. Maybe it’s worth a try - Ikea has a very consumer friendly return policy.

[raw veldt]

Yep, that was the plan. I have a bunch of them here but I was only able to commission one of them before comissioning broke entirely.

Also, Sigh Eve.. what a spectacular way to squander a massive first-mover advantage.

[deep drift]

Btw I also suspected my Ikea battery devices to show this behavior. I take your observations and conclusions as a confirmation. Thanks for elaborating on that. 🙏🏼

[fringe fjord]

interesting idea ... I sent it to some people ... lets see 🙂 Thanks!

See you all tonight! https://discord.gg/home-assistant?event=1493164763126038640

[grizzled burrow]

Yes Eve firmware is a POS and they seem to have zero interest in fixing it. I'm actively removing all Eve devices from my fabric. Just waiting on Onvis in-wall US outlets to remove my last Eve outlets.

[deep drift]

The irony is that this is in full contradiction to one of Matter‘s main goals - sustainability. We are throwing out stuff that is supposed to work in our homes for at least the next 10 years. My Berker/Hager purely electric wall switches and wall plugs are 30 years old, still looking like new and working flawlessly. It can’t be true that we are already on the best way (again) to massively producing electronic waste.

[fringe fjord]

why you do that? Find options to pass then through as matter bridges and you can still use them as Matter 🙂

[deep drift]

Well, the issue with the Eve devices is that they are not only lacking actual Matter but also actual Thread support. They became a liability for both my Matter fabric and my Thread mesh. At the end "doing their job reliably" is their first priority - before being sustainable.

[silk plover]

Hardware requiring firmware updates to optimize to an evolving spec will always be susceptible to this. Eve sold to mega corp and were no longer the primary focus of the larger company, Divided company interest and/or lack of return on investment for anything but new releases for the finance focused parts of a company. Matter also in the process of commoditizing what made eve or nanoleaf special early, allowing cheaper off the shelf hardware and deeper pockets such as Ikea and other to flood the market.

[silk plover]

At some point, the cost of replacement is less than the cost in time and frustration in keeping them. It happened for me first with Nanoleaf thread devices, followed eventually by most Eve. Where that baseline is crossed is different for most of us, but cheaper options released with more up-to-date software resets that equation.

[fringe fjord]

Other question for the users that still have Eve devices with older firmwares that are not yet having the official matter electrical power/energy clusters and so the Matter server is polling the custom cluster data. The Python server did that every 30s. In Beta server we already increased that to 60s ... Eve is proposing 10minutes ... so is there any feedback from the community about expectations and weather accept more network traffic vs "overloading network" vs "having most up-to-date data"?
Added to the agenda also for the community sync tonight!

[grizzled burrow]

Tell Eve to update their firmware to native Matter energy clusters and not their proprietary junk. Problem solved.

And every 10 minutes is laughable. 60s tops.

[fringe fjord]

I am not sure that it is that easy ... thread has a limited bandwidth ... so you are indeed limited in the number of data you can receive by the number of devices and quality of the device placement and and and ... so even 60s with a high number of devices reporting (or being polled, in the end "the same just different") can easiely kill your thread network!

[grizzled burrow]

This entire situation is caused by Eve....hold firm and tell them to get their firmware act together.

[fringe fjord]

sorry but thats not true, as said for all new metter devices it is the question how manufacturers added the "send updates on changes" ... also this can easiely spam the nwtepwkr ...

[grizzled burrow]

The in-wall US Eve outlets are on ancient firmware that relies on proprietary energy cluster polling. They need to update to the standard Matter energy clusters, no? Just like they did for their "peanut" Eve outlets.

Their US energy peanut outlets use Matter v1.3, but the in-wall is Matter 1.1.

[grizzled burrow]

For the Matter v1.1 plugs the polling interval is controlled by HA, and for Matter v1.3 isn't it up to the device to determine how often it PUSHES updates to the Matter controller?

[raw veldt]

I assumed it would have some similarity to the way zigbee did it, where the device did its monitoring continuously and has both threshold and time parameters to trigger a cumulative report to the controllers/subscribers. Early on it was different for eve - the app was the sole consumer and it would connect on demand.

[fringe fjord]

yes I mean that ... so it all depends on your load on it and devcie decisions and can be even worse results if the decisions are "wrong" or the load is too "flaky" 😉

[raw veldt]

That's the thing. If they want to sell a product at premium prices then they need to support it like a premium product. They've clearly failed at this.

[grizzled burrow]

Right...so seems to me that step #1 is for Eve to update to Matter v1.3 (or later) (eliminates HA polling), and then tweak (if needed) their cumulative and periodic energy reporting intervals.

[raw veldt]

What's more irritating is that Eve are producing matter 1.4.1 firmware for the products that they seem to care about - the thermostats/thermos. The 3.6.x firmware for those has been coming out for almost a year.

[grizzled burrow]

And the Eve US in-wall outlet hasn't had an update since November '23 (878 days)

[raw veldt]

Personally, I just want to be able to commission something and I am confused by what I'm seeing. Something is messed up but I clearly don't understand the moving parts.
Background: Because of family health reasons, HA went for a couple of weeks without updates. My last device was comissioned on April 4th with matter.js/otbr-beta/HA/HAOS that was at least a few weeks old.
But it suddenly stopped working. My best guess is that I allowed the python-matter-server addon/app to be updated. I think this should be irrelevant as its just a sideloader for matter.js.
Apple home is present on the network but not involved. HA exports devices via ethernet homekit bridge. AppleTV/Homepods are not on the thread network.
Commissioning successfully enrolls devices onto the thread mesh. I can see them and icmp ping them, and they potentially promote from REED->Router and work like that.

[fringe fjord]

Wait

Which HAOS? 7.20? Did you updated the Supervisor?

Thre was a bug in HAOS 7.20 about ipv6 and docker ... and that is fuixed in supervisor from today ... so would also need an update and reboot

[raw veldt]

What I've tried:
Roll matter.js back in various steps as far back as early 0.5.x and even 0.4.3 - no change. matter.js won't see the new device on the OT network.
Revert from otbr-beta to baseline - no change.
Applied all outstanding updates - AFTER it had stopped working. Including HAOS to 7.20, but reminder, it had stopped working before these updates.
Powering off the apple universe thread in case that's a factor - no change.

➜  ~ ha docker info
enable_ipv6: true
...
storage: overlayfs
version: 29.3.1

➜  ~ ha info       
arch: aarch64
channel: stable
docker: 29.3.1
...
hassos: "17.2"
homeassistant: 2026.4.2
...
operating_system: Home Assistant OS 17.2
state: running
supervisor: 2026.04.0

(anything missing there? there's no available updates that I can see)

Q: what is the companion app's involvement in comissioning? I see it get devices onto the thread mesh. What happens after that? I assumed it tells the matter server to look for comissioning activity on the network of which mDNS is involved. Or does the companion app wait for mDNS activity first then tell the matter server? What's the high level flow here?

➜  ~ ha refresh-updates 
Command completed successfully.
➜  ~ ha available-updates
available_updates: []

[fringe fjord]

check what I write yesterday above here. The mobile app uses the apple/Google framewotrk to commission the devices on the network. afetr that it opens a new commissioning window and hands over these data to zhe matter server for an IPv6 based commissioning

[raw veldt]

I missed this, I'm sorry. Hmm. Interesting. What does "first fabric" mean here? Does this mean it create a new temporary fabric for the device with the thread credentials? Then shares it to HA/matter.js? Huh, wow. I guess it makes sense though.

I have not seen any sign of activity in the matter.js logs but it would be easy to miss with the amount of traffic. Is there a keyword I can search for?

My phone doesn't have Thread. So presumably it'll be using an apple border router as a proxy? If so then this could certainly explain a change - the designated primary apple tbr is an appletv that accidentally got updated to 26.5 beta on an unknown date. It might explain the sudden change.

[fringe fjord]

Come and join the matter sync!

[grizzled burrow]

@fringe fjord If you need more performance logs, I have about 78 Thread devices and would be glad to submit logs.

[elfin hull]

@raw veldt your phone or other mobile device communicates with the device initially over BLE. During the commissioning process it provides the device with credentials sufficient for it to join the Thread network (for matter-over-thread of course), at which point the device will transition over.

You have not responded to @fringe fjord 's question about HA OS 17.2. This release is known to have made a change that broke matter commissioning (among other things), and if you have not taken specific steps to work around the problem then that is likely to be the source of your problems. Your logs show you are on HA OS 17.2. Have you taken those steps, or downgraded your OS back to 17.1? https://github.com/home-assistant/operating-system/issues/4630

[raw veldt]

I did mention this, but it broke before the HAOS 17.2 update. I have run the commands in that issue, and you can see the result in the ha info output a few messages back.

➜  ~ ha docker info
enable_ipv6: true

So yes, it broke spontaneously before any updates, not even iOS. Allowing the iOS 26.4.1 update didn't change anything. Updating to HAOS 17.2 didn't change anything. Running the commands to force enable docker ipv6 didn't help either.

FWIW, I wouldn't have expected the commands to help as the HA host has full IPv6 connectivity and the 17.2 change appeared to mostly affect IPv4-only hosts that stopped enabling local IPv6 routing. Also FWIW, the OTBR app is happy with the IPv6 routing state and doesn't complain about it.

[silk plover]

@raw veldt have you successfully commissioned any Matter/thread devices since removing the apple homepods and such from the pre-existing (working?) conjoined apple thread/HA OTBR network?

[raw veldt]

Yes, the most recent was an ikea grillplats on April 4th. Long after the apple split.

However, I am a little more suspicious about that now that I have a better idea of what's going on behind the curtain. I had problems with locked keychain credentials and I can imagine that I've missed something else that prevents the API from doing a first fabric provision to what it once thought was a shut down network.

I'm very curious about whether a direct BLE adapter bypasses this.

The other glaring problem is that I changed too many things at once. I could have progressed from one problem to a completely different problem.

[raw veldt]

Also, I tried a HAOS downgrade:

➜  ~ ha info   
arch: aarch64
...
hassos: "17.1"
homeassistant: 2026.4.2
...
operating_system: Home Assistant OS 17.1
supervisor: 2026.04.0

No change in behavior

FWIW, this is the state of the separate networks

and to be clear, the companion app on ios does successfully get the devices onto the correct thread network. I can see them arrive on network *6897 and can icmp6 ping them there.

[raw veldt]

Fingers crossed:

2026-04-13 21:29:31.739 INFO   MatterServer         Command line: --storage-path /data --port 5580 --log-level info --primary-interface end0 --fabricid 2 --vendorid 4939 --ota-provider-dir /config/updates --enable-test-net-dcl --bluetooth-adapter 0
2026-04-13 21:29:31.749 INFO   MatterServer         Bluetooth enabled (hci-id=0)
...
2026-04-13 21:29:32.539 INFO   Controller~ndHandler BLE is enabled

[raw veldt]

Well, this method worked.
2026-04-13 21:53:00.383 INFO BleChannel Peripheral f7:b6:cb:06:23:20: Received Matter handshake response: 656c04f10005.
2026-04-13 21:53:00.926 INFO PaseClient Paired successfully » ble://f7:b6:cb:06:23:20 3↔3
2026-04-13 21:53:00.927 INFO Session •unsecured#84603f7070a46745 Channel detached
2026-04-13 21:53:00.933 INFO Controller~missioner Start commissioning of node @1:6b into fabric 2

[raw veldt]

Well, kinda. It seems to work for one Eve Energy devices, but not for the troublesome ikea grillplats device, nor the onvis devices, and not other eve energy devices

[raw veldt]

I tried a few things, probably ill-advised:

• reverted back to python-matter-server. I expected this to be missing nodes but only one node was missing - the one I added on April 4th. The Eve Energy that I added today was present after the rollback.
• I was unable to commission anything on the old server. iOS companion app behaved identically. Was unable to pair Thread devices via BLE on python server. Selecting Thread in the UI messed things up and the chip server logs talked about Wifi pairing rather than thread.
• I figured I'd tempted fate enough and went back to beta matter.js, expecting trouble. Yep! This nearly gave me a heart attack - 1/3 of the nodes were missing.
• server restart - missing nodes came back.
• The ikea grillplats that was added on April 4th is still present in the new beta server.

Current status: an ikea grillplats was commissioned on april 4th via the companion app. Nothing has been able to be commissioned in the companion app since.
I was able to commission 1 Eve Energy via a BLE dongle.

[raw veldt]

One curiosity: the bluetooth commissioner was able to handshake with the Eve Energy devices, but not with the ikea grillplats devices. For the ikea ones it would log that secure pairing had failed. I'm wondering if the antique BT4.0 dongle I dug up is too old or missing something that the ikea devices need.

[fringe fjord]

so you have the same issues with the python seevr? Then it is likely not the server but somehow your network!

[fringe fjord]

did you tried factory reset? while looking for them or very short before strting the commisiioning?

[deep drift]

I might have missed it - were you able to commission the Ikea Grillplats sometime before? I bought 8 and only 7 worked, 1 also refused to being commissioned. I read about others that had even a higher DOA rate. So, if you were never able to commission it, it might be a device issue.

[fringe fjord]

I did some testing today and also had interesting effects for some ikea devices that took up to 2 minutes to respond to MDNS queries some times ... so maybe also a part here. next matterjs. server at least will increase some timeout values

[sturdy kiln]

Hey. I'm looking for some help trying to commission matter-over-thread devices. I've got BLE commissioning going from the companion app on Android. I see the device join the thread network, but I don't see any commissioning flow on the logs on the matter-server. Any suggestions on where to start digging?

[fringe fjord]

Is the app saying that it now puts the device to home asdistant or is it still not finished on Google side? Because no logs in the matter server normally means that the initial commissioning to Google is not finished

[sturdy kiln]

Not yet saying it's putting it in home assistant. I don't have a google matter controller tho, just the HA add-on. It generates thread credentials, says it's trying to "connect to the thread network" (which I see it do on ot-ctl), but then it never finishes and says "can't connect to network". So this is post-joining-thread - that part clearly works.

Doesn't the phone start the commissioning process on the Matter Server side?

[elfin hull]

Does it say "checking connectivity to thread network ..."? If so, are you by any chance using HA OS 17.2? If so, you are probably running into a regression with IPv6 routing

[sturdy kiln]

Yes, running 17.2. And yes, that's what it says

[elfin hull]

https://github.com/home-assistant/operating-system/issues/4630

[sturdy kiln]

Didn't know there was a regression! Is there a CLI series of commands?

Intersting. I'm able to talk to already commissioned devices.

[elfin hull]

yes exactly

[sturdy kiln]

And I commissioned a new one yesterday (even though I can't reproduce that)

[elfin hull]

everything you're describing (where it times out during commissioning, lack of log lines in the matter server, your OS version) matches this issue

[sturdy kiln]

Ok, well giving those commands a shot..
ha docker options --enable-ipv6=true
ha host reboot

let's see how it goes.. NEVER would have guessed that to be the issue. Fingers crossed

[elfin hull]

i would try one of the workarounds (docker command, or OS rollback, or beta supervisor)

[sturdy kiln]

Rebooting now. I'll report back

[sturdy kiln]

No joy 🙁 And nothing in the Matter server logs w.r.t. the commissioning

And what's worse, is several of my thread devices show "offline" in the matter server all of a sudden, even tho they show up using ot-ctl meshdiag topology

[sturdy kiln]

This doesn't seem right:
~ docker network inspect bridge
[
{
"Name": "bridge",
"Id": "a7cdabfbe780c26b01772a746662ac6aabc1e5275d77a4ca30df58e209e5f09a",
"Created": "2026-04-14T13:29:19.043352791-04:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv4": true,
"EnableIPv6": false,
...

despite running --enable-ipv6

[raw veldt]

While I tried them first with HA, I did test each of the problematic devices with apple home - they all provisioned quickly and without any fuss. I just had to remove and factory reset them afterwards.

[raw veldt]

Yes, I am doing a full factory reset between any attempts. Even for a failed attempt that ended in a timeout. I see the devices join the HA OTBR mesh and wanted to start from a clean slate each time.

Hmm. I also have:

➜  / docker network inspect bridge
...
        "EnableIPv4": true,
        "EnableIPv6": false,
...

in spite of having run the commands from the issue report and

➜  / ha docker info                  
enable_ipv6: true

I did revert from HAOS 17.2 back to 17.1 and am still on 17.1.

Presumably that doesn't mean what I think it means

[raw veldt]

One observation. Last night I saw a complaint in one of the logs about a short discriminator not being supported during pairing. So far, I've been using QR codes (with 12 bit discriminator) via phone provisioning, but the manual pairing code method in the server UI only has a 4 bit discriminator. Could that be a factor? Maybe the manual pairing code (with 4 bit discriminator) might be a problem with the ikea devices in manual non-phone pairing?
Hmm, I wonder if I can use the full QR data in the Bluetooth UI provisining field. ... ie: MT:CUO006F-035R2Y7G410 instead of 0649-273-2258 (long discriminator: 891 vs short discriminator: 3)

[raw veldt]

Please yell if you figure something out. I've been in the same boat for a while and don't know why. For me, the timeline is something like this.
mid-late Feb: Apple Home network was shut down leaving the HA OTBR as the sole operator of its thread/matter network.
Mid march: HA updated. Mikrotik network updated. "multicast enhancement" enabled, around then and disabled a few days later.
Late feb (after Apple Home eviction) - April 4th. 12 MoT devices commissioned, mixture of Inovelli and Ikea, using iphone companion app, QR.
April 4th: Last device commissioned (Ikea GRILLPLATS). (iphone HA companion app, QR)
April 5th - April 8th: suddenly can't commission more devices, unknown when this started exactly. Troublesome devices can be commissioned into another thread/matter mesh/fabric just fine.
April 9th-ish: After multiple devices won't commission, I applied all outstanding updates to HA, iphone (26.4 -> 26.4.1) and mikrotik (7.22 -> 7.22.1) to make sure it wasn't an already-solved problem. Ran the docker options enable ipv6 commands from the Issue.
April 12th-ish: mass updated device firmware (30+ nodes) to stress test the thread network. Thread itself is stable and fast, in spite of commissioning issues.
April 13th: was able to commission an Eve Energy using a BLE dongle connected direct to HA, but once only, and not Ikea. Used short numeric pairing code.
April 13th: reverted HAOS from 17.2 tp 17.1 in case, no help.

One big unknown; The Appletv 4k in my office with matter+thread accidentally self-updated from 26.4 to 26.5 because I forgot to turn beta updates off on it. I don't know when this happened.
Also worth noting: when commissioning via phone, I DO see it join the Thread mesh. I see it register its mDNS endpoints in the thread logs. But absolutely nothing on the Matter server side. The OTBR and Matter.js apps are on the same physical ethernet-connected machine, running HAOS 17.1. Phone companion app is obviously wifi.

[raw veldt]

Other things I've tried:
Reverting to python-matter-server. Phone provisioning not changed, but local BLE provisioning is broken there for Thread on the python server. Temporarily - one device went missing (!! - was not a clean rollback, and roll-forward was chaos).
Revert otbr-beta to otbr temporarily.
Revert matter.js all the way back as far as 0.4.3 temporarily.
Deleted Thread keys from apple keychain and sent them across again via companion app.
Powered off the accidental tvOS 26.5 beta device, and in fact have left the entire apple ecosystem powered off during tests. (Not something I want to repeat often - incurs the wrath of spouse)

The HA companion app does report if it cant find a thread border router to use the supplied credentials on. That's consistent though, the companion app does manage to get the troublesome devices onto Thread. Its just the mDNS step that seems to go awry.

[raw veldt]

Hoho!
Using a newer bluetooth adapter. Two new bluetooth-based commissioned nodes:

The home assistant BT page recommends something like the FeasyComm CSR8510A10-based adapter. This seems happy to talk to Eve devices, but not Ikea ones. It's a BT 4.0 w/ long range, quite old. I tried a newer TP-Link UB500 Plus,a BT 5.3(?) system with full EDR+BLE capabilities.

It seems like I can use Bluetooth now. Still no iphone companion app commissioning though. I can live with that.

[fringe fjord]

When you use the companion app then as described above the Apple or Google frameweorks use the QR code you scan do do an initial commissioning and then they open a NEW commissioning window ... ergo it will never be the same data as you scan! But anything also needs to work with the short discriminator

[raw veldt]

I have a question about phone commissioning, again. What I think I understand so far:

• phone uses HA-provided dataset to make sure it can reach a thread border router for the requested network
• phone listens for the ble beacon for a device with a matching discriminator
• phone connects to the matching device using the pin from the onboarding code (either short code or long MT code from the QR)
• phone sends over credentials to the phone for the thread network to create a temporary first fabric
• device uses credentials to connect to border router and is supposed to communicate with the phone
• once the first fabric is online, the phone puts it in pairing mode to do a share to HA, then deletes the setup fabric?
  What have I missed? When using the companion app I see it get as far as coming online in the OTBR and services being registered.

[fringe fjord]

But al salso written above I also had fun test experiences with GRILLPLATS because they partially needed >2 mins to respind to an MDNS query and so if the server missed the one time shot it could have been that the server was mot waiting long enough. That will be fixed in matetrjs server 0.6.0

And with the above written
🚩 Matter server Beta 0.6.0 was just released which should bring some discovery and commissioning optimizations

[raw veldt]

When using BT, it takes 20-ish seconds to go from starting the Ble scan to having completed the interview. FWIW. I'll try again with the phone and 0.6.0.

[fringe fjord]

that sounds reasonable

[raw veldt]

I'm quite willing to accept that I broke my phone's ability to commission things. Except.. others seem to be reporting near-identical symptoms, even with the suggested workarounds applied from the HAOS 17.2 issue.

[raw veldt]

WIth: matter-server/0.6.0 (matter.js/0.17.0-alpha.0-20260415-d9b8bc8d3), these three devices failed twice with the iphone companion app, but worked first try within 15-20 sec via bluetooth.

They didn't appear to reach handoff from the phone, there's no gaps in the node numbering, nothing at all in the logs

[fringe fjord]

(Sorry) .. great for the matter server ... not so great for your apple phone 😉

[raw veldt]

I could see them being registered via Srp / SrpAdvProxy in the otbr log, and I could see them in the Discovery app (which is one of the go-to mDNS browsers), but that's it. I couldn't see anything at all in DEBUG mode that suggested anything was even trying.

[fringe fjord]

Ok, so when you see them there but then apple does not finish and the matetr server never gets a signal then the phone can not see the operational MDNS announcements of zthe devices ... so check your network where the phone is in that it can see all that

[raw veldt]

I could resolve the mDNS host names from an mDNS-aware but otherwise unrelated linux box on the same network but it wasn't able to ping them from there; the fd1e:: prefix wasn't routable at the time.

PING 1ED02B479F3CD9B3.local (fd1e:413b:f4c9:1:66f8:fccb:234e:7068) 56 data bytes

[fringe fjord]

ok, had that linux both the needed ipv6 kernel tweaks?

[raw veldt]

I think that's the core of the problem. Obviously this is all supposed to be local-only but I have to wonder if ios commissioning touches their servers somehow and they changed something over the last few days.

[raw veldt]

The other linux did not have the required settings to allow it to pick up routes to the OTBR.

[fringe fjord]

their server have nothing to do wit it ... it is all mobile phone and/or hub (in asecond step) and the devices in your network

[raw veldt]

Hence my questions earlier about the phone-based flow.. How far off am I? It sounds like its creating a temporary fabric with the phone as the Matter controller and the OTBR as the border router, then doing the handover?

Oh, I just saw the HA companion app was updated on April 7th. That's bang in the center of the window where phone commissioning stopped working for me...

[grizzled burrow]

Anyone having issues with US version of Onvis S4 smart outlet? I have one that regularly drops off my 78 node network and it's most certainly not due to mesh quality. I have to do a power cycle on the switch to bring it back online. It's literally 1 foot from another S4 that's just fine.

[burnt breach]

I previously had a lot of issues with them falling off my network however after updating them to the 1.4 firmware I haven't had any issues with them

[silk plover]

Same experience. Have 6 of them, thankfully all is well.

[hardy juniper]

Is your. Network completely flat, no vlans? No wired network and WiFi network separation?

Your problems sound a lot like of intro to commission a device while not connected to the same vlan as my TBR .

I’m pretty sure your temporary fabric delete temporary and move is not how it works.

With iOS / Apple tbr, phone pops the window and it gets added to the single fabric that HA uses on the Apple TBR. It is called test something by default and has never changed. The device gets commissioned to that network full stop.

Some credentials are passed tot he matter server so it can complete commissioning. I think the matter server either sees the Mdns broadcast or it doesn’t or it is passed the up but there isn’t some temp fabric

[raw veldt]

There is some nuance in there.

• Yes, there are Vlans, BUT the wifi, phones, HA Matter and HA OTBR instances are definitely in the same network. This part of the network is flat, and is switched rather thatn routed. There is no firewall/router in between.
• The network / wifi configuration was unchanged in the window that it stopped working. The last commissioned device was on April 4th, and it stopped working by April 9th. HAOS 17.2 etc wasn't a factor, no updates updates were applied in the window that it stopped working.
• When the phone companion app tries to commission devices, I see it joining the HA OTBR mesh. I see the device registering its mDNS services. Random devices on the network can resolve the mDNS records assigned to it. The machines that are supposed to be able to icmp6 ping it, can do so.
• As near as I can tell, after joining the Thread mesh and becoming resolvable/reachable, everything stops. The phone doesn't progress to the next step. HA Matter.js doesn't even try anything at all. No CASE, nothing at all in the debug logs.
• HA Matter.js and HA OTBR seem to be working fine as matter.js can commission Matter-over-thread devices jsut fine when using its own bluetooth BLE adapter rather than the phone.
  I'm trying to understand the gap. Presumably either the phone doesn't "see" it on the network and isn't trying to do a handoff to HA, or, the handoff to HA is failing.

The logs on the app side aren't particularly enlightening. Basically [MatterWrapper.swift:72] commission > Matter pairing failed: Error Domain=com.apple.MatterSupport Code=1 "(null)"

If I'm reading that right, the phone went through PASE, got it online to the thread network, received pairing data from the HA matter server, then the ios swift call basically went ¯_(ツ)_/¯ after two minutes

https://github.com/home-assistant/iOS/blob/abdda5ad0c82e77ab5ec272526a10993479777ec/Sources/Shared/Environment/MatterWrapper.swift#L72

[fringe fjord]

yeah this at least shows that this is something with the apple part ... and hontesly I guess makes sense to then stop here in this "new matter server "channel ... please move iver to matter channel or open protocols opr an issue with these logs ... nothing the server can do

[fringe fjord]

🚩 I just relesed matterjs server 0.6.1 with two smaller optimizations for commissioning of devices https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#061-2026-04-16

[fringe fjord]

Ok ... relatively quiet here ... so means 0.6.x is stable for all of you? Then ready for the storage tests? 😉

[elfin hull]

Everything came up smoothly on 0.6.1 and has run without issue here!

[raven harbor]

Is it normal for Matter Over Wi-Fi device getting IPv6 from a TBR’s RA?

[fringe fjord]

Can happen I guess

[junior sedge]

expected/normal, yeah. for matter binding between wifi and thread devices it might even be required.

[raw veldt]

My Linux and FreeBSD systems also grab a SLAAC address from the TBR RAs as well. I don't see why a wifi matter device couldn't/wouldn't grab one too.

[raven harbor]

I see thanks, I will look into why the ping wont pass then

[raw veldt]

IIRC, those come from mDNS advertisements - which are from the device's point of view. eg: if you have a matter light switch on your network and it grabbed an ipv6 address in the ffdf: range then

1. it'll advertise that address in its mDNS packets - but that doesn't mean that every other system on your got one as well.
2. will be reachable by other systems that allocated a ffdf: prefix address themselves.
3. won't be reachable by systems that didn't take advantage of the TBR RA's prefixes.
   These are addresses from the ipv6 (approximate) equivalent of RFC1918. Matter devices need to be on this prefix to talk among themselves. IPv4 connectivity isn't part of Matter.
   IIRC, TBRs use two prefixes - one for the LAN side, and one for the Thread mesh.
   The IPv4 address in the device's advertisement is an extension. The rest of the Matter ecosystem can ignore it. It's probably there for manufacturer cloud and/or manufacturer app (eg: Leviton Gen 2 wifi devices do this).

[raven harbor]

Thanks for the explaination!

I was troubleshooting commission and connectivity issues with SwitchBot/Govee devices; and some odd behaviors make me look at the IPv6 condition. iOS and Google would failed discovering the device when they get connected to Wi-Fi during the initial commission. If I try to use Matter Server to commission directly, it won't discover the device at all.

Using iOS and Android flows, the device managed to get network credential, and connect to Wi-Fi, but controllers wont see them on LAN and timed out pairing them. Maybe it's due to broken IPv6 route or simply poor firmware from Govee and SwitchBot.

[raw veldt]

I've been struggling with phone based device pairing for about a week. Still no clue as to what is going on except that the Matter and Thread parts are working just fine here. eg: I can provision Matter-over-Thread devices with a bluetooth dongle attached to the server, but not with a phone. When using a phone for provisioning, the device connects to Thread quickly and is reachable over ipv6, it does the mDNS things, and then everything times out on the phone. For me, the phone worked on April 4th, the HA companion app was updated on April 7th, and as of April 9th I can't provision with the phone app.

[raven harbor]

My issues were tide to specific brands. Most of other units I have are just fine with HA.

[burnt breach]

I have somehow gained a mythical 4th border router that does not exist on the thread page

[raven harbor]

It should just refer routers, TBR is a kind of router. Do you have HomeKit over thread devices? Or a Matter device that’s not added to HA

[burnt breach]

No to both. What's a little weird is that I checked out the thread graph yesterday and there was only 3 external routers. It just happened today where a 4th showed up. I set up some more IKEA plugs yesterday but all of them were through home assistant

[silk plover]

Read thru the thread linked below to see some reasons for this and what you can try if the extra Ext Routers shown really bother you.

https://discord.com/channels/330944238910963714/1487943389105094797

[burnt breach]

Thanks! Instead of repairing I just re-interviewed and pinged the device connected to the extra boarder router a few times and it's disappeared now from the graph

[fringe fjord]

Sooo guy s... then lets start with the torage system tests ...

test of the new Matterjs server Storage system

[fringe fjord]

Keep in mind that partially also iPhones can join temporarily as routers. … could this be?
Theresia an issue open to identify the routers. Let’s see if the idea works out

[burnt breach]

We don't have any iPhones in the house but I do have a Pixel 10 Pro which I think has a thread radio but not sure if it has the ability to join as a router

[waxen tapir]

I have a similar issue, with only one extra, in my case I think it stems from an otbr update that created a new identity for my USB dongle router, but with the old one still kicking about. It works without any problems but it seems a bit weird. Apparently the ghost border router is the leader

[waxen tapir]

They have now been joined by a 2nd ghost router

[strong hazel]

I have two ghost routers that refused to go away.

[deep drift]

You just need to power-cycle the connected peers, then the ghost routers will disappear.

[strong hazel]

I have 20 routers remaining, including 6 border routers. I fear that if I power-cycle the router where the two ghost routers are connected, then that router might be an end device. That router is in the middle of my house connecting the second floor and basement. Of the 20 routers available, only 16 routers are actually working as routers while 4 routers were downgraded as end devices. This is a problem with the thread network which I find Matter Server beta is making worse unfortunately.

[deep drift]

Matter Server Beta visualization is only showing the information of the devices‘ Thread diagnostic clusters. So, this is a Thread phenomenon.

[strong hazel]

I know it is a thread network problem. Matter Server Beta shows me an item of information I don’t want to see with no way to unsee it easily.

[deep drift]

Well, as an iPhone presents itself as a Thread Border Router it might be difficult to distinguish it from a „real“ TBR. But maybe @fringe fjord has an idea for a filter to toggle.

[fringe fjord]

No way to differentiate such temporary from permanent ones. But it is also just assumption.

[glacial knoll]

AFAIK an iPhone acts as a Thread end device not as a Router.

[deep drift]

Yeah, I just checked. In the actual visualization it displays my iPhone as „External Device“. But I also had ghosts displayed as „External Routers“

[glacial knoll]

If you put the "Discovery DNS-SD" App on your iPhone (it's free) and take a look at the _meshcop._udp protocol cluster you may get more info on the ghost routers

[deep drift]

Only the HA OTBR is listed. So indeed only an „external device“

[glacial knoll]

I don't use the HA OTBR. All my OTBRs are AppleTVs or HomePods. They are appear there in Discovery. BTW the way the Thread protocol is written is that it will typically nominate 16-23 Thread devices as routers (including OTBRs), all other devices will be "demoted" to REEDs (Router-Eligible End Device). This nomination is dynamic and will change as network conditions change. A REED can have multiple paths to the "backbone" but will typically only use one at a time.

[strong hazel]

I do have 2 HomePod mini’s, 3 Aqara Hub M100’s and 1 HAOS OTBR. All 6 border routers are showing in Discovery app because they are discoverable in my wireless local area network due to their nature as Border Routers, which are bridges between thread network and ethernet and WiFi.

I just removed my external Ubuntu server hosted OTBR. This was showing in Discovery app before its removal because it was a Border Router. It does not show anymore since its removal. But it is still showing as two ghost routers in HAOS Matter Server beta thread visualization.

I have 14 routers that are not border routers which do not show in Discovery app because they are only on my thread network.

[pseudo sandal]

Wow what a great conversation for me to find, thanks for the pointer here Apollon!

Yeah I have a very extremely large thread/matter fabric and I’m finding that the iOS mobile commissioner is INSANELY chaotic on my fabric compared to direct matterjs-commissioning. I have an iPhone with a thread chip in it, so for me to discover here that this thing is acting as a router….this explains a lot

In my practical experience, the combo of OTBR (in beta 1.4) + matterjs absolutely does not like it when border routers enter the network and then leave in a temporary way. These are best used when the border routers are permanent and never changing.

At my very large location, when I add a OTBR for a few hours and then remove it from the network, my network is sent into complete chaos trying to reorganize for many days, like nearly 7 days. Let’s not talk about “it’s your network bro” because I can assure you (at least for now) my network is absolutely dialed in.

I can’t explain much more than that at the moment but if the presumption here is that iOS is adding and removing border routers in a temporary way, I believe that, because iOS commissioning is insanely chaotic on my fabric. Like identical to if I added and removed a OTBR border router

[hardy juniper]

Must be a OTBR specific issue because commissioning with Apple border routers using iOS works with matter-js is rock solid and faster than it was with python server

[pseudo sandal]

I would believe that for sure.

When I reboot all my OTBR/ZBT2 (I have 7 of them to cover 35,000 square feet, 410 nodes on one mesh) I can make the network stabilize radically faster than it would otherwise. Stabilizes within 6 hours or less, when I reboot my border routers in stages approx 45 minutes apart.

If I leave OTBR alone to organize by its own means, it can sometimes take weeks to completely stabilize.

[reef smelt]

That...is an enormous network

[deep drift]

Wow, this is huge! Are you using TREL to connect the TBRs to each other?

[fringe fjord]

Bjut maybe better to discuss OTBR things in the OTBR channel? 🙂

[pseudo sandal]

Ok I will move any future discussions to OTBR channels where appropriate 😀 my bad

To close that topic: Yes absolutely no chance this would work without TREL. Thankfully this is enabled by default in OTBR.

I say this very casually but I do believe I am operating the largest network of its kind right now. It absolutely works (the promise is real) but as I write today, this isn’t a scale you’ll just casually achieve using most home network equipment. You need very specific networking gear and it needs to be configured in a very exact ways. I’m happy to share those details if anyone wants to know more about that

Huge props to the OHF and @fringe fjord for building such a great server. There’s still a lot of low hanging fruit like storage improvements, which I’m very excited to test.

But as I write this today, the matterjs-server is already working tremendously better than Python matter server. I hit the absolute limits of Python matter server….that limit happens to be somewhere approximately between 150-200 Thread nodes. You absolutely won’t push that any further without taking huge losses in node downtime.

OHF matterjs-server, on the other hand, is orders of magnitude more efficient. We are still commissioning new nodes every day and the server works as well at this scale as it does with 50 nodes.

Truly tremendous work!

[burnt breach]

https://www.theverge.com/tech/915656/theres-finally-an-easy-way-to-see-your-thread-network

https://play.google.com/store/apps/details?id=com.threadgroup.otloom&pcampaignid=web_share

[left rose]

It just does nothing for me. Not getting past this splash screen:

Can anyone confirm this app works in some scenario?

[elfin hull]

(a) This app just draws more attention to Google's head-up-their-ass policy of refusing to allow Thread network credential management beyond the first-come-first-served preferred Thread network credential policy, but I have a Pixel Tablet with a dedicated user with the right network credentials
(b) It took a distressingly large number of attempts to eventually get it to work enough to show me this
(c) This is not the correct number of online devices in this thread network 😂

[rigid bone]

Kind of wondering how is this App getting this data?

[elfin hull]

Start from the mDNS service _meshcop._udp (Mesh Commissioning Protocol) to identify thread networks. Connect to one or more border routers using operational credentials to start querying the disagnostic TLVs to learn about the neighbor table, build the graph

[rigid bone]

I think this means the OTBR has to support the Mesh Diagnostics via the websocket API? If correct, it goes back to an earlier question I had on the Beta OTBR channel about whether the HA Beta OTBR actually supports this websocket API for Mesh Diags? May I ask which OTBR you are using?

[elfin hull]

I'm using the OTBR app inside HA (with the beta version turned on). The Android app seems to pull the Thread info it needs from Google Play Services. It works on my tablet where I have that dataset synced from the HA Companion app, but it cannot connect from my phone which insists on my old, unused NEST PAN.

[rigid bone]

Hey, I got it to work 🙂 ... still wondering how it gets the data from the Beta OTBR.....

Oh, wow, my OTBR logs have thousands of [W] SecTransport--: entries.... so I guess that's how its done

[strong hazel]

Thanks for sharing.

I just set up on my Android tablet after syncing my credentials with the device. It works well. It was quick to set up.

It does show all my routers, border routers and end devices correctly. More importantly, it does not show me the two ghost routers being shown in HAOS Matter Server beta. This suggests that Matter Server Beta has an issue in showing ghost routers.

[silk plover]

Suggest to me that the matter thread diagnostic cluster is less accurate with the second hand info on TBR that devices report back to matterjs server.

[rigid bone]

The drawback I see with the App is you can't label the nodes (or at least I haven't figured out a way to do it), so still a bit challenging to use practically. Maybe they'll add that capability.

[deep drift]

I would like to state that 0.6.1 (with new storage system enabled) is - for me - the smoothest running Matter server build so far. Very few subscription timeouts, not a single offline device. Kudos, very well done! 👏🏼

[pseudo sandal]

I agree with this.

Seems like the commissioning issues are solved.

And the logic around how and when devices get marked offline is good too. I know people will always have feelings about this logic but in my best objective evaluation, it looks correct to me.

[steady dragon]

were there maybe breaking changes with SetAclEntry when it comes to websocket API moving from python-matter-server to matterjs-server? my ACL is no longer being set correctly when calling websocket commands directly through my application that is connecting through the websocket.

[fringe fjord]

What error you get ... I guess I know it 🙂
The Websocket layer is 1:1 the same, BUT the Matterjs-Server handles ACL writes as defined in the 1.5 spec (already) while the python server is 1.4.2. This means that under the hood the ACL are sent differently to the device then before ...

The effct is that invalid ACLs on write (e.g. sending too many!) are now completely declined while in the past you would have needed to check all the write response details to maybe see if one or multiple of the entries could not be stored - but most people and also the Dashboard were just checking the "very first returned status" and this was always OK.

So basically when writing "invalid ACLs" with the Python server you ended up with a partially written ACL where it was hard tio determine that fact and so most users missed it - with the new server you get a complete error or complete access and have no partial written ACLs.

[steady dragon]

actually no, what's happening is that when I'm binding node 2 (light) to node 1 (binding switch). the binding cluster itself is set up correctly on node 1 but the ACL is missing.

[steady dragon]

I actually get a successful message that the ACL has been set for example here I added the last entry:

2026-04-23 12:30:54.569 INFO   Controller~ndHandler Writing attribute 0 with value { node: 14, endpoint: 1 }
2026-04-23 12:30:54.602 INFO   ClientInteraction    Write » @1:2c•b12f⇵b75a attributes: 0x1/Binding(0x1e)/Binding(0x0) = [{"node":14,"endpoint":1,"group":"undefined","cluster":"undefined"}] (version=undefined)
2026-04-23 12:30:54.689 INFO   ClientInteraction    Write « @1:2c•b12f⇵b75a 2↔2 success: 2 failure: 0

where subject is correctly set to node 44 (what I need), but looking at the value that last acl with subjects [44] is missing entirely. so in logs it shows like it did it but in reality nothing happens to the ACL

also tried factory resetting my nanoleaf light but still same bug

[hollow cloak]

@steady dragon I converted your message into a file since it's above 15 lines :+1:

[steady dragon]

I'm guessing something must be wrong with my payload? but same payload was working just fine with python implementation

[fringe fjord]

post a debug log that I see what goes over the wire

and also the log only shows the wrote to the binding and not the write on acl ... thats more than strange

[raven harbor]

it works just give it some minutes to collect data from your thread network

[flint compass]

I updated to 0.6.1 the other day and starting after that I'm getting a steady stream of devices going offline one at a time for a short while and then coming back. Maybe once every hour or two. Here, for example, are the relevant log lines from a recent offline event:

2026-04-24 10:15:28.757 INFO ClientEventEmitter Received event threadNetworkDiagnostics.connectionStatus on server-2-134b.@1:33 connectionStatus: 1
2026-04-24 10:15:28.765 INFO ClientEventEmitter Received event threadNetworkDiagnostics.networkFaultChange on server-2-134b.@1:33 current: 1 previous: 1
2026-04-24 10:16:11.716 INFO InteractionMessenger @1:33•87b5⇵19c0 Error sending success after final data report chunk [peer-unresponsive] Peer is no longer responding to active session (timed out after 43s)
2026-04-24 10:17:09.781 INFO ClientSubscription Subscription cc5035e3 to peer @1:33 timed out after 1m 41s
2026-04-24 10:17:09.782 ERROR ClientSubscription Replacing subscription to @1:33 due to timeout
2026-04-24 10:17:09.783 INFO ClientInteraction Probe » @1:33•87b5⇵0754
2026-04-24 10:17:14.087 INFO ClientInteraction Probe « @1:33•87b5⇵0754 1↔2+1 (success)
2026-04-24 10:17:14.089 INFO ClientInteraction Subscribe » @1:33•87b5⇵0755 min: 1s max: 1m 2s attributes: 1 events: 1
2026-04-24 10:17:17.216 INFO ClientEventEmitter Received event threadNetworkDiagnostics.connectionStatus on server-2-134b.@1:33 connectionStatus: 0
2026-04-24 10:17:17.286 INFO ClientInteraction Subscription successful « @1:33•87b5⇵0755 7↔7 id: e2cae983 interval: 1m 2s timeout: 1m 41s

Any thoughts on what this might be? I was previously extremely stable.

[fringe fjord]

Look at the events ... eems like the devices lose their thread connection and restore but in that regard the subscrition dies and get re-established

[silk plover]

Could it be the recent shorter intervals put in place to more quickly show devices are unavailable have just unmasked something that has been going on in his network the whole time?

[flint compass]

What do you mean by events?

[flint compass]

Would be surprised because I have been reviewing logs. Devices have been going offline briefly all day. At one point about 11 out of 102 devices went offline and came back quickly. I’m restarting Apple TBRs to see if that helps.

[fringe fjord]

Look at the lines with „received event …“ about connectionStatus

[glacial knoll]

Up until 0.6.0 software a matter device going unavailable could fail to be reported to HA. That was fixed on 0.6.0 and later (thanks @fringe fjord). As @silk plover said this could mean that you were experiencing the short term drops you are reporting here all along but HA would not have been reporting it to you. If you can catch one of your devices in the down state try pinging it from HA. If you get no response that points towards a physical later or link layer issue (the device has restarted or the Thread connectiion to it is down) rather than Matter itself.

[flint compass]

I see a bunch of logs like this:

2026-04-24 15:33:20.925 INFO ClientEventEmitter Received event threadNetworkDiagnostics.connectionStatus on server-2-134b.@1:53 connectionStatus: 1

I noticed that the devices blinking offline were all in one area of the house so I rebooted the Apple TV in that area, and it seems to have taken care of it so far (about 9 hours).

[rigid bone]

FYI, don't know if this is new or old, but seeing every few hours for each of my IKEA Alpstugas: 2026-04-25 18:19:19.994 INFO ClientEventEmitter Received event timeSynchronization.timeFailure on server-2-134b.@1:d undefined

[deep drift]

This is a known issue. See https://github.com/matter-js/matterjs-server/issues/245

[fringe fjord]

…what Phaze75 said, and affects both servers

[fringe fjord]

🚩 Matter Server Beta 0.6.2 released just now ... several optimizations and improvements under the hood. https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#062-2026-04-26

[strong hazel]

Thanks for the new Beta.

Does this Beta include the new storage system that is being trialled separately?

[fringe fjord]

no the beta does not enable this by default ... this will also come soon but in an extra version

[unique pine]

Hi. I've just started to follow the developments in the matter stack. Is my understanding correct that commissioning nodes to Tread network using BLE on Linux is not implemented yet?

[fringe fjord]

It is implemented and working. You might need to ensure some permissions or set special flags for docker because of the same reason. Just check the docs in the GitHub repository.
When using the HA addon you need to add a ble adapter to the device and provide its id in the app/addon config.

But also ensure that the device is near the HA host for commissioning.

[unique pine]

oh, I'm rather trying to setup a dev env for now. Just running the server directly from js repo, without HA. Only OTBR is running alongside

I believe the BLE lib on nodejs - is noble . On linux, does it talks to bluez over Dbus?

[fringe fjord]

Then ensure you read the js docs on it. Basically runners root or use setcap on nodejs to add needed permissions to acces ble. And you might need some packages installed. But all mentioned in the docs

It uses hci so should be bluez. But check the readme. All in there

And you Lao might need special Linux kernel setting tweaks for IPv6. Also in the docs

Especially https://github.com/matter-js/matterjs-server/blob/main/docs/os_requirements.md is your friend

[unique pine]

thanks

[strong hazel]

Thanks for the info!

[fringe fjord]

Stay tuned for next version :-))

[agile dagger]

Just curious does matter binding work in any different manner from the python matter server?
Just something I notice and it may just be because of infancy of the feature.
I have bound one of my Inovelli switches to 3 Aqara t2 bulbs and one of them bound to 6 Nanoleaf essentials a19 bulbs.
They work great for the most part but every so often toggling the switch on just doesn’t do anything. Almost like a network delay but my understanding of it is that it’s supposed to be direct command. Pushing the switch up a couple more times with pauses in between or hold up as if you’re increasing brightness typically brings everything back in sync.
Just curious if anyone else has issues with this or if matter binds work any different on the new server.

[fringe fjord]

As you already stated the server is 1000% out for bindings. Once setup zhe communication is between the two nodes directly.

The only thing we know are firmware issues especially in Nanoleaf that bumb 1500 bytes of data over the thread wire (per light bulb!) when you turn off (turn on is only 150 bytes).
So we had several people already reporting "when I turn on multiple nanoleaf then all fine, turn ing off is unreliable sometimes" ... so that could be the same for you?!

But thats clearly a Nanoleaf light bulb issue

[agile dagger]

Interesting. I have never had issues turning off, only seems to happen on “on” requests. Since it happened with both the Aqara and Nanoleaf I figured it wasn’t manufacturer specific issue. Inovelli states supporting binding but not sure if it’s a must support on the bulbs as well and if manufacturers plan on bringing support up, if that is the case.

[fringe fjord]

In case of such bindings the lights are just "command receiver", so the whole logic needs to be on the switch side to trigger the right commands and such ... but I am not too sure how good this works with 6 lights because effectively the switch needs tomaintain at least 7 sessions then (one to the matetr server and one per light) .. no clue if there are also resopurce constraints or such ...

[glacial knoll]

A question on OTA updated. Is it expected behavior that at the end of an OTA update we should see
2026-04-29 05:36:45.301 INFO WebSocketC~erHandler [15] WebSocket connection closed
2026-04-29 05:36:45.492 INFO WebSocketC~erHandler [16] WebSocket connection established

[fringe fjord]

OTA done via HA or via Server dashboard?

[glacial knoll]

OTA done via HA.

I have 3 devices left to upgrade so I can try it from the Server Dashboard if you like.

[fringe fjord]

Yeah try ... I can not see any reason in the dashboard for a "websocket reconnection" ... then we need to check in tghe HA integration

[glacial knoll]

Give me five minutes.

Saw exactly the same.

[fringe fjord]

and browser wise all was still in front of you ... so no tabs in the background or such? because browsers tend to stop threads in the background and this kills the WS ping pong rezuiring a reconnection

So was the dashboard and HA open same time in different tabs or oly HA ?! Ned more details because I was not able to spot something like that so far ... but would beed to test and try to reproduce

Also claude was not able to find any reasion for this in server or HA code

[glacial knoll]

No I left the browser visible till then end. I will try it again to be sure from the Matter Dashboard using Safari rather than Brave.

Updated another device (same type) using Safari this time from the Matter Server UI. This time I kept an eye on it from start till end. Same result.
2026-04-29 07:57:23.813 INFO WebSocketC~erHandler [1a] WebSocket connection closed
2026-04-29 07:57:24.018 INFO WebSocketC~erHandler [1c] WebSocket connection established

[fringe fjord]

Then something and somewhy/somehow is closing and reopening the Websocket connection. Please grab and post a bit more log around it ... like a minute or two before and after

[glacial knoll]

This is everything that relates to the OTA update. The logs are clogged with the electricalEnergyMeasurements events that I am yet to find a way to surpress without loosing all useful lg data however this is what I have:

[fringe fjord]

in general you have 3 parallel websocket connections and one of them is basically reconnected

[glacial knoll]

The reconnection always happens at exactly the same point.

[fringe fjord]

but you curred the log very exact so I can not see over whoch connection the update reuqiest came in 🙂

(and yeahh likel that would also onlybe looged with a dbeug log

[glacial knoll]

I have one more un-upgraded device.. Let me know exactly what you need and I will give it my best shot.

[fringe fjord]

I can not tell tbh ... as said you have 3 websocket connections in parallel ... so one should be HA, one could be browser? or have 2 browsers open?
The question is if it is really worth finding that out ;-))

So for more likely need to enable debug log and then you can try again and we see if the connection that triggers the update is the one that reconnects ... I do not know.
I have also no clue if maybe the "HA update dialog" has it's own session ...
maybe open an issue with the HA integration and add a debug log ... There are too many questions open and I am unsure if we can figure that out and maybe need infos from the integration python devs

[glacial knoll]

OK... this is what I plan to do... close all browser windows that could be connected to HA including the Companion App
Wait for say 20 mins so literally everything will have timed out.
restart the matter server in debug mode
Open a single browser directly to the Matter Server Console Port (not via HA).
Try the upgrade again.
sound reasonable?

[fringe fjord]

if HA is running it will also consume one connection ... better do nt do broeser nd just do HA ... when it then still happens we know that it comes somewhere from there

and write down time wise what happened when

🚩 Matterjs server 0.6.3 released with some optimizations and especially Thread BR name enhancements ... https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#063-2026-04-29

[glacial knoll]

OK..... upgrade from HA it is.

[hollow cloak]

@glacial knoll I converted your message into a file since it's above 15 lines :+1:

[raven harbor]

fascinating

[fringe fjord]

i think thats looks like a HA integration crash. please create a core issue with the two logs ... ok forget it ... I fix it in the server bevcuase it basically is a different behavior than te python server

[silk plover]

Nice peak behind the thread network border router Curtains in 0.63: I can now finally easily differentiate the BBR (primary) from BBR (secondary) thread Border routers for those that have multiple. Confirming that the Primary thread border router and the primary Apple Home hub are not linked. I still have a couple unknown external routers and haven't located the Aqara M3 hub yet, but great progress!

[fringe fjord]

But at least you easiely see now - for these "still external routers" to which network they belong ...

[raven harbor]

I think 5 out of my 20 TBRs are still listed as unknown. What could be the cause?

[fringe fjord]

We send one MDNS query on start and then look for all data that come in MDNS wise ... other network segments or such? Otherwise maybe give MDNS a bit more time?

[raven harbor]

same Thread mesh, but I have a heavy network.. so could be the latter

[raven harbor]

is it possible to add extra tolerance?

[fringe fjord]

The server collects the data from start on and when you open the thread panel in the dashboard they are loaded from the backend ... so there shpuld be enpigh tolerance unless you open the panel 2s after start 🙂

I think it is enoiugh tolerance. else try to do mdns lookups if you fiond these ones that are missing

[raven harbor]

They are there (mDNS) but some just take longer to show up; same for the Thread Integration page in Home Assistant

[fringe fjord]

then they should get mapped when the server runs a bit. I still think thats ok and we shpuld not delay displaying the thread page because of that ... just reload and it gets new data frommbackend

[raven harbor]

May I ask if it is a live discovery? or an one time fetch?

[fringe fjord]

continously

we end one query and then we grab anything that is coming in ... continously

[raven harbor]

I see... I tried refreshing the page then I lost 10+ now

[fringe fjord]

only thing I could check is that we keep records also when the entries expire .. but that more seems liek an MDNS stability issue in your netwoprk tbh

[flint compass]

I've mentioned this before, but about 22 hours after restarting / updating the Matter server, I start to get offline devices. First one here and there and then in increasing frequency. It's happened twice so far. The first time about a week ago, and which I mentioned here. I rebooted one Apple TV and that seemed to take care of it. Maybe it was the "lead"? And again today: I updated yesterday around 11 am, and starting around 9 am this morning, I started to get offline devices. Around 2pm today, I went ahead and restarted my HA machine and updated the Matter server again. We'll see what happens around tomorrow at noon, but I'm seeing lots of stuff like this in the logs already:

2026-04-29 15:02:06.748 INFO ClientSubscription Subscription 4dd92931 to peer @1:23 timed out after 1m 39s
2026-04-29 15:02:06.749 ERROR ClientSubscription Replacing subscription to @1:23 due to timeout
2026-04-29 15:02:06.750 INFO ClientInteraction Probe » @1:23•7d0a⇵90fe
2026-04-29 15:02:06.809 INFO ClientInteraction Probe « @1:23•7d0a⇵90fe (success)
2026-04-29 15:02:06.850 INFO ClientInteraction Subscribe » @1:23•7d0a⇵90ff min: 1s max: 1m attributes: 1 events: 1
2026-04-29 15:02:08.405 INFO ClientInteraction Subscription successful « @1:23•7d0a⇵90ff 6↔6 id: c42d2367 interval: 1m timeout: 1m 39s

Before I restarted this morning, I was also noticing that several of my Inovelli White switches were behaving oddly, taking up to 40-60 seconds to respond to button clicks, although they appear online.

I don't know where to begin to troubleshoot this. Should I just reboot all of my (Apple) TBRs one at a time and see if that clears the issue? I have been recording the Matter Server logs since today's restart, if that's helpful.

[manic moat]

Hi. Is this the right place to ask about my python-matter-server instance, which is running in a docker container? More specifically, how can I get it to use a systemd controlled avahi-daemon instead of trying to listen on 5353 itself?

Or is there a better channel for this? https://discord.com/channels/330944238910963714/1284966617670881350 ?

[flint compass]

Yes this is for people testing the matter.js beta.

[flint compass]

Update: Tried rebooting the Apple TVs one by one. After I rebooted one of them, nearly all of my Matter devices has gone offline. After a loooong time they started to come back online, and then back up to most offline, got down to about 10 percent offline, and then back up to 30 percent. Not sure what the issue might be or where to look, Here's a snippet of the latest logs with all the churning... Ideas welcome!

[flint compass]

OK, about 5 minutes ago, my number of offline devices is 0. Took about 1.5 hours. This doesn't feel right for the matter.js server, even with 102 devices. Usually takes less than 10 minutes after any kind of restart or reboot of HA, Matter, or TBRs. I'm continuing to record the log and will wait to see what happens.

Update 1: I’m back up to 53 devices offline again. I guess I’m going to start rebooting.

Update 2: It's been several hours now and a device or two are blinking out here and there. Nowhere near the stability I had in earlier versions of Matter.js.

[raven harbor]

Anyone tried the sensitivity option with the latest beta Matter.JS Server and HA beta? Does it work as expected?

2026-04-30 13:43:42.787 ERROR Transaction Rolling back ◦setStateOf<server-2-134b.@1:1c.ep1>#e5f due to error: Validating server-2-134b.@1:1c.ep1.booleanStateConfiguration.state: Constraint "all": Value 1 is not within bounds defined by constraint (135)
2026-04-30 13:43:50.273 ERROR Transaction Rolling back ◦setStateOf<server-2-134b.@1:1c.ep1>#e79 due to error: Validating server-2-134b.@1:1c.ep1.booleanStateConfiguration.state: Constraint "all": Value 1 is not within bounds defined by constraint (135)
2026-04-30 13:44:22.848 ERROR ClientSubscription Failed to establish subscription to @1:df, retry in 17.7s: [aborted] Operation aborted: [peer-unresponsive] Peer is no longer responding to active session (timed out after 11.5s

[fringe fjord]

Have a debug log please? And yeah would i retesting if newest matter server beta and old python works because there were also other changes in 0.6.3 that could cause that

[fringe fjord]

do you also have the screenshot for that device attributes? especially the id 1 ... so how many state the devcie has

[raven harbor]

3

[fringe fjord]

so i would more think it is an issue because of an other changein the server I did in 0.6.2

i check

[raven harbor]

It reads the value changes correctly but wont set

[fringe fjord]

on it

but nothing to do with the beta of HA ... likely server

[raven harbor]

yea I don't see error from HA Core log

[fringe fjord]

create issue pleas ein matterjs server. i check

[fringe fjord]

Yes this is not thr right channel for python server questions. But because we are short before to declare the matterjs server as the new default one and decease the pythonone the question is still relevant. And answer is: No currently - and also especially with the whole dockerized usage/setup here, there is no easy way to rely on an systemd based MDNS solution ... For the matterjs server we have a todo on our list to look into using DBAUS or such but when running in docker this would also not help that much ... so rigt now not easy to solve

[raven harbor]

https://github.com/matter-js/matterjs-server/issues/589 Thanks, I just created one

[fringe fjord]

With all I see in logs (more details in the private messages I sent you) ... Yes there are issues either on the OTBRs or on the devicees. the event sreceived from tgeh devices on a new subscription clearly state that the devices astill "run" but had several thread connection issues (disconnects and reconnects) and also reporting a "Hardware network fault" whatever "hardware "means in this case ... so it is clearly states by that to me that the devices have a hrd time staying connected and all this clearly is reflected by the log from the controller side.
The question why the devices fall off the thread is not the topic I can not really say anything about. It could maybe be an idea to grab details and report to apple .. but thats not a "fast solution"

[strong hazel]

Wow! You have a lot of matter over thread devices.

How many routers and border routers do you have in total?

[raven harbor]

That’s pretty much the same situation I have? Some TBRs are not labeled due to slow mDNS response somehow

[fringe fjord]

I will update for next version that msnd is longer cached for the OTBRs when "Just going offline" mdns wise

[raven harbor]

Thanks 🙏 maybe a better cache mechanism?

[fringe fjord]

exactly

[raven harbor]

Lovely, I’m updating my article draft for the feature 🚀

[fringe fjord]

Comes together with the fix for the issue you found hopefully later today

[silk plover]

14 border routers at the moment, 1 aqara M3, 1 ZBT-1 (only usable with OTBR beta) and the rest AppleTV/Homepods. Have more homepods but I’ve unplugged several that we no longer use. 60 or so thread routers. Some here have much larger setups.

[fringe fjord]

🚩 0.6.4 of the beta server just released ... https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#064-2026-04-30 ... Optimizations to the Thread chart and @raven harbor please verify the fix for the mode set

[raven harbor]

P100 with 10 levels sets successfully; P2 motion sensor with 3 levels failed with errors from HA Core

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:332
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 23:46:41 (5 occurrences)
Last logged: 23:47:14

[140165897325760] Error during service call to select.select_option: Unhandled error in commit phase 2 participant remote-writer
[140165897325760] Error during service call to number.set_value: Unhandled error in commit phase 2 participant remote-writer
[140165077772672] Error during service call to number.set_value: Unhandled error in commit phase 2 participant remote-writer

[raven harbor]

Do you need extra logs from Matter Server?

[fringe fjord]

if you like yes, but if it works basically optional 🙂

if you eant add to the issue

[fringe fjord]

Ohh just see that error now. Please add to the issue with log from
Matter.js and ha side

[raven harbor]

Just did with additional logs 😁

[silk plover]

So all of my unknown external routers were connected to Aqara T2 bulbs, I believe these were ghost in the T2 routing table reported to Matterjs Server, of TBR that either were powered off (removed couple HomePods over a month ago, or the TBR just changed address/name with a power recycle.)

Power cycling the aqara T2 bulb and waited for it to be reported offline in the hopes of degrading any cached values, removed those particular unknown external routers.

The only 2 remaining unknown external routers are connected to an offline device (Inovelli switch that has been completely removed from the wall, no power for 2-3 weeks) still has mapped connections in the mesh graph. I assume this is just cached data from its last reported connections. Should those not eventually drop in the Thread Mesh graph and the offline device end up floating in space alone?

For every thread router connected to this offline device I ‘updated the connection data’ from the thread mesh graph

[fringe fjord]

So ignore all offlone connectoons or only those to "unknown nodes"?

My idea would be "hode all unknown devices/routers that are only conected to offline dveices ... but the offline and it's connections to "other known ones" should still be shown. So here we would only remove the two external routers on top ... make sense?

[silk plover]

What does the dashed line and arrow directionality of the lines mean again? Just trying to see if we have any additional logic we can use.

[fringe fjord]

the arrows mean that "just that one connection exists" which make sense for the offline one because all others do not see that right now. a "both way mapping" would have no arrows

i think dotted also means "one way"

[silk plover]

Like should/could we remove all of the outgoing data lines that the offline device has reported? And only continue showing lines that are incoming (connections to offline node reported by other devices)?

[fringe fjord]

If others are updated then all offline would float around unconnected ... i thought maybe makessense "where they normally would be connected"?

(when the devices are online)

[rigid bone]

Running into a problem with the Thread topology graphs (now on 0.6.4). I have two HA systems on the same LAN, one a test system, the other a production system. They both use the same Thread network (around 20 devices total), but the test system only has around 3 Thread nodes in its Matter fabric (they all show up in the "Nodes" tab), the production system's has almost all the Thread devices in its fabric. The production system's Thread topology graph works fine. But now the test system's Thread graph is completely blank (it had shown Thread nodes in the past), yet its Wifi graph (of one node) works fine. Thought it might be Windows/Chrome front-end but same problem on an iPAD/Companion App. Nothing in the logs [info]. Have done a complete system restart just see if it helped, but no change.

[fringe fjord]

hm ... the test system one should at least show still the test device nodes and - see above - what they think are connected to even if the BR is not discovered ... I will check again. if you like enable debug log in dashboard temporariely ... then open the thread visu page and then post the debug log (you should see a "get_theead_whatever" websocket message with data ... share that

[rigid bone]

OK...

See if I can paste this snippet...

2026-04-30 15:22:54.812 DEBUG WebSocketC~erHandler [2] WebSocket request {"message_id":"1736136209","command":"get_thread_border_routers","args":{}}
2026-04-30 15:22:54.813 DEBUG WebSocketC~erHandler [2] WebSocket response (get_thread_border_routers) 1736136209 { extAddressHex: "6EEBCAFEC4632D27", addresses: [ "fdaf:77aa:4dae:faef:7eb6:7c01:5d03:c9b6", "fe80::67e2:ae44:5824:8498" ], sources: [ "meshcop", "trel" ], lastSeen: 1777576728054, extendedPanIdHex: "AF77AA4DAE87FAEF", hostname: "ot6eebcafec4632d27.local", trelPort: 43818, meshcopPort: 49154, networkName: "home-assistant", vendorName: "Home Assistant", modelName: "OpenThread Border Router", threadVersion: "1.4.0", stateBitmapHex: "00001CB1", activeTimestampHex: "0000000000030000", partitionIdHex: "150C18E0", domainName: "DefaultDomain" } { extAddressHex: "6202D8C1156DF461", addresses: [ "fdaf:77aa:4dae:faef:574c:3291:8e74:c5d2", "fe80::d748:345d:bd81:54ee" ], sources: [ "meshcop", "trel" ], lastSeen: 1777576728089, extendedPanIdHex: "AF77AA4DAE87FAEF", hostname: "ot6202d8c1156df461.local", trelPort: 38230, meshcopPort: 49154, networkName: "home-assistant", vendorName: "Home Assistant", modelName: "OpenThread Border Router", threadVersion: "1.4.0", stateBitmapHex: "00001DB1", activeTimestampHex: "0000000000030000", partitionIdHex: "150C18E0", domainName: "DefaultDomain" }

that's all there is

[raven harbor]

Just realized I have an Aqara T2 as well; shared it from IKEA to HA and saw it only connect to one unknown router

[silk plover]

I would vote to have it floating around unconnected and that showing it where it was or should be connected is misinterpreted as an error by most users, but dont have really strong feelings on it.

[hardy juniper]

For instance I have all these external router connected to this aquara h2 switch. No idea what they are or how to figure out what they are. If these are all old connections not really connected I'd prefer they are just outside and marked as some kind of "not being used" color. My mesh is working fine and it is all on 1 thread network.

[silk plover]

5 of the 6 T2 bulbs in my home had a different unknown TBR connected to each. The 6th one I power cycled the other day, so dont know if it also had a Ghost TBR before then

[silk plover]

Can you power cycle, breaker box maybe, the H2? It may have the same firmware issue the T2’s seem to have. I left my unpowered until they displayed as offline in matter server.

[hardy juniper]

I can, of course it wacks out the network for a while but I'll do it soon

[hardy juniper]

They all disappeared after the power toggle and network didn't suffer much while off which was great.

[hardy juniper]

I may just shut off the power to the whole house and reboot everything. See if any of it comes back:

[fringe fjord]

That’s ok. So he found the BR at least.

[fringe fjord]

But that’s different because here device id online. And via vs arrows you see that the light has them in its table. Try reload the data if the light bulb.

We could also additionally say to hide „unknown router leafs“ … in general or only if they only have one connection?

[fringe fjord]

Next version will do this ... lets see how it is

[silk plover]

Might I suggest using the new discovered name (when available) for external devices in the Connections and Neighbors list of the Thread Mesh Graph? You already do this for Nodes. Happy to start an issue in Matter server if that seems a reasonable ask.

[rigid bone]

Is there a way to downgrade MatterJS to a previous release? If yes and you think it would be beneficial, I can check to see which previous release the Thread graphics did work in

[fringe fjord]

Yes you can downgrade - use the server versipn field in the settings ... when beta and you enter a 0.x version then it should install this instead of "latest". Yu need one of the most recent integration versions then too

[rigid bone]

OK, thanks. I am finding that it last worked in 0.6.2.

[fringe fjord]

Then open an isue please in the matterserver repo ... state the infos you have, add screenshots that worked vs "not". For all the devices you have in this test network please go into the dashboard - root endpoint - thread diagnosticcluster and also copy and paste the values of te neighborTabkle and rotingTable attributes into the issue togeter with the info from whcih nde (as text please not image). I will look at it then

[rigid bone]

will do... thanks! Done. Added as Issue #597.

[pure scaffold]

Matter is just totally not working for me. Says "can not connect to device" and there is no log of any details of what is happening

[fringe fjord]

Ok we need wwaaaayyy more details to support here. Maybe better trying in the general matter channel or Arcturus ecosystem protocols and add anything there you have as infos. How you run the server. Your network structure… (I guess you already checked all docs and such)

[fringe fjord]

Sorry but that question is wrong here in this channel because here we just talk about the new Matter server

[warped kraken]

Got 2 quick questions:
1, i know matter groups are implemented in the matter.js server. Any plans of HA integration support?
2, matter bindings ? is it planned ?
Thanks!

[fringe fjord]

Again basically no question for this channel 🙂
Bindings ... the matter server dashboard contains the same options to set them up (experimentally) - same as the python server
Groups, yes planned, but I do not have more info yet. Likely we will add something to the matterjs server dashboard to experiment first. (and groups in general are implemented but a management layer for them is still missing and needs to be added, so we are not fully there)

[strong hazel]

I know HA Matter Server beta updates to the latest version pulling alpha or nightly Matter js version when restarted. Is it planned in the future to stop it from updating on restart?

Some of us may not want to use an alpha or beta version once HA Matter Server becomes stable. Thanks for your great work.

[silk plover]

The assumption is after stable MatterJS Server is released, you only need to deselect "use Beta" in the in the Matter server App Configuration and you are done. After that (Matter Server App 9.0 lets say) the stable releases will come as a new Matter Server App and not on ever restart regardless if a new beta is available or not.

[fringe fjord]

The automatic update will only update official versions. Nightlies will NEVER we automatically updated because they are never pushed on the latest npmjs tag. So you only get versions that I want you to get by intendn and that I also officially release and announce here!
But yes right now on each start we install nodejs and also install the newest version from "latest tag" even if it is the same version as on. the last start.
This is needed because the JS version is still "piggybacked" on the Python server because you can still switch to Python version any time.

As soon as we declare the JS server as the official one (will be an HA intergation 9.0.0) then there will be no python anymore and we use the latest released matterjs server docker image which then also have a more optimized size and will directly include the relevant matter server version a nd remove any buulding or downloading efforts.

With release of the v9.0.0 of the server we might still have a beta that updates to special beta versions ... biut lets see how we do that later then

[strong hazel]

Thanks @silk plover and @fringe fjord

[pseudo sandal]

425 Thread nodes. This is more than double what Python Matter server could achieve.

Thank you OHF team, for the amazing work. I’ll hit 450 nodes soon.

[reef smelt]

That's practically a whole sweater

[raven grotto]

https://tenor.com/view/supertroopers-little-guy-wouldnt-worry-gif-17147609

[pseudo sandal]

Literally lmfao, good one (this movie is the goat too)

[raven grotto]

https://tenor.com/view/ываавыс-gif-25854535

[fringe fjord]

🚩 Ok 0.6.5 of the Matterjs server was just releaded with some smaller optimizations, see https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#065-2026-05-04

[strong hazel]

So happy to report that this beta version removed the two ghost routers that refused to go away. Thanks a lot for your great work

[wide charm]

@fringe fjord Thanks so much for the work on the matter.js server, truly night and day. Is there a timeframe for groupcast / 1.6 support (I’ve seen the PR)? I’ve got an array of 20 bulbs which all should be controlled together, any solution I’ve come up with so far either is super slow or ddos’s thread.

[fringe fjord]

I can not say anything about the planned timing for Groupcast or for Matter 1.6, but if all goes well we might add basic group support using the currently existing group implementations maybe before that, but lets see. If you want to prepare yourself ... The more current matter versions (min 1.3) your lights - or whatever you want to control in groups - have the better

[deep drift]

Is it intentional that the three-segment signal meter (green, orange, red) in the Thread visualization doesn’t always match the LQI values (3, 2, 1, 0) reported from Matter devices? It appears the signal meter segments are based on RSSI ranges rather than LQI. Is that correct?

[silk plover]

@fringe fjord, I realize this is a small thing over all, but any thoughts on changing the Matter Server App dock icon when you go to version 9 or whatever version marks the change to a stable underlying Matterjs server replacing python matter server for all?

https://github.com/home-assistant/addons/issues/4308#event-25147567418

[fringe fjord]

Yes.

[fringe fjord]

Need to check what the reason was that it is no matter icon currently.

[deep drift]

Is there a reason why it is not matched against the LQI?

[silk plover]

Thanks, HA devs have allowed the matter logo/icon in the settings menu, since they added the direct Matter Entity/Device section so that barrier seems to have been crossed.

[fringe fjord]

Good question. I think assumption was that Russo is better 🙂

[deep drift]

RSSI is about signal strength, while LQI is about received packet quality. Afaik a higher LQI usually means fewer errors in the received frame and shows how clean/reliable transmissions were. A strong RSSI can still have a poor LQI if there is interference or corruption on the link. So, for troubleshooting LQI might be even more helpful. Would it be an option to add a switch to toggle between RSSI and LQI?

[fringe fjord]

sure, open an issue to propose it ... we use LQI already so should be easy to switch and basically it also is "just 0..3"

[deep drift]

Perfect, will do!

[craggy scarab]

Are there ways to get more debug information than what is given in the debug logs of the server? "Re-Discovered device" is not quite enough to understand why this one single light won't commission...

[fringe fjord]

The Beta server we talk aboit here should have different logging ... this log line feels like you use the Python server ... then thats the wrong channel

[craggy scarab]

I am talking about ghcr.io/matter-js/matterjs-server:stable. Here is a concrete example of what I am talking about. It looks like something going wrong, but I cannot make out what exactly..

May 05 19:34:32 pi1.local matter[26491]: 2026-05-05 19:34:32.584 DEBUG  NobleBleClient       Found peripheral ea:b3:ac:f5:56:55 (LED Light0x07C2): {"localName":"LED Light0x07C2","txPowerLevel":"undefined","manufacturerData":"undefined","serviceData":[{"uuid":"fff6","data":{"type":"Buffer","data":[0,123,12,124,17,5,144,0]}}],"serviceUuids":[],"serviceSolicitationUuids":[]}
May 05 19:34:32 pi1.local matter[26491]: 2026-05-05 19:34:32.585 DEBUG  BleScanner           Re-Discovered device ea:b3:ac:f5:56:55 data: {"deviceIdentifier":"ea:b3:ac:f5:56:55","D":3195,"SD":12,"VP":"4476+36869","CM":1,"addresses":[{"type":"ble","peripheralAddress":"ea:b3:ac:f5:56:55"}]}
May 05 19:34:32 pi1.local matter[26491]: 2026-05-05 19:34:32.612 DEBUG  NobleBleClient       Found peripheral ea:b3:ac:f5:56:55 (LED Light0x07C2): {"localName":"LED Light0x07C2","txPowerLevel":"undefined","manufacturerData":"undefined","serviceData":[{"uuid":"fff6","data":{"type":"Buffer","data":[0,123,12,124,17,5,144,0]}}],"serviceUuids":[],"serviceSolicitationUuids":[]}
May 05 19:34:32 pi1.local matter[26491]: 2026-05-05 19:34:32.612 DEBUG  BleScanner           Re-Discovered device ea:b3:ac:f5:56:55 data: {"deviceIdentifier":"ea:b3:ac:f5:56:55","D":3195,"SD":12,"VP":"4476+36869","CM":1,"addresses":[{"type":"ble","peripheralAddress":"ea:b3:ac:f5:56:55"}]}

[fringe fjord]

Ahh ok ... yeah thats the matterjs server - whats the exact question? 🙂

"Re-Discovered" in that cointext just means that we got "the same BLE discovered devcie that we already know" ... thats ok ... so whats the "issue"?

potentially you need to say a bit more or share a bit more logs?

(and BTW: When it is found but you say "device mot discovered" then this normally means that it did not matched the data of the matter pairing ... and for that i would need more log to say whcats up and if thats really the case)

[craggy scarab]

These lines loop quickly until timeout is reached and commission is aborted. I figured I’d try to debug this a bit further before asking for help. Let me grab a longer log

[fringe fjord]

yeah show a log because usually it means you have the wrong QR code or such because else it would match it ... or it already tried to connect but because of ble issues it keeps re-discovering but connection fails ... can be several things

[craggy scarab]

Here is a log where I try to commission a kajplats around in the middle. I do have a bit of a special setup with a raspi running fedora iot, which in turns runs the matterjs, otbr and ha in podman containers. commissioning via phone never worked for me, so I put the code into the matter webui. I made sure its correct and the light is in pairing state. Its weird, I just commissioned another kajplats, but with this one no change. Same goes for the varmblixt and a bilresa 2x button

[fringe fjord]

I see

20:52:13 Peripheral e9:6d:b6:fc:ea:49: Connect to Peripheral now (try 1)

… then nothing anymore till 20:52:07 … I assume that a bit time later you would get a connect failure and retries.

But basically ble connection issues. Try to reset then ble adapter. Move the devices or such. Try a device factory reset directly before entering the code …

So just wait until you get a response. I would assume the ui still shows a spinner right? 😉

[craggy scarab]

Indeed, after a reboot of the pi it worked first try. What...
Now, its just the Varmblixt that suddenly resets during the commissioning process, but that still feels more like a problem on the devices side.

[fringe fjord]

There is an issue open already in matterjs-server for varmblix ... is that from you or someone else? if someone else we would have now "the second" user we always searched for

[craggy scarab]

Nope, that one is from me 😄 I am surprised that seemingly I am the only one with that issue.
Its more obvious with that lamp: BtpSessionHandler Acknowledgement for the sent sequence number was not received ... disconnect...

[strong hazel]

I just noticed you are already working on adding LQI on GitHub page. Would it be possible to add a toggle switch so that the users can choose between LQI and RSSI for more diagnostic comparison or analysis? Thanks

[fringe fjord]

Honestly lets not make it too fancy because basically noone will really use that ... and I agree that Thread wise the LQI is the better way, because:

• RSSI is no tofficially exposed by the Thread data but "somehow calculated by logic in the matter server" by trying to use the data available
• LQI is officially exposed from the devices and so dorectly used for routing decisions, so thats "THE" value whoich is relevant
  So with this I would stay with "we show RSSI still in the node details but use LQI for the connection colors"

[fringe fjord]

yeahh your log clearly shows that after the successfull handshakle (so there was traffic back and forth) and when we send the first message to the device then the devcie stopos responding and somewhen disconnects

[strong hazel]

Cool

[wide charm]

Was there a change made recently that might persist data for longer than ideal? Have a number of lights which are reachable but report stale brightness values from hours earlier until I control them.

[fringe fjord]

Nope. No such changes were done. Also: is HA showing stale values or also the matter server dashboard?

[wide charm]

Good question. Will check next time it pops up

[boreal coyote]

are these nanoleaf by chance?

[wide charm]

IKEA

[glacial knoll]

Are you aware of a problem with bindings? I'm trying to add a binding between two VTM31-SNs using the matter web ui. These two devices had previously had a binding setup in teh Python server which was deleted via the Python server. However trying to add it back via matter.js gives the following errors:

2026-05-07 07:05:09.846 INFO Controller~ndHandler Setting ACL entries { privilege: 5, authMode: 2, subjects: [ 112233 ], targets: null, fabricIndex: -1 } { privilege: 5, authMode: 2, subjects: [ 56 ], targets: [ { cluster: null, endpoint: 1, deviceType: null } ], fabricIndex: -1 }
2026-05-07 07:05:09.849 ERROR Transaction Rolling back ◦setStateOf<server-2-134b.@1:16>#dbb due to error: Validating server-2-134b.@1:16.accessControl.state.acl.0: Value -1 is below the uint8 minimum of 0 (135)
2026-05-07 07:05:09.850 ERROR WebSocketC~erHandler [3] WebSocket error response (set_acl_entry) 1736307118 Cannot read properties of undefined (reading 'find')
at ControllerCommandHandler.#writeAttribute (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:624:44)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async ControllerCommandHandler.setAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:1140:28)
at async WebSocketControllerHandler.#handleSetAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:1011:16)
at async WebSocketControllerHandler.#handleWebSocketRequest (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:489:30)

I also get the same error on two switches that have never had bindings

[fringe fjord]

🚩 0.6.6 of the matter serve rjust got released -> https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#066-2026-05-07

[fringe fjord]

please open issue, no not yet known. Also please add logs and tell what you used to send the ACL requests and such - but yeahh I see the prioblem. open issue please I will fix it

[glacial knoll]

Copy that... I will do it later today.

[fringe fjord]

Ok, wait I just prepare 0.6.7 ... just already found the cause ... fix soon

[glacial knoll]

Copy that... thanks... bad fabric_id?

[fringe fjord]

no bad dummy constant

[glacial knoll]

copy

[fringe fjord]

🚩 0.7.6 release which should fix the ACL setting ... https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#067-2026-05-07
@glacial knoll please verify

[glacial knoll]

Still fails...

2026-05-07 10:57:42.398 INFO Controller~ndHandler Setting ACL entries { privilege: 5, authMode: 2, subjects: [ 112233 ], targets: null, fabricIndex: 0 } { privilege: 5, authMode: 2, subjects: [ 56 ], targets: [ { cluster: null, endpoint: 1, deviceType: null } ], fabricIndex: 0 }
2026-05-07 10:57:42.401 ERROR Transaction Rolling back ◦setStateOf<server-2-134b.@1:16>#d40 due to error: Validating server-2-134b.@1:16.accessControl.state.acl.0: Constraint "all": Value 0 is not within bounds defined by constraint (135)
2026-05-07 10:57:42.402 ERROR WebSocketC~erHandler [2] WebSocket error response (set_acl_entry) 1388176072 Cannot read properties of undefined (reading 'find')
at ControllerCommandHandler.#writeAttribute (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:624:44)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async ControllerCommandHandler.setAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:1140:28)
at async WebSocketControllerHandler.#handleSetAclEntry (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:1011:16)
at async WebSocketControllerHandler.#handleWebSocketRequest (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:489:30)

[fringe fjord]

Ok open issue please, need to look into that more deeply 🙁

[glacial knoll]

OK... I will do this afternoon... Does the fabricIndex: 0 have any impact?

[fringe fjord]

it is a validation issue ... checking it

[glacial knoll]

Here is the issue anyway: https://github.com/matter-js/matterjs-server/issues/625

[fringe fjord]

fix comes tomorrow

[fringe fjord]

🚩 0.6.8 released with the fix for settings ACLs https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#068-2026-05-08

[deep drift]

The LQI based visualization makes - at least in my fabric/mesh - much more sense now. Overall, there is more "green" and "orange" and the neuralgic "red" edges reflect my observations concerning issues much better. Thanks for the improvement!

[fringe fjord]

I agree. that was a good idea to change it

[glacial knoll]

Binding looks all good as far as I can see... Thanks!

[deep drift]

OTA updates for my Ikea Bilresa Dual Buttons (to 1.9.15) were super smooth. All on first try!

Offtopic: Although they knew, Ikea managed to release a CSA certified firmware that still misses the fix for reporting the correct battery levels of their Laddas… 🙄

[fringe fjord]

What has correct energy value handling to do with csa certification? I think that’s a bit aside certification. In this case they need to adjust the engery calculation curves to convert voltage into level … so that’s vendor specific

[deep drift]

I just meant that Ikea took the efforts for the csa certification of their firmware knowing that the battery level issue still exists. It’s clear that csa can‘t do quality assurance. It is a vendor issue.

[fringe fjord]

Yeahh and as unknown ikea also works on this issue. So just stay tuned

[grizzled burrow]

Yes, I have two Bilresa buttons, and firmware update went smoothly.

[warped kraken]

Should i open a bug report for this: latest matter.js server, HAOS, pretty standard stuff. issue:
"power-on-behavior" on and off and toggle are working, however i cannot set "previous state" (tried on my grillplats plugs, and other non-ikea lights, so it seems like it's not a device bug). The settings seem to apply ok, however if do re-interview the device, it flips back to on or off. When i factory reset a device, it comes with the "previous state" by default, and it works as expected.

[grizzled burrow]

Hmm with 0.6.8 all of my Inovelli exhaust fans stopped working:

[fringe fjord]

Restarted them?

[grizzled burrow]

Not yet, but restarted the Matter server and all 78 devices except the exhaust fans (and one Onvis S4) are back online.

Air gap pull/reset brought them back online. But very odd that ALL of them went offline at the same time and a Matter server restart didnt fix it.

[silk plover]

Hope we get that Matter 1.5 beta firmware for those VTM35-SN this week.

[grizzled burrow]

Yup, I'm tired of all my Exhaust fans going offline periodically.

[slate cedar]

It's exhausting, I'd imagine.

[warped kraken]

Did some more testing. The affected cluster is :

StartUpOnOff
AttributeId: 16387 (0x4003) - Value type: Optional[Nullable[StartUpOnOffEnum]]

In home assistant setting from on/toggle (1/2) to previous state (null) : for a split second the value shows null then 0.
From off (0) it is possible to set previous state (null), at least it seems like that. However after a re-interview the value comes back as 0, and a power-cycle always comes up as off.
I verified this on my ikea grillplats smart plug, and a sunricher sr-mt1029-cct LED driver, both behave exactly the same.
When i comission the device by default that field is null, and works as it should.

[fringe fjord]

Ok turn on debug log in the matterjs server using the dashboard upper right (no restart needed). Then do such a change and post the log from it with also a it afterwards to see the changes or such.

[warped kraken]

i managed to do it, uploaded the log txt:

[rigid bone]

I came across a situation where one of my Eve Energy plugs is showing as off-line and has been for more than a day, but when I check the Thread network using the otbr's mesh diag, the plug is well connected, and I can pings its IPv6 address from HA core. I asked matterjs to reinterview the node, but it aborts/exceptions saying it has been off-line for X amount of time. I re-checked the logs with Debug level, but nothing more significant. Restarting matterjs didn't change things either. I see (from HA Core Networking), there is a matter._tcp.local mDNS advertisement for the Plugs IPv6 address with a name that matches the fabric-id and node-id. Oddly there is another mDNS advertisement for the same IPv6 address but with a different name, fabric-id and a weird node-id (maybe from the iOS commissioning??). Anyway, thought I would share to see what else to check for.

[fringe fjord]

Try to power off and on the plug. Does that change anything? I also have one older firmware eve plug which acts strange. Newest firmwares are better

[fringe fjord]

Log Check states that the write of null works but then the device sends 0 as valid 8ms later. I will decode the message to verify that log is right (what it should) tomorrow. But with that it is a device topic.

[rigid bone]

Yes unplug/replug worked. Strange indeed. f/w version 3.5.0

Looks like ver 3.5.0 is the latest (on DCL anyway).

[warped kraken]

Thanks! It seems weird that different manufacturers/devices behave exactly the same in this way. I just tested with an ikea kajplats light, and it's the same. So i confirm this on 3 devices: ikea kajplats, ikea grillplats, and sunricher sr-mt1029-cct led controller.
edit: i just remembered i have an aqara t2 bulb as well.... quick test show exactly the same behavior as the others.

[grizzled burrow]

Due to buggy or neglected firmware, I'm dumping all Eve devices into the trashbin. Waiting on the Onvis T20 to replace my Eve in-wall outlets. Eve customer support is appallingly bad and rude.

[fringe fjord]

Let me check later in detail. Strange indeed.

[fringe fjord]

Ok seems is an issue in the server ... I will fix it for next version

[fringe fjord]

Reminder: The Matter Community Sync for this month has been moved to next week monday as announced in the last sync. So it is NOT today, but coming monday!

[fringe fjord]

Mega strange. Which version of the matterjs server you use? please restart the server and retry to get the katest verison and try if it happens there too

[warped kraken]

i am running the latest version: 0.6.8 (i usually restart the server when i see a new release). These devices are part of the ikea matter fabric (dirigera) as well. It might create this problem, so i'll test removing one of these from it to see if it changes things.
edit: removing from other matter fabrics resulted no change in behavior.

[fringe fjord]

Noo all fine ... I could reproduce locally ... still need to understand it but it is clearly an issue of the matter.js server ...

[warped kraken]

Okey, thanks for checking it! 🙂

[fringe fjord]

Was a nice one! ... I think I found it ... Good catch

[valid anvil]

@fringe fjord As you mentioned in the matter-js discord the HA discord would be the better place for discussing the update issue, would that be the right channel now?

[fringe fjord]

for the Matterjs based Beta server exactly this is the place currently.

[valid anvil]

I'ved tried to update a MYGBETT some days (or maybe weeks already) ago and the update is still stuck:

Mai 15 12:03:29 home matter[4939]: 2026-05-15 10:03:29.809 INFO   OtaSoftwar~derServer OTA Update to version 16842755 for Requestor @1:1 (2762fa2ef650d7ffedb3e397eb62dc01d26954e88a3ac0793d>
Mai 15 12:03:29 home matter[4939]: 2026-05-15 10:03:29.810 INFO   SoftwareUp~teManager OTA update BDX cancelled for node @1:1, resetting for retry
Mai 15 12:03:29 home matter[4939]: 2026-05-15 10:03:29.810 INFO   SoftwareUp~teManager BDX transfer still active for node @1:1, skipping announcement
Mai 15 12:03:29 home matter[4939]: 2026-05-15 10:03:29.811 ERROR  BdxProtocol          Error processing BDX transfer: [aborted] Operation aborted
Mai 15 12:03:29 home matter[4939]:     at Function.attempt (/app/node_modules/@matter/general/src/util/Abort.ts:371:17)
Mai 15 12:03:29 home matter[4939]:     at async Function.attempt (/app/node_modules/@matter/general/src/util/Abort.ts:167:16)
[...]
Mai 15 12:07:44 home matter[4939]: 2026-05-15 10:07:44.740 INFO   WebSocketC~erHandler [1] WebSocket connection established

[fringe fjord]

restart the server ... deoending on when exactly it was we also fixed some edge cases in OTA updates that caused such hangs ... but thats really "weeks" ago 🙂
Easier to see if it happens again with current version than otherwise

potentially check changelog between your version and the current to see if thats the case (but could be even when not explicitely mentioned in changelog ... but yeahh which version?

[valid anvil]

now the server get's unexpected messages again after retrying (edit: something was cutoff)

Mai 15 17:04:28 home matter[493522]: 2026-05-15 15:04:28.284 INFO   BdxSession           Starting BDX session exId: 56644 isSender: true isInitiator: false blobName: ota/117c.8007.test.1684
2755
Mai 15 17:04:29 home matter[493522]: 2026-05-15 15:04:29.631 ERROR  ExchangeManager      @1:1•e1f4⇵dd44✉0e7e370a Unhandled error handling incoming message: [flow] Drop received a message fo
r an unexpected protocol. Expected: 2, received: 0
Mai 15 17:04:29 home matter[493522]:   at MessageExchange.onMessageReceived (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:370:19)
Mai 15 17:04:29 home matter[493522]:   at ExchangeManager.#onMessage (/app/node_modules/@matter/protocol/src/protocol/ExchangeManager.ts:310:32)
Mai 15 17:04:29 home matter[493522]:   at <anonymous> (/app/node_modules/@matter/protocol/src/protocol/ExchangeManager.ts:506:40)
Mai 15 17:04:29 home matter[493522]:   at <anonymous> (/app/node_modules/@matter/general/src/net/udp/UdpInterface.ts:46:13)
Mai 15 17:04:29 home matter[493522]:   at Socket.messageListener (/app/node_modules/@matter/nodejs/src/net/NodeJsUdpChannel.ts:226:13)
Mai 15 17:04:29 home matter[493522]:   at Socket.emit (node:events:519:28)
Mai 15 17:04:29 home matter[493522]:   at UDP.onMessage [as onmessage] (node:dgram:991:8)
Mai 15 17:04:29 home matter[493522]: 2026-05-15 15:04:29.695 INFO   ClientEventEmitter   Recei

[fringe fjord]

I need a full log ideally debug level please because unexpected BDX should never happen when we triggered an update ... then we should expect it ... especially after a server restart ... ok, if the log comes time near after restart then the devcie might still think we wwant to manage it but the restart cleared it ... or what you mean?

Please structured information and tell what you did ... I can not read your mind from the distance 😉

[valid anvil]

sure, I'll enable debug logging

Now I restarted the server, enabled the debug logging and triggered the update via the webinterface of the matterjs-server

[fringe fjord]

Ok I see something that I need to look at, but in the end the device is declining the first block with TRANSFER_FAILED_UNKNOWN_ERROR ... So yes the error message shown in the log is misleading and I check that but the device declines it ... why ... no clue

And yes because of that strange error you basically need to wait 10 mins before you can try an update again till the currentl try timed out

[valid anvil]

it times out then, yes:

Mai 15 17:45:37 home matter[494002]: 2026-05-15 15:45:37.809 INFO   SoftwareUp~teManager OTA update BDX cancelled for node @1:1, resetting for retry
Mai 15 17:45:37 home matter[494002]: 2026-05-15 15:45:37.810 INFO   SoftwareUp~teManager BDX transfer still active for node @1:1, skipping announcement
Mai 15 17:45:37 home matter[494002]: 2026-05-15 15:45:37.811 DEBUG  BdxProtocol          BDX session for exchange 56659 closed
Mai 15 17:45:37 home matter[494002]: 2026-05-15 15:45:37.811 ERROR  BdxProtocol          Error processing BDX transfer: [aborted] Operation aborted
Mai 15 17:45:37 home matter[494002]:     at Function.attempt (/app/node_modules/@matter/general/src/util/Abort.ts:371:17)
Mai 15 17:45:37 home matter[494002]:     at async Function.attempt (/app/node_modules/@matter/general/src/util/Abort.ts:167:16)
Mai 15 17:45:37 home matter[494002]:     at async DataReadQueue.read (/app/node_modules/@matter/general/src/util/DataReadQueue.ts:46:20)
Mai 15 17:45:37 home matter[494002]:     at async MessageExchange.#nextMessage (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:684:16)
Mai 15 17:45:37 home matter[494002]:     at async MessageExchange.nextMessage (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:645:20)
Mai 15 17:45:37 home matter[494002]:     at async BdxMessenger.nextMessage (/app/node_modules/@matter/protocol/src/bdx/BdxMessenger.ts:88:25)
Mai 15 17:45:37 home matter[494002]:     at async BdxMessenger.readBlockQuery (/app/node_modules/@matter/protocol/src/bdx/BdxMessenger.ts:182:24)
Mai 15 17:45:37 home matter[494002]:     at async FollowingReceivingFlow.transferNextChunk (/app/node_modules/@matter/protocol/src/bdx/flow/FollowingReceivingFlow.ts:25:28)
Mai 15 17:45:37 home matter[494002]:   Caused by: [peer-unresponsive] Peer is no longer responding to active session (timed out after 5m)

[fringe fjord]

Fix comes in next verison likely monday

But so or so even with the fix you would have no success because device eclined it ...

[valid anvil]

yeah, I think I should powercycle it

[fringe fjord]

maybe also cheange batteries

[valid anvil]

after the timeout it retries to update

Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.352 DEBUG  MessageExchange      New exchange « @1:1•7c98⇵dd57 protocol: 1 peerSess: 7c98 SAT: 1s SAI: 2.5s SII: 17s maxTrans: 5 MRP
Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.353 DEBUG  MessageExchange      Message « for: I/ReportData id: @1:1•7c98⇵dd57✉0acee222 type: 0x1/0x5 reqAck size: 89 payload: 152600fba3690336011535012600e37a50aa370124020024032a240402182402021818183602153501370024010024022a240300182601081a0d00240201260419ffa777350724000124010224020134031818181824ff0b18
Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.368 DEBUG  PairedNode           @1:1 Trigger attribute update for 0.OtaSoftwareUpdateRequestor.2 to 2
Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.368 DEBUG  WebSocketC~erHandler [0] Sending attribute_updated event for Node @1:1 0/42/2 2
Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.368 DEBUG  WebSocketC~erHandler [2] Sending attribute_updated event for Node @1:1 0/42/2 2
Mai 15 17:50:39 home matter[494002]: 2026-05-15 15:50:39.369 INFO   ClientEventEmitter   Received event otaSoftwareUpdateRequestor.stateTransition on server-1-fff1.@1:1 previousState: 1 newState: 2 reason: 1 targetSoftwareVersion: null

which leads again to the unexpected message behavior. And that repeats and repeats so I got the impression it's stuck for weeks

[left rose]

Interesting. that seems to be an IKEA specific behavior to endlessly try to fetch the updates. What happens if you e.g. move the mygbett closer to your border router? Does that change anything?

[valid anvil]

Let's see, I've put the sensor next to the Thread Dongle

[fringe fjord]

maybe better to wait for next version ... because yes the bug you run into kind of keeps the update active partially in the servers loop ... so when devcie then asks we continue ... just to fail again ...

[valid anvil]

The update failed now

Mai 15 21:49:22 home matter[6717]: 2026-05-15 19:49:22.641 INFO   ClientEventEmitter   Received event threadNetworkDiagnostics.networkFaultChange on server-1-fff1.@1:1 current: 1 previous:
Mai 15 21:49:22 home matter[6717]: 2026-05-15 19:49:22.857 INFO   ClientEventEmitter   Received event threadNetworkDiagnostics.connectionStatus on server-1-fff1.@1:1 connectionStatus: 0

Mai 15 21:51:59 home matter[6717]: 2026-05-15 19:51:59.951 INFO   OtaSoftwar~derServer OTA Update to version 16842755 for Requestor @1:1 (effd24a73f6e838ac83486ffa3aa589a53aeba08f93c9cae33a3ab0dc0877b32) is now Cancelled (formerly Downloading)
Mai 15 21:51:59 home matter[6717]: 2026-05-15 19:51:59.952 INFO   SoftwareUp~teManager OTA update BDX cancelled for node @1:1, resetting for retry
Mai 15 21:51:59 home matter[6717]: 2026-05-15 19:51:59.956 INFO   SoftwareUp~teManager BDX transfer still active for node @1:1, skipping announcement
Mai 15 21:52:00 home matter[6717]: 2026-05-15 19:52:00.000 ERROR  BdxProtocol          Error processing BDX transfer: [peer-unresponsive] Peer is no longer responding to active session (timed out after 5m 55s)
Mai 15 21:52:00 home matter[6717]:   at MessageExchange.#sentMessageAckFailure (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:589:29)
Mai 15 21:52:00 home matter[6717]:   at MessageExchange.#retransmitMessage (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:735:22)
Mai 15 21:52:00 home matter[6717]:   at StandardTimer.callback (/app/node_modules/@matter/protocol/src/protocol/MessageExchange.ts:726:36)
Mai 15 21:52:00 home matter[6717]:   at Timeout.<anonymous> (/app/node_modules/@matter/general/src/time/StandardTime.ts:122:18)
Mai 15 21:52:00 home matter[6717]:   at listOnTimeout (node:internal/timers:585:17)
Mai 15 21:52:00 home matter[6717]:   at process.processTimers (node:internal/timers:521:7)

[fringe fjord]

now you had a thread connection issue as it seems

[valid anvil]

hm, it updated until 12% and seemed to be stuck then, while the sensor was lying next to the thread dongle

and IIRC it can disconnect while updating

seems like net.netfilter.nf_conntrack_udp_timeout_stream got reset after reboot though net.netfilter.nf_conntrack_udp_timeout_stream = 3600 is set in /etc/sysctl.d/99-matter.conf

[fringe fjord]

But there were ikea updates that had 3 reboots during the OT process ... soooo if short after the 12% stuck it restarted and started over then that might be ok

[valid anvil]

It seemed to be starting again and again, but finally made it to 1.1.3 over night 🎉

[fringe fjord]

Cool. Yeah as said and discussed earlier here some updates on ikea restart the device 4 times during the update and always start transfer of firmware again from 0

[fringe fjord]

Reminder: Monday at 7pm CEST we have the next matter community sync. Join to get the latest infos on matter, the OHF matter server and Matter in Home Assistant!

[fringe fjord]

🚩 🚩 OHF Matter Server Beta 0.7.0 was just released.
Changelog at: https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#070-2026-05-18

This version is meant to replace the Python Matter server in some weeks and so the goal here now is to verify anything (again if needed). So please verify that everything works as expected.

IMPORTANT:

1. This release switches the used matter,js storage to the new "wal" storage and is automatically doing a migration on the first 0.7 start, so the first start takes longer (comparable to the initial data migration when starting from the python server). Log will show

Migrating storage "server-2-134b" from "file" to "wal". Be patient, this may take a while...
... so please ... "Be patient" 🙂

The new storage system takes less disk space and should generate much less I/o then the old one BUT you will not immediately see the "less diskspace" because the migration still have the old data in a ".migrations" dir in your Docker data folder. A future App or server version will clean these data up - if you like and all worked you can delete this ".migrations" folder manually in docker, but not really needed.

2. This version has now enabled the strict "certificate verification" (like the Python-server). This means that you need to enable the Test DCL mode in order to commission any device with just test/dev certificates.
   The installed certificates will be seeded from pre-installed certificate lists on installation, when not already existent, and will be updated once a day from the Matter DCL automatically.
   On commissioning we try to check the DCL for Certificate revocations too (Python server did not do that)

Thanks a lot!
(And feel welcomed to join to the Matter sync call tonight at 7pm CEST to get all the details)

[silk plover]

Have a Inovelli VTm35 fans switch with a beta Matter 1.5 Firmware was Matter 1.2 previously. Update moves a bunch of settings parameters exposed in HA around from custom clusters to what they say is compliant Mode select options. After update all of those parameters are listed in the HA device info page twice, though only the new version works. The orphaned Custom parameters are no longer present in the firmware, but they are not listed neither listed in HA unavailable nor is any other indication they are non-functional. So far the only way beta testers have found to remove them from HA is to remove the VTM35 from HA MAtter server then add it back. I only have one of those switches and it was updated a while back so not sure what type of logs I can provide to help find the issue.

Will only be an issue for those with current VTM35 using the older Matter 1.2 firmware in HA.

[fringe fjord]

Yeah I already got that told. I am clearly no friend of these changes because they have a lot of "Not-so-nice" consequences that noone at Inovelli thought about 🙁
And the "usability of such changes via a Firmware update" that you describe is "just one".

Maybe it could be an idea to have kind of a "forced rediscovery" of a node/device in HA which basically do a new entitiy mapping, comparres it and tell whats orphaned? Maybe worth a issue as idea or such? But clearly a topic of the Matter intergation and not the server,

[silk plover]

Ok thanks, that was why I asked before I just fired off an issue, I was unclear if the issue had already been raised and even more unclear where exactly it should raised (Matter Server or Integration) if it had not been.

[fringe fjord]

effectively the integration ges a call with "mode_updated" events whenever there are such changes ...and then new things (e.g. on a bridge) are registered, so this part works.
No clue if this logic should also check "orphaned" things and create reppaid issues to remove them or such ... I think HA has options to make this visible, but logic needs to prepare it

[glacial knoll]

The formula for removing the "orphaned parameters" on Inovelli switches when updated to later software versions is well described on the Inovelli forum and only takes a few seconds to do. Ot does not require deleting the delice from HA. Here is the text that was posted by one of the Inovelli guys:

"Note: The mode select clusters were moved to their own endpoints (20-27) to better conform to the standards. This (temporarily) creates duplicate select devices. Restart Home Assistant and the “old” copies will show up as Not Provided devices (greyed out, dead) entities. Go to entity tabs and filter on Domain = Select, Integration = Matter, Status = Not Provided and you should be able to bulk-select and delete those."

[fringe fjord]

Sure but thought more into the future it makes sense to allow such auto cleanup or at least "flagging" i think ... but as said ... it was no good idea to do what they did ... in my eyes the consequences re worse then the benefits (if you look at more then pure usability in Home Assistant)

[raven harbor]

Two way audio seems working via companion app (iOS) but no image; tested with Aqara G350

[silk plover]

Does not work in this instance. These never display as not provided. The guy who documented that work around is in our small core pre-release beta tester group (we get these initial firmware update before Inovelli post them to their Community forum for a wider audience) agrees.

[fringe fjord]

I also have issues with the G350 and am in contact with Aqara. For me the device is not calling back to the matter sevrer after we send the camera Offer and so the flow is stull if "waiting for device" (if you also see that). If it works you need to see an incoming invoke from the device after wendet the Offer to it.
I still wait for feedback whats up there - with the Chip camera example app it basically works (and as soon as my new webcam arrovs I should also have a image and not a black stream)

[raven harbor]

thanks for the info

the audio is smooth though haha

Snapshots work

[fringe fjord]

yes same for me

[glacial knoll]

What specific clusters?

[glacial knoll]

OK... the LED on/off intensity is a known issue. A user (not Inovelli) added custom clusters for those features a while back. He has already removed them from matter and HA (there are two parts to the feature) for the VTM30 and VTM31 since they have already been upgraded to have the same features implemented by mode select. I will drop him a note to remind him that the custom cluster needs to be removed by the time that the new VTM35 version reaches GA. No idea about the Fan mode. It's possibly a beta issue.

[glacial knoll]

What I did with the VTM31 and VTM30 until the custom cluster was removed was just to disable the "bad" clusters so they did not display in HA. When the HA update turned up I just deleted them as per the recipe above.

[fringe fjord]

The Matter community sync starts in 4 minutes ... see you there https://meet.google.com/uch-rsxw-txh

[strong hazel]

Thanks for the new version.

The storage migration was rather quick for me. I would say in a matter of 2ms everything went through.

Here is my feedback. I noticed that one of my border routers was not showing properly in the thread network or topology, even after restarting my HAOS Matter Server app. What solved the issue is a reboot of my HA instance.

[fringe fjord]

The BRs are discovered via MDNS ... we send a query but they sometimes do not respond ... so tn it just needs a bit time for the data to show up ... But effectively there were no changes on this part of the server between the last and this version

[low otter]

How do you add the camera part of the G350 ? I tried scanning the Matter QR code after updating and it was only the Matter bridge part.

[rigid bone]

Regarding 0.7.0 and the new storage system, some release prior we were able to test the new storage out by setting particular environmental variables which I did. I presume when we start using 0.7.0 we can get rid of these variables now, right? [EDIT] I went ahead and removed the env var and did the upgrade...seemed to work MatterServer Using storage drivers: kv=wal, blob=dir

[raven harbor]

Use Aqara App to upgrade firmware then obtain another QR Code from there

[grizzled burrow]

I have VTM35 with orphaned entities. However, in the "entities" when I use the provided filter, NONE of the Matter entities have ANY "status". That column (with no status filters) is all hypens.

[vague yarrow]

I am trying to add a matter device to my HAOS with a ZBT-2 is connected via USB. The device says I need a thread border hub. OTBR is installed. Is there something I need to configure on Matter side?

[fringe fjord]

You first need to add to aqara app. Then install latest update and then the camera will show up. This update is only available when added in aqara app. The deliver firmware had no camera

[fringe fjord]

Yes exactly. I posted this in the thread here where we discussed the storage. 😉

[fringe fjord]

I assume you pair with Apple or Google and the companion app right?! Which of it?

[vague yarrow]

Not pairing with Google and not pairing with apple. Strictly HA

[fringe fjord]

Have a screenshot of that message about „you need a border router“?

[low otter]

I thought about that but no update yet. Maybe a region thing ? I’m in Europe.

I tried the code in the app, and it was the bridge as well. Really weird.

[fringe fjord]

You need to add to aqara app using The Aqara QR code. Not the matter code!!!

[low otter]

That’s what I did. 😅

I have the camera in the Aqara app already, from the start. I was waiting to try the Matter part of it.

[fringe fjord]

Ok i have same. But the camera is only visible in the beta matter server web dashboard. There is no home assistant discovery yet.

[low otter]

Oh that’s what I miss ! I thought you could add it directly from HA

[vague yarrow]

Found the piece of documentation that says to sync via troubleshooting.

[fringe fjord]

That’s a next step. See the OHF roadmap

[raven harbor]

It’s only available within the Add-on; HA Core needs more work for the UI/UX part. You can check the prototype in work on GitHub roadmap

[vague yarrow]

At least I am a little further. Now, it just can't see the thread network.

[strong hazel]

It should be under “Open Web UI” and then check under “Thread” in desktop. If you are using a phone, please put it in a landscape mode to see “Thread”. Did you try it as I described?

[vague yarrow]

Okay, I should be more specific. From the matter device app, it doesn't see the hub at all. When I try to add it from HA, it'll try to connect to the thread border router, but fails. I get the following message: something about couldn't connect and make sure your phone is connected to wifi

[strong hazel]

Do you have Matter Server and thread integrations under Devices and Services though they are often shown automatically when OTBR app is set up? Does your OTBR app have the serial port and host port mapped properly in the OTBR app to link to ZBT-2?

[hollow cloak]

@onyx wraith I converted your message into a file since it's above 15 lines :+1:

[manic lichen]

@onyx wraith This is not a general support channel. #1284966540617449515 might be able to help you. And please use the appropriate channels in the future for your support requests. #find-support

[glacial knoll]

I may (repeat may) have found a way to delete the VTM35 redundant clusters without removing the switch from HA and adding it back. I’ve given Inovelli the formula to try at their end. The issue seems to be with HA rather than matter per se since the same issue occurs with the python server.

[vague yarrow]

Resolved.. Had to enable ipv6 on my Unifi Router and move the HA to the same vlan as my android device.

[fringe fjord]

Hm… but honestly all this is written in the basic docs of matter integration and in the os requirements of the matter Server.

[vague yarrow]

Well buried from the docs. It's how I found it.

[fringe fjord]

if you have ideas on how to make that better visible and such please tell ous or make a PR to the docs

[grand kite]

FYI that user was me. When additional devices have proper ModeSelect settings, removing the custom cluster support is trivial. See https://github.com/home-assistant/core/commit/b5d8c1e89338b82c7341773da2a476f6d6599e97

[feral glade]

i've seen online there should be this topology view in the matter server webui when you enable beta mode. i'm not seing that

[grand kite]

you're not in beta mode. Did you restart the server after changing the setting?

[feral glade]

yes i did. twice. it says matter.js/0.17.0-alpha too

[grand kite]

that's definitely the python matter server in your screenshot

[feral glade]

it says matter.js in the screenshot too

it’s very confusing. i definitely toggled beta and watched the log acquire matter.js from npm

[grand kite]

Ya, that's pretty strange.

[feral glade]

i tried a force refresh too

[grand kite]

But that's def the old python UI. What do the last few lines of your log look like right now ?

[feral glade]

i’ve just opened it on my phone and it’s the new frontend

[grand kite]

sounds like a web browser caching issue

[feral glade]

it seems like there was some stale cache despite shift + f5

does the topology button not appear on mobile?

it’s not there

[glacial knoll]

no it does not. Ipad yes. Iphone no. It’s based on the screen width (768px if i remember correctly)

[silk plover]

Actually iPhone is also a yes for the thread dashboard map if you switch your phone and the HA app to landscape mode. Just learned that a few weeks ago.

[feral glade]

🤦i tried that but didn’t collapse the HA sidebar

[silk plover]

After you turn it to landscape tap the three lines in the left uppermost corner of the app to collapse the HA sidebar to icons only and you will have the maps available

[fringe fjord]

Yeahh it currently requires a certain resolution/browser size. If anyone has time to test out reasonable „minimums“ where it makes sense to still show it vs hide it just tell me. I could also remove the minimum limitation … Wdyt?

[deep drift]

Am I wrong, or did the Matter server beta visualization/dashboard use to display the Thread version for each device? I can’t seem to find the data field anymore.

[fringe fjord]

good question ... i check

Ahh .. thread version is only shown for BRs! For devcies I check if we also have it but unsure

i add it

[fringe fjord]

🚩 OHF Beta Matter Server 0.7.1 released just now! https://github.com/matter-js/matterjs-server/blob/main/CHANGELOG.md#071-2026-05-21
The newly added "BLE Proxy" feature can be used later in HA 2026.06 (so the plan), so thats mainly preparation here. But additionally we also now show the devices Thread versions in the visu

[grizzled burrow]

Not sure if this is a Matter server issue, or an Aqara firmware reporting issue. But I have the Aqara G350 camera on my 5 GHz WPA-3 ONLY network. However, here security is listed as WPA2 personal.

[fringe fjord]

the data come from the wifi diagnostics cluster ... check there, when thats also wrong there then the devce reports it wrong

[strong hazel]

Thanks a lot for this update.

Just noticed that there is no longer need to change the phone orientation to see and access the thread topology.

[fringe fjord]

Yeah unjust thought I should change that …. People will see if it makes sense and if too small they likely do not use it.

[strong hazel]

I like it a lot the way it is now. It requires no effort or thought

[rigid bone]

I have a few devices that don't provide the Thread version number. Is that because its not being made available in the Thread diag cluster?

[fringe fjord]

Do they show „unknown“? Then they provide likely 0. device specific data yes.

Are still some of you having issues with Apple thread networks and these „device reconnect issues after roughly 6h or such? (Or also reconnection storms either Apple BRs)? I got some attention from some guys and they would love to see a sysdiagnose from each tvOS device. Ideally with the debug profile installed.

https://developer.apple.com/services-account/download?path=/iOS/tvOS_Logs/Home_Network_Diagnostics_Logging_Instructions.pdf
https://developer.apple.com/services-account/download?path=/iOS/tvOS_Logs/HomePod_Intercom_Logging_Instructions.pdf

so please do this and grab the logs and report them as a feedback thing to them. Please then send me the details of the report and the feedback id as DM and I can give it to them. Thanks.

[rare creek]

Man.. it took me a hot minute to figure out why I couldn't join thread devices to home assistant. You have to load the credentials using the companion app and it's buried under the troubleshooting section. There has to be a better way to do/check this

[grizzled burrow]

On iOS it's in the Thread settings page.

[rare creek]

For android that let's you make a thread network and set it as default but doesn't load the credentials onto your phone

[grizzled burrow]

Ah on iOS from that page you can do both: "send credentials to phone" or "Send credentials to Home Assistant"

[rare creek]

It looks like it should but it doesn't

[raven harbor]

@fringe fjord hi, I noticed that Matter Server Beta would keep trying updating and get stuck in the restart loop without WAN access. Is there a way to bypass the update and boot with the installed version?

[fringe fjord]

While I agree there is potential this is no topic of the new server. Thee is Aldo already a rosdmap item for that. So ideally provide feedback there.

[fringe fjord]

That’s the „how beta installs from npm“ and more a app/addon topic. I plan to adjust that when doing the final 9.0 version where we also officially switch to the new server. So known and adjustments planned.

[raven harbor]

Thanks 🙏 it would be more friendly for fully local setups.

[fringe fjord]

I agree. In fact when we switch to „only matter.js“ then failing installing the beta should mean we fallback to the stable version without internet. I guess same is with python today.

[rare creek]

My bad I didn't realize this was a different matter server

[strong hazel]

@fringe fjord, I am having issues adding ESP32C6 router flashed with matter over thread via ESP Launchpad. Previously, I was able to commission 4 of the same ESP32C6 to my Matter Server Beta. What happened now?

The above screenshot seems to say it is not found in a trust store. I was able to add it to my Apple Home Matter and thread network but failed in HA Matter server

Update: I just commissioned it after turning on “Enable test-net DCL usage” under HAOS Matter Server app configuration. Those who do not know that that setting exists may not be able to add such devices. I think there is a need to offer users an opportunity to add non-certified devices in a friendly way like Apple Home does. Apple Home warned users and gives an opportunity to add such devices anyway.

[fringe fjord]

The python server should also behave this way. Test/dev devices require the test DCL mode. The beta server missed this check <0.7 and added it in 0.7.0 to behave like the python server.

Please open an issue in the matterjs server repo to Bericht this error message to include a hint to that fact.

[fringe fjord]

Yes and Apple told you that it is a uncertified device. HA is a bit more strict here and requires upfront config with this test flag

[strong hazel]

Well, now HA wants to be more approachable. There is a need to reconsider how strict HA wants to be in that regard considering that one of HA principles is choice. I guess an option to make it more user-friendly like Apple Home could be a UI thing not what you are working on now. Hope front end teams could pick it up and do something about it in the future.

[fringe fjord]

Yes this is true. Please check https://github.com/OpenHomeFoundation/roadmap/issues/91 and add your thoughts there

[chrome oxide]

Hi Apollon, thanks for all the hard work and time you investigated into Matter.js. I have a feature request.

Why doesn't the Thread Mesh window automatically resize to fit the browser window size? It seems to be locked at a fixed size of 800x600 or 1024x768. Is it possible to change this behavior?

Look at the srceenshot. So much space is not used.

Thanks Hoppel

I also have a question. I have 7 Apple Thread Border Routers (2 hardwired AppleTV 4K 3rd Gen, 4 HomePod Minis, 1 HomePod v2). 5 of them are recognized as expected with its name, but 2 are seen as "External Router".

_meshcop._udp. seems to resolve them completely:

I see the following information in the Thread Border Router device panel of the Matter.js Thread Mesh view:

This device appears in Thread neighbor tables but is not commissioned to this fabric. It may be a Thread Border Router whose Thread radio MAC differs from its MeshCoP border-agent ID (common with Apple and Aqara), or a device from another Matter ecosystem.

But Home Assistant also sees them correctly under "Thread".

Why can't Matter.js resolve them correctly, while Home Assistant Thread can?

Another question: What's wrong with those 2 devices? Why aren't they part of my Thread mesh? The Sleepy End Device with the name "Büro Fenster" works as expected.

[fringe fjord]

in fact the XA fields of the annoucements need to match the address ... is that matching? So yes maybe we can see the annoucement but the address is different and so it is nt matched?

[fringe fjord]

no clue whats wrong ... it sees that for whatever reason you have a split network. why ... no clue. But it seems that no other node sees this BR and the BR is only connected to that . try to restart the devcie (battery out and in) and check what happens, sometimes also battery devices have stale entries

In fact alkl this is no eact science here ... there can be a lot of effect and several I can not tell you why still is as it is

[feral glade]

please tell me that the add-on pins the package version

or has at least a minimum release time

with all these npm supply chain attacks, an addon that has access to my whole set of home devices auto-updating from npm is very bad

[chrome oxide]

Yes, thats right. The extended address doesn't match. Restarting the respective HomePods doesn't help.

@all Does it help to reset the HomePods to factory defaults?

[chrome oxide]

Doesn't a network split mean that the devices behind a split network TBR have to be in a separate ip segment? I am unsure about that fact, but thats not the case. However... I removed the battery, waited until the device got unavailable in Home Assistant and reinserted the battery. After that the sleepy end device reconnected to another TBR, but lost its node label which I assigned yesterday.

[warped kraken]

It looks just like my aqara p2 door sensor. Go to endpoint 0, and check if the device implements the ThreadNetworkDiagnostics cluster. Apparently there are some who do not, even while reporting matter 1.4.1 or higher.

[fringe fjord]

When we release the official version soon the official app version will be pinned on build time. The beta is from the idea „the latest released version“. Matter.js and the matter server by default tractor not use many dependencies and we also monitor such attacks. So far we were never affected.

[fringe fjord]

Yes some devices have a bug and do not persists the node label across restarts.

[fringe fjord]

The tread BRs manage that up access topic themselves. But I guess in same network you could construct strange things with a split thread network with same IP ranges. ….

[wide charm]

Is there a way to sync home assistant device names to the new matter server?

[fringe fjord]

Currently only manually. Planned for later

[glacial knoll]

I see the same issue with an Aquara Motion detector... it has no ThreadNetworkDiagnostics cluster and appears as an isolated node on the matter visualization. AFAIK the ThreadNetworkDiagnostics cluster has been in the Matter spec since the beginning so I assume t is something that Aquara just decided not to implement. Other battery devices that I have such as the Leval bolt do implement the cluster and appear connected to a single "router" node.

[warped kraken]

yeap, eventually i realized aqara actually is overpriced cr*p. Let's not go more into it, just accept the fact that you should avoid aqara if you want to get a thread device.
It does not help, that almost everything in the matter spec is optional.

[glacial knoll]

I take your point... however assuming I'm reading the Matter specification correctly the NeighborTable attribute inside of the ThreadNetworkDiagnostics is a Mandatory element. I checked the Matter 1.3 and 1.5 specs and that has not changed.

[empty gyro]

Hi, before I gather the logs for a bug report: Should the node label persist if the device goes offline for a few minutes? I have a few Ikea devices thag reset their node label to an empty string after temporarily loosing connection.

[fringe fjord]

See some Lines above. When devices do not persist it then it is snug on the device. The matter server can not do too much here. We plan some general optimizations to keep that in sync but that will come later. So for now no bug on the server needed because failure to persist is device side.

[fringe fjord]

Ok I digged deeper and yes the python server was always allowing the official „chip test certificates“ … so yes we will document this as a behavior change and will leave this way for now because so it is more clear. I will enhance the error messages

[junior sedge]

Should probably be possible to allow devices using the test certificates without enabling the test DCL.

(to allow open-source bridges, diy devices, etc. but without disrupting firmware updates for commercial devices)

[fringe fjord]

Yeahh maybe we can allow this when using the dashboard to commission. Using companion app will need some more changes also there so that will fit into a roadmap topic

[chrome oxide]

Ok, I removed the batteries of the devices connected to the 2 external routers, reinserted the batteries and after while the external routers disappeared. But they didn’t come back as ’known‘ TBRs. I see 5 of my 7 TBRs only. Next step is to reset them. Let’s see, if that changes the behavior.

[chrome oxide]

I have some Aqara Matter devices:

• Aqara T2 GU10 LED bulb RGB CCT
• Aqara T2 E27 LED bulb RGB CCT
• Aqara FP300 Presence Multi Sensor

All of them have the ThreadNetworkDiagnostics cluster. Which do device are you talking about?

[chrome oxide]

Ok, so I resetted one of my HomePod Minis to factory defaults and set it up again. One hour later I still do not see the device, also not as an external router. How long do I have to wait until the TBR appears in the Thread Mesh view?

@fringe fjord Can you give us the option to search for node labels instead of extended addresses in the Thread Mesh view?

[silk plover]

My Aqara Door and Window Sensor P2 and Motion and Light Sensor P2 do not have the ThreadNetworkDiagnostics cluster.

[fringe fjord]

Open issue and I can see. Right now address and node id are searchable.

[deep drift]

Shouldn't it be logged with a "WARN" flag if a device times out and becomes unavailable? Used to be that way...
See log entries:
2026-05-28 09:38:10.376 INFO ClientSubscription Subscription 10e99681 to peer @1:39 timed out after 5m 39s
2026-05-28 09:38:10.376 INFO ClientSubscription Replacing subscription to @1:39 due to timeout
2026-05-28 09:38:10.377 INFO ClientInteraction Probe » @1:39•2e95⇵f220
2026-05-28 09:39:15.439 INFO ClientNode server-2-134b.@1:39 is offline
2026-05-28 09:39:15.439 INFO Session @1:39•2e95 Session ended
2026-05-28 09:39:15.440 INFO ClientInteraction Probe « @1:39•2e95⇵f220 0↔5+5 (failed)
2026-05-28 09:39:15.440 INFO ClientSubscription Failed to probe reachability of peer @1:39, resubscribe with new session
2026-05-28 09:39:15.440 INFO IpServiceStatus @1:39 Resolving (no address known)
2026-05-28 09:39:15.440 INFO PeerConnection @1:39•unsecured#93ce085bd54ceff8⇵f221 udp://[fd9e:76d4:11ad:1:4c7:91cf:3200:8f]:5540 Connecting addr #: 1 attempt #: 1 connect time: 0 addr time: 0 thread:15:connect fallback
2026-05-28 09:39:35.502 INFO IpServiceStatus @1:39 Resolving (address is unreachable)
2026-05-28 09:40:00.440 INFO PeerConnection @1:39•unsecured#b0c169bdb7fad7df⇵f222 ip://[fd9e:76d4:11ad:1:4c7:91cf:3200:8f]:5540 Connecting addr #: 2 attempt #: 1 connect time: 45s addr time: 0 thread:15:connect
2026-05-28 09:41:10.377 INFO Controller~ndHandler Node @1:39 offline grace period expired, marking unavailable
2026-05-28 09:41:10.377 INFO WebSocketC~erHandler [0] Node @1:39 availability changed to false

[warped kraken]

ProductName: Aqara Door and Window Sensor P2 <= this one does not have it.
Some products only receive updates from their own hub, instead of the matter dcl... and more issues, let's not get into it as it's offtopic here. Their lights are usually ok, though overpriced.

[fringe fjord]

Hm… if you like it a warm instead info open issue and I think I can change it. But then „becomes available again“ is also warn or info? In fact it is all about the semantic meaning of a loglevel and that’s hard to generalize 😉

[deep drift]

Well, losing a device like this is an unwanted and unintended behavior and imo a warn. Coming back online would be a info. But I see your point.

[fringe fjord]

In fact you have the availability info in HA which reflects the state.
Honestly I never really know nor understand how users expect „warns“ to be. And „error“ is even more special.

So for me personally info is all „handled know behavior“. Warn is extraordinary that does not break things or crash the server but users should look at. „Error“ is then even harder like „unexpected but handled ideally/hopefully“ but something the user should look at in any case.

Matter.js internally also has a notice loglevel which is „above info but below warn“. But old matter server did not so I could not map that. Maybe later.

And with thread and the current issues with offline devices that could recover themselves too - or not - that’s a hard case log log as what.

But Yeahh still also a todo in matter.js to overhaul loglevels

[deep drift]

I agree with your suggested log level classification. It is definitely something the user should look at, notice would also be ok. Though I like the red colored warn level for things I should look at.

The device is a Timmerflotte btw. After weeks of stable behavior (I had recommissioned all of them) they start again to drop out. I hope Ikea will provide us with a Matter 1.4/Thread 1.4 firmware soon. This is a device issue.

[glacial knoll]

If we create another level between INFO and WARNING (say NOTICE) I would say anything that is service effecting (timeouts and probes, no response, availability true/false, OTA messages etc) gets put into that or WARNING. WARNING gets "failures", NOTICE gets recovery from failures plus OTA. Anything that is non-service effecting (switch activation, electricalEnergyMeasurement events etc. etc) stays as INFO messages since that is what they are, Info messages, non service effecting. This approach means that anything that is saying a device has a problem or has recovered from a problem can be easily picked out of the logs. The ideal (for me) is that if you set your log level to the proposed NOTICE level, logs should only be shown when something service effecting (incl. OTA) happens (good or bad). This is in line with network management systems that I've worked with in other lives.

[deep drift]

Sounds good to me!

[fringe fjord]

I will consider this

[silk plover]

Not huge deal but for those of us with multiple border routers (probably mostly Apple home users) would be nice if the thread dashboard map somehow visually denoted, which of them was the primary thread border router. Nothing big, just a different color, bold text something along those lines. That way we could quickly discern which TBR to restart or not restart based on what we’re looking to do.

[warped kraken]

Hello!
For thread comissioning with a ble proxy, does one need to set up the thread credentials manually in the matter servers config interface, or can it automatically get it from the homeassistant thread integration ?

[strong hazel]

Thanks for the post. I agree with you totally. I was planning to say the same. Cheers!

[fringe fjord]

Hm … no clue how to determine that tbh. And also not sure if there really is such a thing as a „primary“ one really

[fringe fjord]

When you start a commissioning via the matter server dashboard it will ask you for credentials. So yes

[silk plover]

Your thread mesh dashboard currently uses that terminology now. Under Thread Network: state, when I select a thread border router from the thread mesh graph all are listed as secondary except the one thread leader which is listed as primary.

[fringe fjord]

Yeah when the announcement has the infos. I can maybe also add to the icon somehow.