Incorporating Matter

[Jonas88 (Jonas)]

Hello

Finally i bought my first matter device and would like to implement it to OH. Can you give me a hint on where to start? I want to implement a thread based downlight from nanoleaf which is connected to nanoleaf border router. I also have a homepod mini.

Thank you for your effort!

[sihui]

@Jonas88

Can you give me a hint on where to start?

openhab-addons/bundles/org.openhab.binding.matter at matter ·...

Incorporating Matter

Sorry i have missed this thread for so long! I have been casually pursuing a matter strategy for a little while, its probably a good time to share what i’m thinking and how I plan to spend my free time. this is very tl;dr , just warning ya… So around Christmas I took a long weekend and was able to get a pure, non android build of the connectedhome (project chip) java client working, the basis of this can be found at connectedhomeip/examples/java-matter-controller at master · project-chip/conn…

[Jonas88 (Jonas)]

Thank you!
I read the readme carefully and understand the basic concept I think. I already paired the Nanoleaf border router with my HomeKit. In order to add it to openhab I need to generate a new pairing code, but I cannot find a way to do so in the Apple home app. In the Nanoleaf app, there is a button called connect API. I used this code to connect the controller to the Nanoleaf binding, but it doesn’t seem to be the matter pairing code …

I found an article where the process is described. The Nanoleaf device I added to HomeKit does not provide the option to generate a pairing code inside the Home app. Tomorrow, I will try to reset the device and pair it with openhab at first and the home app later.

[Lolodomo]

Here is why Main UI is proposing number temperature for humidity. There is a typo here:

bundles/org.openhab.binding.matter/src/main/java/org/openhab/binding/matter/internal/controller/devices/converter/RelativeHumidityMeasurementConverter.java

Dan, I will push a fix to you that also use QuantityType instead of DecimalType.

[Lolodomo]

Dan, my fix for the humidity channel is pushed to you.

[digitaldan (Dan Cunningham)]

Thanks!

[digitaldan (Dan Cunningham)]

I have a new jar pushed, this contains the humidity fixes, lots of label cleanups, moves the decommission option to a Thing action (and not a config option), fixes Node/Bridge state when saving and bumps us the the latest matter.js nightly.

Release Matter Beta · digitaldan/openhab-addons

[digitaldan (Dan Cunningham)]

@Jonas88

I already paired the Nanoleaf border router with my HomeKit. In order to add it to openhab I need to generate a new pairing code,

So a thread boarder gateway is not a matter device, so it can not be “commissioned”. Apple homekit is exchanging thread credentials so it can use it as a thread router (no matter invloved at this point). We don’t yet support adding thread routers like this yet, but it not a problem right now in your case.

Now that your thread boarder router is useable by Apple, you should be able to add matter devices to that in Apple Home. Once thats done, you generate a pairing code from the Matter device in the apple home UI and use that to pair. You should not have to do anything with the router in the apple home ui.

openHAB will talk directly to the thread boarder router that the device is using at this point, and Apple Home will not be involved anymore. If you remove the router from Apple, openHAB will still be able to talk to it and control any devices that are already paired.

I actually didn’t know that Apple supported 3rd party thread routers like this, thats good to know.

[Pedro_Liberal]

@digitaldan

If you remove the router from Apple, openHAB will still be able to talk to it and control any devices that are already paired.

Ooooh. This is new information. Good information! So as long as we have one service still paired we should be able to keep a matter device off of the internet??

[digitaldan (Dan Cunningham)]

@Pedro_Liberal

So as long as we have one service still paired we should be able to keep a matter device off of the internet??

I’m not sure what you mean here? Matter devices pair with local controllers, which are independent from one another. If you don’t want it part of your google or apple ecosystem, then you can unpair the device from that local hardware (Google home, apple tv, HomePod, etc…) if you have it paired already. Not sure thats new information, we have mentioned that several times here.

[apas_csc (Christian Schäfer)]

@Pedro_Liberal

So as long as we have one service still paired we should be able to keep a matter device off of the internet??

The router in question here is not your internet router but the thread border router. You can unpair it from Apple or Google and still keep the connection with openHAB.

Matter is not dependent on any cloud, so you can switch off your internet connection and still control devices locally.

[Lolodomo]

Dan, I believe a call to updateRootProperties(endpoint) is missing at the beginning of this method:

https://github.com/digitaldan/openhab-addons/blob/matter/bundles/org.openhab.binding.matter/src/main/java/org/openhab/binding/matter/internal/handler/BridgeEndpointHandler.java#L75

In my case, unfortunately, it does not set any thing property as Switchbot is not setting the corresponding data in the BridgedDeviceBasicInformation cluster.

[Lolodomo]

I discovered a bug with discovery results but it could be unrelated to the binding, I am not sure.

