Hello everyone, I would need your help with the integration of a Matter bulb.
IKEA bulb:
First scan:
Second scan:
Again? OK, one more try:
You notice that Gladys detects the bulb at some point and even seems to have added it, but it doesnât appear among the devices?
This is strange, unfortunately I donât know a solution yet.
So far, I have always been able to add all Matter devices this way. The distance between the bulb and the hub is about 5 meters. Wi-Fi is working. All other devices are working.
Here is the corresponding Docker log excerpt:
âŠ
I would be grateful if someone had an idea to solve this problem. Thanks in advance for your attention and support. Best regards, Tom
Hi everyone!
This topic is now in development .
A PR has been opened to fix the Matter pairing error « Node ID X is already commissioned » (update of matter.js to 0.17.9):
master â claude/confident-hypatia-wpt1ah
ouvert 02:39PM - 21 Sep 26 UTC
### Description
Pairing a new Matter device could fail with:
```
matter.pairDe⊠vice.js:50 Error commissioning device: Error: Node ID 1 is already commissioned and can not be reused
```
and, on the next attempt, `Node ID 2 ...`, `Node ID 3 ...` â one node ID burned per attempt, on a controller that already has nodes 1â16.
**Root cause (matter.js 0.17.6, the version pinned by the service lockfile):** when allocating the next sequential node ID for a commissioning, `ControllerBehavior.allocatePeerAddress()` checks collisions through `IdentityService.peerAddressInUse()`, which in 0.17.6 only knew about addresses reserved at runtime (`peers.added` events). Nodes already commissioned by the controller were not taken into account, so as soon as the persisted `nextNodeId` counter was behind the existing nodes, the allocator handed out an ID that `ControllerCommissioner` then rejected against the `PeerSet` with `NodeIdConflictError`.
**Fix:** matter.js 0.17.7 ships *"Fix: Consider existing node IDs when determining the next node ID to commission"* â `peerAddressInUse()` now also consults the `PeerSet`:
```diff
peerAddressInUse(address) {
- return this.#reservedPeerAddresses.has(PeerAddress(address));
+ address = PeerAddress(address);
+ return this.#reservedPeerAddresses.has(address) || !!this.#node.env.maybeGet(PeerSet)?.has(address);
}
```
0.17.8 / 0.17.9 additionally bring fixes for unreachable peers and subscription re-establishment.
`server/services/matter/package.json` already declared `^0.17.6`, but the service lockfile pinned 0.17.6 and `cli/install_service_dependencies.js` runs `npm install`, which keeps a lockfile that satisfies the range â so nobody ever got the upstream fix. This PR bumps the service dependencies (`@matter/main`, `@project-chip/matter.js`) and the server devDependency (`@matter/main`) to `^0.17.9` and refreshes both lockfiles. Lockfile changes are limited to the `@matter/*` packages and their `@noble/hashes` dependency. No Gladys code change.
Verification done locally:
- `npm run test-service --service=matter`: 302 passing
- smoke-loaded the real 0.17.9 modules used by the service (`@matter/main`, `@matter/main/types`, `@matter/main/clusters`, `@project-chip/matter.js`) and confirmed the installed `IdentityService.peerAddressInUse()` carries the upstream fix
- `prettier --check` on the four changed manifest files
### Related request
Forum: https://community.gladysassistant.com/t/matter-over-thread-decouvert-mais-non-accepte/10881
### Checklist
- [x] If a forum topic or GitHub issue exists, the description links it (`Forum: https://community.gladysassistant.com/t/...` or `Closes #...`)
- [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed â dependency-only change, no JS lines touched; the Matter service suite (302 tests) passes locally
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
đ€ Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01ThmubNV1qfGSC65L5cD3qc
---
_Generated by [Claude Code](https://claude.ai/code/session_01ThmubNV1qfGSC65L5cD3qc)_
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.
Hi Tom,
Thanks for the logs, they are very informative! The key message is this one:
Error commissioning device: Error: Node ID 1 is already commissioned and can not be reused
then Node ID 2 ... in the next attempt. So itâs neither your lamp, nor the Wi-Fi, nor the Dirigera: the pairing itself is working fine (we can see that Gladys is talking to the bulb), itâs the Matter library used by Gladys (matter.js 0.17.6) that assigns the new bulb a node number already taken by one of your existing devices. You have 16 nodes (your devices + the Dirigera), and the internal counter has restarted from 1: each attempt « burns » a number, fails, and retries with the next one. This is a bug in matter.js, fixed upstream in version 0.17.7.
I have prepared the fix on the Gladys side (update of matter.js to 0.17.9): #3122 .
It will be in the next release.
@ruegerth The fix is live in Gladys Assistant 5.1.0
Wow, wow, wow⊠Thank you so much, really, for this ultra-fast response and for your help⊠I was already on the verge of despair. Iâll test it tomorrow and keep you posted.
Already tested, Gladys version 5.1.0:
Itâs so fast that you donât even have time to « look »⊠Everything is settled in a few seconds.
Excellent work, thank you so much for your help
ladys | 2026-09-22T00:15:24+0200 matter.handleNode.js:138 (MatterHandler.handleNode) Matter: Node 13 handled, 1 device(s) with features (connected)@1 :8 udp://[fd1a:9a82:f69e:1:6e6a:3dcd:5d61:badd]:5540 Peer error (retry in 5m): [channel-status-response] (Failure (1) / NoSharedTrustRoots (1)) Received general error status for protocol 0 (Sigma2(Resume))
