Matter Binding

Just a question - have not installed the OH 5.0 MS 3 + Matter Binding so far:

I would like to use the Matter binding as Matter bridge in order to control devices from the Apple Home app. Is this also possible with multiple users with different Apple Id’s? Or - if not - is it possible to share those devices in iOS to other users?

If both is not possible and I would think that this is a quite common use case - are there any plans to facilitate this by generating multiple bridge instances?

(Background information: I tried this with the HomeKit binding and I don’t find any solution. The multiple instances there are meant for distributing a large number of devices to more than one instance of the “bridge” - which does not help for multi-users. iOS does not allow sharing such devices, only possible with a HomePod or Apple TV as a controller.)

An openHAB Matter Bridge exposes openHAB items as Matter devices so that any standard Matter client can add them to its local fabric (matter term for network) to control it. Our bridge does not have a limit of how many fabrics it can be a part of. So you can have multiple Apple Home instances connected to it, as well as other vendors as well at the same time, and they are generally not aware of each other. Since apple creates a Matter fabric (network) per Home instance, you would need separate Apple accounts, which sounds like what you want anyways? My testing has always involved an Apple TV as a hub, i have not tested if you do not have a hub device, but i assume it works as long as the IOS device is on the same IP network/subnet (since i know IOS has matter built into its OS for the last 2 years).

I’m not sure if i’m actually following what you want however.

Yes, it is exactly what I would want. I have no Apple hub, but 4 iPhones within my family that should all be able to control the devices exposed by the Matter bridge. As I said, that was not possible with the HomeKit Add-on. iOS then said that this “device” (i.e. HomeKit Bridge exposed by the HomeKit Add-on) was already coupled to another home. Also sharing of devices is not allowed.

I’m sure this is obvious, but without a Hub, this will only work when the iPhones are inside the home network…only a Apple Hub can proxy to the Apple cloud for remote access for the Home app. This is not a Matter issue as much as a Apple issue (matter is a local protocol, so you of course would need something to expose it to the outside world).

Of course, I know that. The iOS devices directly talk to the Matter bridge, i.e. to openHAB. That’s fine, the only cloud instance I do accept is myopenhab.org.

I discovered I have a Matter device in my inbox.
I am asking myself if it could be my Hue bridge.
Thing is labelled “Matter device: Unknown”. Is the hue bridge discovered with such label?

Could you add a (hopefully simple) device definition for a speaker to the Matter bridge?

The speaker device definition I see in matter.js seems to be pretty much similar as a dimmable light, even more reduced. So maybe it is enough to copy DimmableLightDevice.java and rename and adapt things.

Its likely a phantom device, maybe one that failed to pair the first time? Hue bridges would be named as “Hue Bridge”, and would still required to be paired first before being in the inbox.

If you add it as a thing, you can then use the "Decommission Matter node from fabric
" action on it, this will remove it from the matter controller and then you can safely delete the thing.

The problem is client support, right now Apple/Google/Alexa only support a subset of devices, i don’t think any of them support speakers. So if we add it, nothing right now can use it yet. I’m sure that will change, but it could be a while.

OK, I see. So it’s not that urgent. In the meanwhile, a speaker can be bridged via a dimmable lightbulb.

I discovered it when I setup a new device for my switchbot hub. As expected, an endpoint thing appeared in inbox but at the same time this node thing. I can’t be sure that it appeared at this time but I also know that I didn’t have it in a recent past.
So I am asking myself if this could be a bug.

Hi,

will you please add a power measurement channels for the “OnOffPlugInUnit” device?

I have a matter plug with consumption measurement and (now in home assistant) I evaluate if the washing machine is running or not according to the current consumption.

In openHAB the socket has channels “only” for wifi signal and switch.

Thank you,

If you mean you are connecting to a matter device that exposes both a OnOFF cluster and a Power Measurement cluster, that should be working today. If not, i would need to see the TRACE logging when that device is initiated. We add any clusters we find on a device as channels. It would also be helpful to know what exactly the device is, like make and model

@digitaldan, thanks for the quick response. Trace log is attached. Model is NEO Matter Plug (635). Thanks for your help.