I have my things defined in a things file.
I start a new discovery. All things are discovered but they are not marked as ignored. If I look at the content of the discoveryResult JSON, I see “flag” set to “NEW” (and not “IGNORED”). Due to the representation property and because the things are already created, they should be all marked as ignored.

If I stop/start the binding, it does not change anything.

If I remove my things and then later add them again, now all the entries in inbox are properly marked as ignored. In the JSON, “flag” is set to “IGNORED”.

Do I miss something obvious ?
Maybe a bug in core framework ? Or in the binding ? But I see nothing wrong in the binding code related to that.

[Jonas88 (Jonas)]

@digitaldan

Now that your thread boarder router is useable by Apple, you should be able to add matter devices to that in Apple Home. Once thats don

Hello

thanks for your response!
I managed to install the Addon and found the matter downlight in the home-app.
Indeed it is possible to set it into pairing mode there.
I copied and pasted the 11 digit code into oh paper ui (create new thing under the matter bindung) and hit start scanning. Unfortunately i cannot find it.
Do i need to add or create a matter controller in advance?
Thank you

[mjcumming (Michael Cumming)]

If you have a thread device, you will need to make sure your OpenHAB machine is IP6 enabled.

[Jonas88 (Jonas)]

Thank you!
I read that in the docks and after i finished the Readme i forgot …
This is the issue - back to start … I hope i can get it to work (docker on synology nas)

[sihui]

@Jonas88

paper ui

PaperUI does not exist anymore since years already.
If you are not on a recent 4.3.0 Snapshot (4.3.0.M4 will work also), you are out of luck.
The admin UI is now called MainUI.

@Jonas88

Do i need to add or create a matter controller in advance?

Yes, you need to create a controller first.

[Lolodomo]

Concering discovery and ignored entries in inbox, searching the code in core framework, I have the feeling that entries in inbox will be marked as IGNORED only when a thing with the same representation property is added or when its status changes to ONLINE. So not when entries are added in inbox. Strange.

I can confirm the case when new thing is added is apparently working.

But when the thing status is changes to ONLINE, it does not update the entry in inbox and it could be due to the binding.
In MainUI, I can see that my thing has thingTypeUID “matter:node_11359365265881931550”:

UID: matter:node:openhab:hubSwitchbot
label: Hub Switchbot
thingTypeUID: matter:node_11359365265881931550
configuration:
  nodeId: "11359365265881931550"
bridgeUID: matter:controller:openhab

while the entry in inbox is like that:

  "matter:node:openhab:11359365265881931550": {
    "class": "org.openhab.core.config.discovery.internal.DiscoveryResultImpl",
    "value": {
      "bridgeUID": {
        "segments": [
          "matter",
          "controller",
          "openhab"
        ],
        "uid": "matter:controller:openhab"
      },
      "thingUID": {
        "segments": [
          "matter",
          "node",
          "openhab",
          "11359365265881931550"
        ],
        "uid": "matter:node:openhab:11359365265881931550"
      },
      "thingTypeUID": {
        "segments": [
          "matter",
          "node"
        ],
        "uid": ""
      },
      "properties": {
        "nodeId": "11359365265881931550"
      },
      "representationProperty": "nodeId",
      "flag": "NEW",
      "label": "Matter Device: SwitchBot Hub 2",
      "timestamp": "2024-12-07T14:36:02.818759046Z",
      "timeToLive": -1
    }
  },

So with matter:node as thing type vs matter:node_11359365265881931550.
It could explain why it does not work. I will have to confirm by adding logs in core framework.
Here is the line in core framework that filter inbox entries for a particular thing:

bundles/org.openhab.core.config.discovery/src/main/java/org/openhab/core/config/discovery/internal/AutomaticInboxProcessor.java

“matter:node_11359365265881931550” is a thing type created dynamically, correct ?
I find an entry for it in org.openhab.binding.matter.internal.MatterChannelTypeProvider-ThingType.json.
Maybe it does not work well with such dynamic thing types ?

Regarding Bridge Endpoint things, I am asking myself if defining endpointId as representation property is sufficient. Imagine you have two Matter bridges, you could then have several Bridge Endpoint things wtih the same endPointId but a different bridge thing. If they have different thing type UID, that should be OK. To be investigated as it is a case that should really happen for a part of users.

[digitaldan (Dan Cunningham)]

@Lolodomo

Dan, I believe a call to updateRootProperties(endpoint) is missing at the beginning of this method:

Yes, you are correct, i forgot to add that in the bridge, thanks !

[digitaldan (Dan Cunningham)]

@Jonas88

This is the issue - back to start … I hope i can get it to work (docker on synology nas)

Hmm, that could tough, Docker disables ipv6 by default, but since its managed by synsolgy in this case, you’ll have to figure out how to enable that within their configuration management. A quick google on “synology docker ipv6” and the first results are people struggling to get matter working on this setup , so i guess we are not alone there.