Incorporating Matter

Hello openHAB community,

I am currently a student exploring Matter (formerly known as connectedhomeip or CHIP) and trying to figure out a way to communicate with it via code (Java).

I thought it might be a good idea to ask a few questions regarding this topic in this community.

  • Is there currently work being done by openHAB to incorporate Matter?

  • If not are there plans to do so?

  • What would be the point of entry to the Matter system?

Using the Chip Controller or its API seems like a good idea.
However the Chip Controller is written in Python and therefor I am thinking about whether it makes sense to talk to it via Java. Does anybody maybe have a good idea on how to connect these two?
Would somebody consider using the API and write a Controller in Java (or a different programming language) from scratch or would this be assumed to much effort?

Or would the openHAB community consider the integration of Matter as too early, either due to missing products/interest or because of the current state of Matter (not being advanced enough)?

Thanks a lot in advance!

Link to Matter repo:

Link to Controller API:

I’m not a developer, but my sense is that it’s too early. I’m pretty confident that someone will want to work on Matter integration down the line, but likely not until it’s released and there are devices we can test and use.

Not that I’m aware of but the best way to find out is to look at the open issues and the WIP pull requests on the openhab-addons repo.

openHAB is an all volunteer project. Plans don’t mean much unless someone has volunteered to do it. Volunteering to create an add-on is usually done by opening an issue or WIP pull request (preferably both). Though it’s also possible to just go and code it on your own. We now have a marketplace that makes discovery and installation of such third party add-ons easier for end users.

The answer to that will probably be answered based on the devices that support it first. In this community the Thread based protocol (as opposed to WiFi and BT) would be the most attractive. But with Google Home Hubs and eero and others coming out with support, it might make sense to integrate with one of those instead. I think there are a lot of unanswered questions about how it’s all going to work with hubs and such.

The absolutely most flexible approach, if using the Python code, is to add support for MQTT to the Python code. If possible, using the Home Assistant or even better the Homie MQTT standard would be even better. Then anything that can speak MQTT, which is pretty much everything in the open source home automation world will be able to interact withe Matter.

Beyond that, if you want to create an add-on you’ll probably have to port the code to Java.

If you just want raw interaction, maybe it’s possible to have openHAB call Chip Controller using the Exec binding and executeCommandLine.

As I said, it’s all volunteer effort. But typically no one will volunteer unless they have:

  • possession of hardware that works with the technology
  • time
  • ability to program

That first one will probably be the limiting factor for OH right now. People tend to only volunteer their time when they personally have a need for it. Since there really are no devices, there is no one who has a need for it yet.

I’ve no doubt that it will happen eventually though. Just not yet.

1 Like

Hello Rick,

thanks a lot for your very elaborate answear. It surely gave me a great deal of information.

My goal is not to be informed when Matter will be supported by openHAB but rather what would be the best way to approach the connection to Matter as a general issue.

Porting the code to Java was my first approach but porting the whole Python Chip Controller seems like a big deal for someone who is more of a junior developer.

The MQTT approach though is something i have not thought about and I will certainly investigate it as a possibility.

Also as a side note: Why would you consider the integration of Thread based devices (as opposed to Wifi or BLE) to have a different approach in general since Matter is application layer? Thread is transport layer so it will not matter whether you have a Wifi or Thread device, or am I missing something out? At least as long as the Chip Controller supports it.

Because OH doesn’t just work at the application layer. It also has to work with hardware. Full integration of OH with Matter means OH is a hub. That means that OH has access to and interacts directly with the antennas that provide the physical medium Matter operates on top of. For example, in order for OH to be a Zwave/Zigbee hub, it has to communicate with a Controller/Coordinator over a serial connection to cause that device to transmit and receive the messages and control the mesh network they are build upon.

If the Chip controller handles all that though, then it is probably invisible to OH. It wasn’t clear whether you are looking to integrate with something special built for OH or trying to make OH work with Matter using commodity BT, WiFi, and Zigbee/Thread hardware.

1 Like

At the moment, you can read a lot in the press about Matter. If I understand correctly, then in the future actually only a HUB (have just ordered the Aqara M2) will be necessary with full integration into the various operating systems such as iOS and Android. With every socket that refuses to work, I’ll replace it with a new one based on Matter in the future. The question arises whether openHAB is thus actually only an interface to obsolete hardware and protocols that are no longer supported by Matter. The question then is what future openHAB will then still have at this point. How do you see this?

Hi Frankie,

It depends on the amount of devices and features everyone has integrated in his smarthome.
I see it from the architectural standpoint like this:

devices->hub
Right now there’s devices that can talk directly to each other. That works for a very limited set of devices and features. So if you want more features or devices you need a hub.

hubs->openhab
When your smarthome grows you’ll probably find yourself having multiple hubs of different vendors and protocols which refuse to talk to each other. Right now there is no “commercial” interoperability product. This void is filled by opensource projects like openhab/homeassistant etc. with plugins to talk to all the hubs. This enables devices->Hub->openhab->Hub->device automation.

Matter promises to be a standard that all vendors support and thus openhab etc. would not be needed anymore. This is a big promise and the future will have to tell if matter actually matters [pun intended]. It has been postponed and worked on for a long time although a lot of big companies are supporting it.

I’m pretty sure there will remain devices that cannot talk matter. Maybe not for you, especially if you’re able to and willing to pay for replacement devices.
But most probably for some time, most of us will still need something like openhab that fills the interoperability gap.

3 Likes

For me it’s not just about device interoperability - it’s also about a configurable user interface, ultimate flexibility in configuring automations, and using an open source “hub” which I trust (no third party commercial apps required on my phone for home automation, for example).