Unfortunately the NEO device made up their own non standard cluster for power management. I have seen workarounds where implementations intercept this and try patching it to make it look like a standard Power Measurement cluster (it also has to patch all the attribute ids for that cluster). Right now we don’t have any hacks to get around non-compliant devices. I have this on my list of todo’s , but its lower right now.

EDIT:
You can see this in the logs, look for a bunch of lines like:

Decode unknown attribute 0x31/0x125d0007 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0001 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0009 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d000a via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d000c via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0011 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0012 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0013 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0021 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0022 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0023 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0024 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0025 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0026 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0027 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0028 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d0029 via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d002a via the AnySchema.
Decode unknown attribute 0x125dfc11/0x125d002b via the AnySchema.

0x125dfc11 is their custom (non standard) cluster for power, and 0x125d0001 through 0x125d002b are the unknown attributes on that cluster. We would need to patch all of those to look like a standard power management cluster to process.

Thanks for the tip. I was looking for how HA handles this and there is “custom clusters” for vendor-specific clusters.

On line 499 is the spec for NEO, see python-matter-server/matter_server/common/custom_clusters.py at main · matter-js/python-matter-server · GitHub.

Hi @digitaldan

Not sure if you remember but you helped me get the “beta” version of the binding working on Openhab 4, installed on a Raspberry Pi built using openhabian along with an Amazon Alexa device as a Thread Border Router with a number or Matter/Thread devices “connected” to the Matter Fabric via the Alexa.

I originally had some issues getting IPv6 working as the Raspberry Pi is connected via an ethernet connection to the network and the Alexa connected via WiFi. We had to update the Pi configuration to accept the IPv6 Route Advertisements. We also needed to update the configuration of dhcpcd as well.

This was all working fine on my dev openhab instance via adding the JAR to the addons folder and then exposing the items to my production openhab instance using the remoteopenhab binding.

I’ve recently “rebuilt” my dev openhab instance using openhabian (5.0.0.M3), installed the relevant bindings (including the integrated Matter binding) and restored the configuration from a backup.

However, it seems that the openhabian build for 5.0.0.M3 is now installing a version of Raspberry Pi OS that is based on Debian Bookworm and has removed dhcpcd as the DHCP client and replaced it with network manager.

This has resulted in the Raspberry Pi not now accepting the IPv6 Route Advertisements despite net.ipv6.conf.eth0.accept_ra being set to 1 and net.ipv6.conf.eth0.accept_ra_rt_info_max_plen being set to 64 and I’m unable to add the Matter/Thread devices via a pairing code. Attempting this results in the following error…

2025-07-10 22:18:18.904 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {“type”:“response”,“message”:{“type”:“resultError”,“id”:“846b081c-2329-4970-bdab-3baafdd85866”,“result”:“undefined”,“error”:“send ENETUNREACH fdda:4358:6f4f:1:68e0:827e:b3fa:23a4:5540”,“errorId”:“network”}}

I have checked on my Macbook and can see the relevant route is there and if I add it as a static route on the Pi using

sudo ip -6 route add fdda:4358:6f4f:1::/64 via fe80::3625:beff:fe29:bda dev eth0

then I can successfully add a Matter/Thread device to Openhab.

All of my Matter/Thread devices are working fine and controllable via Alexa and also added to Apple Home without issue.

Are you aware of this issue?

I’m mindful that the binding documentation specifically mentions the configuration changes required to dhcpcd which, obviously, won’t be present and configurable on a “new” install of openhabian.

I am going to open an issue on the openhabian git repository for this as well.

Thanks

Mark

I’m not up to date on whats happening over at our openhabian repo since i don’t often use it, but if there are changes needed, please open a ticket , thanks!

I just updated to OH 5-M4
No change to apple home
I surmise you did not have time to get this into M4

So, i did look into it, Humidity and Fan servers are actually not part of the Matter Thermostat device type, they support humidity clients, which are not state holding clusters (meant so the thermostat can talk to humidity and fans as inputs to its own logic, like any other client).

There is another part of the matter standard called “aggregators” which allow you to group devices (endpoints), i played around with this but with mixed results, Apple’s UI got really weird, and Alexa just ignored things. Support for this stuff is still maturing. For now they will just have to be separate devices in the Apple/Alexa/Google UIs until i can experiment some more.