Using matter.js to build a Node-RED based Matter Bridge

[sercancetin]

Hello Matter JS Team,

I hope you are doing well.

We are considering matter.js for a commercial product and would like to ask a very direct question.

Our idea is to build a Matter Bridge where:

The bridge logic is implemented using matter.js

The integration and automation layer is Node-RED

Node-RED is used to map external systems (e.g. KNX / Modbus / others) to Matter endpoints

In short:

Node-RED + matter.js = Matter Bridge

From your perspective:

Is this a reasonable and supported architecture?

Are there any known certification concerns or limitations when matter.js is used inside a Node-RED–based bridge?

Would you recommend this approach, or strongly suggest separating Matter logic into a standalone service instead of embedding it in Node-RED?

We understand that matter.js itself is not certified and that certification applies to the final product, but we would like to know your technical and practical opinion on this setup.

Thank you for your time and for the great work on matter.js.

[Apollon77]

Hey @sercancetin, I converted into a discussion because it is rather not an "issue" :-)

Technically all this works, and there is already an node-red project out there (https://github.com/sammachin/node-red-matter-bridge), so in fact yes that works.

If and how you will get this certified is a very good question because I really see the challenges here. From my perspective the certification ensures that the matter device works as expected by the specification. This also includes that e.g. a light when it dims reports back it's start or a window covering that moves does that, or that a configuration you set has the relevant results.
All this behind "free-to-pluged-in-logic" via nodes might make a certification result potentially questionable because it maybe can not be expected that "one installation of the bridge" reacts "like another installation". You understand what I mean?

So likely what not work is to certify this as a matter product.
What could work is to certify such a "solution" as a "Matter Software component" to be used by CSA members to then build own matter certifiable "end user solutions" by limiting the testcases that need to be executed by them for certification to the "own implemented/plugged in logic".

But in any case this all is just my personal opinion and you should get in contact with the matter certification team to discuss this in detail. They will know more exact what's possible and how and what not.
We are also here to support you in such a process or during implementation.

[sercancetin]

Hi @Apollon77,
Thank you for the clear explanation — that helps a lot.

Our main goal is actually very focused:

• To act as a protocol bridge between KNX and Matter
• Convert KNX devices → Matter endpoints and Matter commands → KNX
• Node-RED is mainly used as the mapping/orchestration layer between the two worlds

We are not aiming for free end-user programmable Matter behavior.

Our intention would be:

• Define a fixed set of Matter device templates (clusters, attributes, reporting behavior)
• Enforce these templates strictly in the bridge
• Allow Node-RED only to:
  • map KNX datapoints to predefined Matter attributes
  • forward commands/events
• No runtime change of clusters, device types, or reporting semantics

From your perspective:

• If Matter clusters and behavior are strictly predefined and not changeable, would this address the main certification concern you mentioned?
• Or would the presence of Node-RED still make this unsuitable for certification as a Matter product?

Thanks again for your guidance

[sercancetin]

@Apollon77 Could you please help when you have a chance? It's important to us. Have a good day.

[Apollon77]

If Matter clusters and behavior are strictly predefined and not changeable, would this address the main certification concern you mentioned?

I guess you basically "need" exactly that. From my knowledge a certification is always done with concretely defined "device types and their clusters including featuresets". So you need to test and certify basically each device type with each allowed combination of clusters/features when you want to certify a "debug/bridge". So there is no room for flexibility when you want to be certifiable as a bridge from what I know.

My problem is that it is still a "configurable" system in some sort unless you really allow "i have a hard defined KNX "node" X and I map this to Matter "node" Y and so you exactly know what happens when and such. As soon as you give users options to just map datapoints and they might just do nothing when they do it wrong, then that might be an issue.

Additionally a big part of Matter is exactly about "how command work and need to work", so it goes a bit beyond "pure datapoint mapping". Sure for some simple device types this works or the matter.js default implementation can hide enough details away that this works but there might be device types where this is more complex. And it might still require certain behavior like "report back window-covering movements positions during move" which then needs to be ensured by the KNX nodes otherwise ensured.

Or would the presence of Node-RED still make this unsuitable for certification as a Matter product?

When it limits the options to do exactly the certified ones then I guess not, but in such a case that's even more a question for the CSA certification team.

[sercancetin]

Thank you very much for your interest. Have a nice day.