I’m sure there’s more reasons, but those are the top three for me right now.

(Oh, and self hosting the remote entry aspects (VPN), so I don’t need to rely on a third party cloud to gain access to my devices when out of the house…)

I understand your points. But my assessment was about the future of openhab and not about the current advantages, which I certainly see. It is not for nothing that I have been using it for many years. For me, it remains a valid scenario that I will only use openhab for old devices and gradually replace them with “matter” compatible ones using one (not several) hubs. The additional benefit is becoming less and less and the effort and loss of time for maintenance and servicing is hardly in proportion. I just spoke to a buddy today who has installed over 150 fibaro in sockets and has been controlling them via openhab for three years on my advice. If it wasn’t so much work to replace them, he’d like to throw it all away. At the latest after he shot up his system with the upgrade to 3.3.0. In the end, it’s the same arguments as when we made the transition to the cloud. Matter and cloud will prevail and openhab will unfortunately die a slow death. It was still a great time.

Matter is purely about connectivity, not sophisticated control on the level of openHAB. So, OH can still have a valuable role in your home if you want deep, rule-based control.

If someone doesn’t want to have advanced/complex automation (and most people don’t), then I agree that they don’t need openHAB. That has nothing to do with Matter, though…it’s already been the case for years. openHAB is a niche system for a very small number of people who want to dive deep into the home-automation rabbit hole.

I only recommend openHAB to people who are looking for a hobby…which means that I’ve never recommended it to any of my family or friends. I point them to TP-Link Kasas.

Matter networks have border routers, not hubs. That’s an important distinction, because there is no hub-like centralized controller. Ideally, homes will have multiple border routers that are all able to pass commands to and from endpoint devices. If one border router is offline, others carry on without it.

When you add a Matter device, you’ll be able to do so with the corresponding app for any of your border routers (Apple, Amazon, Google, IKEA, Nanoleaf, etc.). Once it’s in your Matter mesh network (which will comprise WiFi and Thread radios), other border routers will automatically be able to talk to it, regardless of manufacturer. That’s the big deal here: no closed manufacturer ecosystems and no singular points of failure.

openHAB can still play a valuable role by enabling you to integrate things that aren’t compatible with Matter, and that isn’t just “legacy devices that will eventually be replaced”. For example, I use:

  • Astro to inform rules that are based on time of day
  • Network UPS Tools to get reports from my Raspberry Pi UPSes
  • MQTT to control my octoPrint RPi server and 3D printer
  • IPP to connect to my wireless print server
  • HTTP to send sleep/hibernate commands to my Windows PC

Matter isn’t going to replace any of that.

The question now is how OH will talk to Matter. I’m not a developer, but I’m hoping it’ll just be a binding that enables OH to join a Matter network. When a new Matter device is added, it’ll pop up in the OH Inbox and we’ll make items/rules/sitemaps/pages with it, mad scientists that we are.

2 Likes

I suspect you’ve misunderstood my post - they’re not just current advantages, but also future advantages: Matter itself doesn’t do any of the stuff I mentioned.

1 Like

Does Matter have Boarder Routers or does Thread have them?

Would it be an approach to launch two distinct projects; one for Thread Support (probably without things) and one for Matter. As OP mentioned already, Matter works on WiFi/Eth too as it is based on IPv6.

As a OH-User for probability a decade I’m honestly looking very interested at the Matter-tests of HAss…

And the other direction. OH itself exposes Items as Matter devices to the network.

1 Like

Good clarification. Border routers are really about Thread, but there’s not really any point to a border router that can only talk to Thread devices or WiFi/Ethernet devices. Its job is to integrate both into the mesh network.

https://blog.espressif.com/matter-thread-border-router-in-matter-240838dc4779

There are USB Thread controllers (which are pretty much updated Zigbee controllers), so this should be possible. I have no idea which approach would be better/easier to implement (again, not a developer). Both aspects would be required if we wanted OH to be seen as a border router. Without looking at what HA is doing, I suspect that that’s their goal.

OH exposing devices to Matter is really critical. It’ll eliminate the lag and unreliability of routing commands through cloud services, even if you’re not concerned about security and/or privacy of them.

That’s a huge benefit, IMO. Even more so for existing OH users, which are obviously already running a slew of non-Matter devices.

I don’t see how matter addresses that at all. If it’s a cloud API, it’s a cloud API. All OH exposing it to Matter will do is let something that speaks Matter talk to OH which in turn will talk to the device’s cloud API. It’s not going to magically cut the device off from its own cloud API.

What it might mean though is stuff that doesn’t speak Matter, can show up on and be controllable from a hub that speaks Matter (Alexa, Google Assistant, HomeKit, etc.) opening up different sorts of integrations.

What it might mean though is stuff that doesn’t speak Matter, can show up on and be controllable from a hub that speaks Matter

Exactly. Right now, to control anything attached to OH via the common (and affordable) devices like an Echo, or Nest Hub, you have to go through myopenhab or a private install running in the cloud. That’s – best case – slow. Sometimes it lags a second or two, sometimes its five or ten seconds, and sometimes it just doesn’t work at all.

If OH was exposing its devices via Matter, those commands would not go through the cloud, with all the associated latency. (Although the latency is an order of magnitude worse for OH than other devices – a command to a Kasa device triggers effectively instantly from Google Home, but the command via myopenhab can take many seconds.

Sort of like how, early on, Alexa-based devices could communicate to a certain subset of UPNP-exposed devices directly, with no skills/cloud services needed. They would trigger instantly.

I can’t imagine I’m in the minority when I’m constantly trying to figure out if Google or Alexa just didn’t hear me, or if the connection via myopenhab is being slow, or if its just down again.