Experiences with matter.js beta of Matter Server 8.2.2

Configuration Matter/Thread
1

I just switched from Python Matter Server to the beta of the matter.js. Interested in other exchanging people’s experiences.

I’m running Home Assistant Greet with Matter Server 8.2.2 add-on. I’ve been using Python Matter Server about a year and it works, but just recently had some memory issue with it crashing. I have about 50 Matter devices. So I’m risking the beta ironically for more stability.

When you first start the add-on with matter.js enabled, it copied all your devices from the old configuration. This takes a long ass time. For my 50 devices, about 10 minutes. You can watch it happening in the add-on logs so you know it’s not just dead. The web UI won’t work until this process is complete. After that everything came online, quite fast actually, and so far it works

The add on is using 500MB of RAM, vs ~100MB for Z2M, that’s progress I guess. Add-on has a cool (if unstable it tends to rotate continuously) graph view for Thread and Wifi, and displays Thread signal strengths, which is a great step forward

Update: I’ve been on the matter.js server for about 2 months and all good. It have been stable and if you restart server or HA, matter.js is way faster to reconnect everything.

1 Like
2

I tried to add a new Matter of Wifi device (a powerboard) but so far it fails. The Matter set up works with the phone, however then the ‘Add to Home Assistant’ stage fails. Each time the log looks like this. Possibly and mDNS issue.

2026-02-22 21:26:42.707 INFO   ConfigStorage        Set config key nextNodeId to 104
2026-02-22 21:26:42.723 INFO   PeerCommissioner     Connecting to device with identifier {"shortDiscriminator":9} and 1 scanners and knownAddress "undefined"
2026-02-22 21:26:42.723 INFO   ControllerDiscovery  Start Discovering devices using identifier {"shortDiscriminator":9} ...
2026-02-22 21:26:42.724 INFO   MdnsClient           Registered waiter for query _S9._sub._matterc._udp.local (268) with timeout 30000

...

