Matter Bridge commissioning with Amazon Echo Hub fails after AddNOC (openHAB 5.2.3)

Add-ons Bindings
1

Hello everyone,

I’m trying to commission the openHAB Matter Bridge with an Amazon Echo Hub, but commissioning consistently fails before completion.

I’d appreciate help understanding whether this is a known issue with openHAB 5.2.3, the bundled Matter.js runtime, or the attestation certificates used by the bridge.

Environment

  • openHAB: 5.2.3

  • Hardware: Raspberry Pi 5

  • Node.js: v22.23.4 (/usr/bin/node)

  • Matter binding bundle: 301, version 5.2.3

  • Controller/commissioner: Amazon Echo Hub

  • Router: ASUS RT-AC86U running Asuswrt-Merlin 386.14_2

  • The openHAB Matter Bridge Thing reports ONLINE.

  • The bridge configuration reports Running State: Running.

  • The Matter Node.js process listens on UDP port 5540.

The bridge is defined in a .things file as a matter:controller Thing with interface="eth0". The devices I want to expose are standard openHAB Switch items, for example:

Switch bs01 "Pool" {
    channel="openwebnet:bus_on_off_switch:mybridge:s01:switch",
    ga="Light",
    matter="OnOffLight"
}

What happens

The Echo Hub discovers the bridge and starts commissioning. The initial PASE handshake succeeds, and the exchange proceeds through regulatory configuration, attestation, CSR generation and operational credential installation.

The relevant log sequence is:

  1. SC/PbkdfParamRequest received from the Echo Hub over IPv6.

  2. PASE session established successfully.

  3. Initial GeneralCommissioning.armFailSafe succeeds.

  4. SetRegulatoryConfig with country code IT succeeds.

  5. CertificateChainRequest is answered.

  6. AttestationRequest succeeds.

  7. CSRRequest succeeds.

  8. AddTrustedRootCertificate succeeds.

  9. AddNOC succeeds and an operational certificate is installed (fabric index 7).

  10. Approximately 20 seconds later, the Echo Hub sends GeneralCommissioning.armFailSafe with expiryLengthSeconds: 0.

  11. openHAB resets the fabric builder, revokes fabric index 7 and closes the session.

The key log lines are:

certificateChainRequest
...
node-matter Dev PAI
...
Matter Test PAA
...
attestationRequest
...
csrRequest
...
addTrustedRootCertificate
...
addNoc
...
expiryLengthSeconds: 0 breadcrumb: 1
FailsafeContext: Failsafe timer expired; resetting fabric builder
FailsafeContext: Revoking fabric index 7

There is no successful CommissioningComplete, and commissioning never reaches a stable operational CASE session.

I also see this earlier in the exchange:

generalCommissioning.0x6
UnsupportedCommand(129)

The Echo Hub continues commissioning after this response, so I don’t know whether it is related to the eventual abort.

What I have already checked

  • Restarted the Matter binding and reproduced the same failure.

  • Confirmed that the bridge is online and the Node.js process is listening on UDP port 5540.

  • Captured network traffic: IPv6 communication between the Echo Hub and openHAB is occurring, and the initial commissioning exchange completes.

  • Tested a temporary ULA IPv6 configuration on the router; the failure remained.

  • The Echo Hub’s commissioning request reaches openHAB, so this does not appear to be a simple discovery or initial-connectivity failure.

Questions

  1. Is the node-matter Dev PAI / Matter Test PAA certificate chain expected for the openHAB 5.2.3 Matter Bridge?

  2. Can Amazon Echo Hub commission a bridge using these development/test attestation certificates, or would that explain why the commissioner aborts after AddNOC?

  3. Is there a known compatibility issue between openHAB 5.2.3 / its bundled Matter.js version and Amazon Echo Hub?

  4. Is UnsupportedCommand(129) for GeneralCommissioning command 0x06 expected, and could it cause the commissioner to cancel commissioning later?

  5. Are there additional Matter.js debug logs or configuration details I should collect to identify why the Echo Hub sends ArmFailSafe with expiryLengthSeconds: 0?

I have not manually reset the bridge or deleted any fabric data. I wanted to identify the cause before making further changes.

Attached the full TRACE log.

Thanks in advance for any suggestions.

log-trace.txt (44.7 KB)