This part is related to the matter bridge. That is the part of the binding that allows you to expose OH items as matter devices to other matter controllers. That’s not what you’re looking for. (If you add the matter metadata to an item, then you should see that Running state transition to running at which point you would get the QR code for pairing OH into that other controller.
This means that you want to use the controller side of the binding. You’ve created the controller already, so you can click on that thing and you’ll see a Pair a Matter device action right on the main detail page for the controller thing. This when you then have to move over to your other system (in this case your aqara hub). Somewhere in that interface you should have the chance to produce a pairing code for the device you want to add (don’t know the interface at all, so I can’t help there). Once you have that created that code via the aqara interface, then you have only a few minutes to type that code into the pair action in OH. If you get that code in within that time then you should be able to find your paired matter device in the thing inbox.
Okay, metadata added, running state
Running, QR code visible
So, do I add new devices from Aqara to OH one by one using a pair, or can I also add the hub itself so that new devices from Aqara are automatically detected in OH?
I have now added the Aqara Hub using manual pairing. OH also says that it was successful and that it should be in the inbox, but there is nothing there. In the Aqara app, I can also see that the hub is linked to another Matter system.
The Aqara Hub M3 is at the same time a Matter controller but also a Matter bridge.
So you could use it as a Matter controller to control in your Aqara app any Matter device and you could even control stuff from openHAB using the bridge feature of the openHAB Matter binding.
But you could use it also as a Matter bridge to expose any Aqara devices including non Matter devices to any Matter controller including openHAB server using the controller feature of the openHAB Matter binding.
In both cases, the setup is fully different.
I understand your need is the second case. So you don’t care about the bridge feature of the binding. What you have to do is to pair the Aquara hub with the openHAB binding using its QR code (the QR code of the Aqara hub). A new node thing corresponding to your Aqara hub will be discovered and then multiple endpoints will be also discovered corresponding to your different Aqara devices. It is possible that you have to setup in the Aqara app what devices you would like the hub to expose. At least, this is the case with my Switchbot hub used as Matter bridge, I have to setup in the Switchbot app what to be exposed as Matter.
So, to summarize:
Pair your Aqara hub with the OH server by scanning its QR code and then add the discovered node thing.
Setup, if necessary, in the Aqara app what devices should be exposed as Matter by the Aqara hub
Add the endpoints things discovered by the binding, each of them matching an Aqara device or a particular feature of an Aqara device. For one Aqara devices, you could have several things.
Regarding Matter bridges, I know that @digitaldan tested the Hue bridge, I myself tested the Switchbot hub. I am not sure we already had a feedback with the Aqara Hub M3 used as a Matter bridge. So your experience will be interesting. But if the standard is respected, there should be no wrong surprise.
It would be interesting to have feedbacks for other Matter bridges like for example the Dirigera (Ikea) bridge.
And finally, if your intention was to control only Matter devices in openHAB, of course the Aqara Hub M3 is unnecessary as you can pair any Matter device directly to the openHAB server (Matter fabric).
openHAB do not need an additional Matter controller as it is itself a Matter controller.
But you could need a Thread Border Router in case you want to control Matter devices using Thread to communicate. I am not sure if the Aqara Hub M3 is also a thread border router.
All this, even if obvious for few of us directly involved since already a long time in Matter concepts, is certainly very complicated to understand for a new user.
Thank you for the explanation. Yes, it is relatively confusing if you are not already deeply involved in the subject matter, and Matter is supposed to make smart home life easier.
Yes, the Aqara HubM3 is a Thread Border Router, but it also supports Zigbee and Bluetooth. I want to use it for Thread devices.
I’ll try out the new information first and then report back.
In the Aqara app, I removed the previous testest connection for the HubM3 to start from scratch.
In summary, I performed the following steps.
I enabled IPv6 DHCP for fd00/64 on the router.
I assigned an IPv6 address to the Proxmox host.
I assigned an IPv6 address to the LXC for OH.
I connected the Aqara HubM3 to the LAN (with IPv4) and set it up in the Aqara app.
I added a Matter Controller Thing with Node ID 1 in OH.
Generated a pairing code for the HubM3 in the Aqara app.
In the OH Matter Controller Thing, executed Pair a Matter Device with the previous pairing code under Actions.
Added the new OH Matter Node for the Aqara HubM3 from the OH Inbox.
Were any of these steps unnecessary?
Is it correct that I can now also pair new devices directly via the external Aqara HubM3 using OH, via "
Generate a new pairing code for a Matter device
Generates a new manual and QR pairing code that can be used to pair the Matter device with an external Matter controller"?
Can the firmware update for devices that would receive updates via the Aquar HubM3 also be controlled via OH? So that I no longer need the Aqara update and can delete my account there?
No, firmware updates still require the Aqara app I believe.
Regarding you setup steps, most of them are about container and how to configure network for a container, I am not a specialist in that domain and so I can’t help you.
What is important is that both Matter devices and the Matter controller (OH server) must be on the same local network and IP v6 must be enabled on the OH server.
My OH is also in a proxmox LXC (actually in a docker container in a proxmox LXC) and the only one of your steps that I didn’t do was #1. I just assigned static link-local ipv6’s (fe80) to my pve node and LXC. My isp, I’m fairly certain is still sometime away from full ipv6 support, so enabling it in my router was one level of complexity I didn’t feel the need for at this time. Notably, because I run my OH container with host networking, docker picked up the LXC’s ipv6 just fine and no further config was required there.
Did you also have to enable the OH ipv6 network setting or was that already on for you?
@DrScr3w Does your hub have any devices paired yet? If you are adding the hub as a matter device (which operates as a bridge), after it pairs, any devices it has paired will show up in the inbox, if there is nothing paired, then nothing will be in the inbox (yet). If you add new devices, they will automatically show up in the inbox (or at least they should, stoping and starting the controller thing would ensure that). I don’t think i tested pairing an empty bridge before.
For Thread devices on your Hub, since they are matter devices, then you have more options. If your hub exposes them via its bridge, then they will just show up in the inbox along with any other devices the hub is controlling (matter or not). However, you should be able to generate a pairing code for just that device, in which case openHAB will talk directly to it (through the thread router), and not through the Hub’s matter bridge. Note that you will for sure need IPV6 working for that.
The Aqara SmartLock U200 is connected to the Aqara HubM3 via Thread and was displayed in Aqara as a Matter device. To use the full range of functions, you must also connect the device to Aqara Magic Pair.
In OH, two new Matter Node Things were then displayed to me, unfortunately both as Matter Device: Unknown. They both have different node IDs, one with 20 and one with 21 digits.
The U200 itself is a great device so far; it is very fast, and I would definitely keep it for standalone operation.
What can be done to make it usable in OH, or is it a problem with the manufacturer, since it does not comply with the Matter standard?
What information is actually sensitive in Matter, apart from the pairing code? Can you simply post the node ID here, or should you make it unrecognizable?
I’m not sure at this point, its a little suspicious that it comes up as an unknown device (and 2 of them), locks are definitely supported. It would be really helpful if you could
Stop/Pause your “Controller” thing in the Main UI
Put the matter binding in TRACE logging
Start/Unpause your “Controller” thing in the Main UI
Send me all the logs from from the start of the controller thing
There will be a LOT of logging, but if you could PM me that, i can quickly tell what the device looks like from a matter POV.
This reminds me, i’m going to add some type of matter “debug” action to automate this, i’ll see if i can get that in the next release.
I have the same issue here with Aqara Hub M3 and two Thread matter devices:
running OH 5.0 in a VM
Aqara Hub M3 in the same subnet as OH
can be paired as a Matter bridge with the OH Matter controller
Thing of type “matter:node” is online, Thing properties are displayed in OH correctly
Thread devices are not found when trying to be paired via the OH Matter controller
Searching for Matter devices via Things –> Add (+) –> Matter Binding –> Scan populates Inbox with three Matter devices of type “unknown”
adding them as Things creates three Things with no additional properties or channels, therefore useless
Since I lack any other thread hardware I am unable to figure out if the problem is OH-specific or an issue with the Aqara M3 (that is claimed to act as a Thread border router).
I will also send the logs as requested. Thanks for looking into this!
Those seem to be phantom devices from previous pairing events that may have failed, to clear them, if you add them as things (even though they are not working) you can then use the “Decommission” action on the thing in the MainUI to remove them from the matter fabric, then you can safely delete the thing.
FYI the Aqura Matter bridge does not expose matter devices, only zigbee ones, the bridge is stricktly to enable legacy devices with Matter functionality.
For true matter devices (including thread) paired to the M3, you need to click on the device’s settings in the Aqura app and generate a new matter pairing code, you can use that (there’s a copy button) in the openHAB discovery UI (either a 11 digit code, or a QR based one starting with “MT:” , both work)
Thread devices require that IPV6 route announcements are working and everything is on the same Lan/Vlan (unless you really know what your doing IPV6 wise). Accepting route announcements is not turned on by default in linux, if you can not pair the device after generating a code, this is very likely the issue.
Please let me know your network and hardware configuration and confirm you have followed the README regarding IPV6 (and RA). I also have a M3 for testing can can confirm the Thread router (its just the stock Google OTBR) works fine with openHAB once IPV6 is configured right in the environment.
Thanks a lot for the hints! Both worked like a charm:
Successfully stopped orphaned Matter devices popping up in Inbox when scanning by decommissioning them first
Could add my Matter Thread device paired to the Aqara hub as a Thing in OH by generating a Matter pairing code in the Aqara app for it
However, direct pairing with the Matter binding did not work - device was not found
Scanning for matter devices via Things –> Add (+) –> Matter Binding –> Scan made the device appear, could be added then
My VM runs Debian 13 Trixie and I have a multi-homed network config (systemd-networkd) with the secondary Ethernet port in a dedicated subnet for the IoT stuff (also the Aqara hub is located there). It seems like the IPv6 route announcements worked out of the box since after booting the routing table is automatically updated with fd46… and fd59… routes:
fd46:6bf2:35a5:4c86::/64 dev ens19 proto ra metric 1024 expires 1566sec pref medium
fd59:1bbc:fb55:1::/64 nhid 302148865 via fe80::1ac2:3cff:fe43:2f57 dev ens19 proto ra metric 1024 expires 1566sec pref medium
fe80::/64 dev ens18 proto kernel metric 256 pref medium
fe80::/64 dev ens19 proto kernel metric 1024 pref medium