2026-02-22 21:27:12.724 INFO   MdnsClient           Finishing waiter for query _S9._sub._matterc._udp.local (268), resolving: true
2026-02-22 21:27:12.725 INFO   ControllerDiscovery  Found 0 devices using identifier {"shortDiscriminator":9}
2026-02-22 21:27:12.726 ERROR  WebSocketC~erHandler [0] Failed to handle websocket request Commission failed: No device discovered using identifier {"shortDiscriminator":9}! Please check that the relevant device is online.
    at Function.nodeCommissionFailed (/opt/matterjs/node_modules/@matter-server/ws-controller/src/types/WebSocketMessageTypes.ts:517:16)
    at ControllerCommandHandler.commissionNode (/opt/matterjs/node_modules/@matter-server/ws-controller/src/controller/ControllerCommandHandler.ts:951:31)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async WebSocketControllerHandler.#handleCommissionWithCode (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:592:28)
    at async WebSocketControllerHandler.#handleWebSocketRequest (/opt/matterjs/node_modules/@matter-server/ws-controller/src/server/WebSocketControllerHandler.ts:384:30)
  Caused by: [commissionable-device-discovery-failed] No device discovered using identifier {"shortDiscriminator":9}! Please check that the relevant device is online.
    at <anonymous> (/opt/matterjs/node_modules/@matter/protocol/src/peer/ControllerDiscovery.ts:65:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
1 Like
3

This error code would suggest that the device has already been added to the Matter fabrics. Are you sure it has not been paired with other hub (Google and/or Apple?)

4

Is it possible the phone was on 5GHz band of WiFi? Or was the phone on a different VLAN/IP-subnet?
The iPhone gives the device the WiFi credentials based on the WiFi the phone is using at the time of commissioning.

5

My personal experience is that I can commission devices with my Android smartphone being connected over 5 GHz. Did this with a couple of Eve devices no later than a few days ago.

6

It will depend on whether or not the device supports the 5GHz band.
My guess is that it is probably not the problem here, as the OP says the “Matter set up works with the phone” which probably means the device joined the WiFi network and the phone is seeing mDNS advertisements from the device…but seems HA Matter Server is not seeing these.

1 Like
7

Correct. I overlooked that the OP was talking about Matter over WiFi. :roll_eyes:

But again: Tapo P110M here can be connected with the Matter Server - can’t tell if they do this on 5 or 2.4G. So I would rather point to the device not being compatible.

8

Sorry but noo this is no error code! This is just the discovery identifier … and the error means what is written there:

No device discovered  ... Please check that the relevant device is online.

So it was not found via MDNS in the network.

When the device is fresh then it can only be paired via BLE, so HA app is the best or add a BLE UST stick to the host and configure the Matter server to use it

9

“this takes a long ass time”…“about 10 minutes”. :wink:

Outside of this; what issues were you having with the Python Matter Server? I have been having lots of thread instability for the last 3-4 weeks (ever since upgrading my Inovelli White Switches to the latest firmware release). I plan to migrate to matter.js as well but waiting for my C5 Lite first as I think part of my problem is the 2GB of memory in my Yellow. The firmware release exposed power utilization for each of my 33 White Switches. Which is amazing; but I think the amount of data is just overwhelming my Yellow Thread; causing it to crash.

10

Also have more than 30 Inovelli white switches and running firmware 1.1.5, which was improvement for me, running great on the matterjs server beta. Much better than the ever did back on 1.0.5 and the Python Matter server.

@Apollon77 has been great with taking logs and help optimize matterjs for those of us with large thread networks.

13

Do you mind me asking what your running for a Thread hub? I’ve been having nothing but issues since upgrading 33 White Switches to 1.1.5 (from 1.0.5) and am running HA Yellow with 2GB memory. I have an upgrade (CM5 with 8GB) on the way hoping it will help fix the issue.

14

HAOS Proxmox VM.

1 Like
15

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.

16

Have you restarted Matter server beta? This is the easiest way to update to the latest beta version. Settings/Apps/Matter Server/Info, then select restart. Some mitigations to address energy reporting have been added over time, but not sure here. After making sure you are on the latest, as of this moment you should see matter-server/0.5.13 (matter.js/0.17.0-alpha.0-20260402-bd064abc8) at the top of the dashboard view, not the app view. @Apollon77 is active on the new Matter Server Discord channel and you are more likely to get knowledgeable responses there: Discord

17

Yes… Thanks, I have restarted matter.js a couple of times this morning as it happens. I will put a post on Discord if I do not get a response here. For now I’ve switched back to the Python server.

18

Anecdotally the Python server was so far behind Matterjs Server, it would be a punishment for me to switch back.

Curious what are you scanning the Matter server logs for with such frequency?

19

Generally I’m looking for connection errors as a sign of something in the Thread/Matter network that may need attention. The existing Python server (once devices are setup and working) only logs errors (plus entries for it’s approx. twice a day check for later versions via OTA).

This makes it very easy to scan for something that might need attention.

I’m happy to filter the matter.js logs however I so far not worked out how to do it.

20

One of the reasons that I’m “still” using the Python matter server is because the matter.js server is still alpha/beta and hence it is going to have problems (pretty much by definition).

I am absolutely sure that the matter.js server will be an improvement over the Python server when it is released but since you can essentially get a new version every time you reboot the matter server there is too much “churn” for me.

Here is an example that I turned up this morning where a device that was not connected (I pulled the power to it) was still shown as available in HA after 15+ mins. I’ve posted this on Discord as well (as you recommended) however this is what I found.

It appears to be that HA Core is not getting a message that it “understands” to mark a device as “Unavailable”. This is an example.

At 10:55 I pulled the power to a switch. The logs (just filtered for that device) were as follows.

2026-04-06 10:50:36.272 INFO   WebSocketC~erHandler [0] Node @1:12 availability changed to true
2026-04-06 10:51:58.368 INFO   ClientInteraction    Invoke » @1:12•ce23⇵11ca 0x1.OnOff:0x6.off:0x0 with (no payload)
2026-04-06 10:51:58.426 INFO   ClientInteraction    Invoke « @1:12•ce23⇵11ca 0x1.OnOff:0x6.off:0x0 status: Success (0)
2026-04-06 10:51:59.796 INFO   ClientInteraction    Invoke » @1:12•ce23⇵11cb 0x1.OnOff:0x6.on:0x1 with (no payload)
2026-04-06 10:51:59.854 INFO   ClientInteraction    Invoke « @1:12•ce23⇵11cb 0x1.OnOff:0x6.on:0x1 status: Success (0)
2026-04-06 10:52:04.503 INFO   ClientEventEmitter   Received event switch.initialPress on server-2-134b.@1:12.ep1.ep4 newPosition: 1
2026-04-06 10:52:05.537 INFO   ClientEventEmitter   Received event switch.shortRelease on server-2-134b.@1:12.ep1.ep4 previousPosition: 1
2026-04-06 10:52:05.549 INFO   ClientEventEmitter   Received event switch.multiPressComplete on server-2-134b.@1:12.ep1.ep4 previousPosition: 0 totalNumberOfPressesCounted: 1
2026-04-06 10:53:03.947 INFO   ClientInteraction    Invoke » @1:12•ce23⇵11cf 0x1.OnOff:0x6.on:0x1 with (no payload)
2026-04-06 10:53:04.007 INFO   ClientInteraction    Invoke « @1:12•ce23⇵11cf 0x1.OnOff:0x6.on:0x1 status: Success (0)
2026-04-06 10:53:53.584 INFO   ClientEventEmitter   Received event switch.initialPress on server-2-134b.@1:12.ep1.ep5 newPosition: 1
2026-04-06 10:53:54.599 INFO   ClientEventEmitter   Received event switch.shortRelease on server-2-134b.@1:12.ep1.ep5 previousPosition: 1
2026-04-06 10:53:54.610 INFO   ClientEventEmitter   Received event switch.multiPressComplete on server-2-134b.@1:12.ep1.ep5 previousPosition: 0 totalNumberOfPressesCounted: 1
2026-04-06 10:56:35.605 INFO   ClientSubscription   Subscription c9e931e2 to peer @1:12 timed out after 1m 40s
2026-04-06 10:56:35.607 ERROR  ClientSubscription   Replacing subscription to @1:12 due to timeout
2026-04-06 10:56:53.476 INFO   ClientInteraction    Read » @1:12•ce23⇵11d1 attributes: 0x0/OperationalCredentials(0x3e)/Fabrics(0x1) fabricFiltered: false
2026-04-06 10:56:53.577 INFO   ClientInteraction    Read » @1:12•ce23⇵11d2 attributes: 0x0/OperationalCredentials(0x3e)/Fabrics(0x1) fabricFiltered: false
2026-04-06 10:57:18.212 INFO   ClientNode           server-2-134b.@1:12 is offline
2026-04-06 10:57:18.214 INFO   Session              @1:12•ce23 Session ended
2026-04-06 10:57:18.216 ERROR  ClientSubscription   Failed to probe reachability of peer @1:12, resubscribe with new session
2026-04-06 10:57:18.216 INFO   IpServiceStatus      @1:12 Resolving (address is unreachable)
2026-04-06 10:57:18.226 INFO   PeerConnection       @1:12•unsecured#1e437612421808c⇵11d3 udp://[fd7f:289c:9914:0:e2f9:911f:fd0f:610b]:5540 Connecting addr #: 1 attempt #: 1 connect time: 10ms addr time: 10ms thread:25:connect

Within a few minutes the Node has been declared “offline” however HA still shows the device as available. I let this run for 15 mins no change, the device is unplugged, matter.js sees it as offline but HA sees it as online.

If we look at the Python server same routine, pull the power and wait we get this:

2026-04-06 11:16:49.503 (Dummy-2) CHIP_ERROR [chip.native.DMG] Subscription Liveness timeout with SubscriptionID = 0xb2fee7ad, Peer = 01:0000000000000012
2026-04-06 11:16:49.508 (MainThread) INFO [matter_server.server.device_controller] <Node:18> Subscription failed with CHIP Error 0x00000032: Timeout, resubscription attempt 0
2026-04-06 11:17:13.558 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:4402i with Node: <0000000000000000, 0> S:0 M:58331174] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2026-04-06 11:17:24.125 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000012, 1>. Current state was 4
2026-04-06 11:17:24.126 (Dummy-2) CHIP_ERROR [chip.native.DMG] Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:594: CHIP Error 0x00000032: Timeout'
2026-04-06 11:17:24.128 (MainThread) INFO [matter_server.server.device_controller] <Node:18> Subscription failed with CHIP Error 0x00000032: Timeout, resubscription attempt 1
2026-04-06 11:17:55.461 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:4403i with Node: <0000000000000000, 0> S:0 M:58331175] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2026-04-06 11:18:06.066 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000012, 1>. Current state was 4
2026-04-06 11:18:06.067 (Dummy-2) CHIP_ERROR [chip.native.DMG] Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:594: CHIP Error 0x00000032: Timeout'
2026-04-06 11:18:06.068 (MainThread) INFO [matter_server.server.device_controller] <Node:18> Subscription failed with CHIP Error 0x00000032: Timeout, resubscription attempt 2
2026-04-06 11:18:06.069 (MainThread) INFO [matter_server.server.device_controller] <Node:18> Marked node as unavailable

As soon as the “Marked node as unavailable” event turns up the device shows as unavailable in HA. My guess (note guess) is that HA is looking for something similar to “Node @1:12 availability changed to false” from matter.js which it never sees and hence the device appears to be still online in the frontend when it is not.

Thoughts appreciated!

21

I hear you, just for my setup Matterjs Server has been more stable and less problematic than the Python version from the start. That failed repeatedly and resulted in much more downtime/offline nodes than anything I have seen from this beta.

Please file an issue in the MatterJS Server GitHub on what you may have found here.

22

I will do so this afternoon