I have a Yeelight Cube that supports Matter. When paired directly with Homey, it exposes basic controls such as on/off, brightness, and color. However, the device also supports a clock, dynamic effects, and effect settings through manufacturer-specific commands.
To make these features available in Homey and Flow, I built an app that runs its own Matter controller using matter.js. It works, but requires separate commissioning and additional memory. If other apps take the same approach, each will run its own Matter stack.
I’d love to see Matter driver support in the Homey Apps SDK, similar to homey-zigbeedriver: access to Homey’s built-in controller, endpoints and clusters, attribute reads and subscriptions, and manufacturer-specific commands.
Is an API like this on the roadmap? It would let developers provide more complete device support while sharing Homey’s existing Matter controller.
I can elaborate on this one from Homey’s perspective.
The whole idea behind Matter is to standardize the smart home: manufacturers, platforms and other members of the industry working together on a common standard, so that the same functionality works consistently across ecosystems. That is a mission we very much support at Homey.
Matter does allow manufacturer-specific extensions, including manufacturer-specific clusters, attributes and commands. In that sense, it isn’t fundamentally different from what we’ve seen with standards such as Zigbee.
However, we believe these extensions should be the exception rather than the default.
If every manufacturer implements additional functionality through its own proprietary Matter clusters, we’re effectively recreating one of the problems Matter was designed to solve. Every ecosystem would once again need to create and maintain manufacturer-specific implementations for individual brands and products. A device might technically be a Matter device, while large parts of its functionality only work in ecosystems that have specifically implemented that manufacturer’s extensions.
That’s also why we haven’t exposed an API in the Homey SDK that allows Homey Apps to add support for arbitrary manufacturer-specific Matter implementations.
We would much rather see manufacturers such as Yeelight work together with the Connectivity Standards Alliance and its members to bring useful functionality into the Matter standard. That way, implementing a feature once benefits not only Homey users, but the entire Matter ecosystem.
Of course, if the industry ultimately moves in a different direction and manufacturer-specific Matter extensions become the common way of adding functionality, we’ll have to reconsider our approach as well. But at this stage, we don’t believe moving back towards manufacturer-specific implementations is the right direction for Matter, so we’re not planning to support these custom implementations in the Homey SDK.
Thanks for the detailed explanation! I agree with your position. I’m not a fan of manufacturers adding their own clusters and attributes either. If this becomes common practice, we risk recreating the same interoperability problems we currently have with Zigbee. I would also prefer to see these features become part of the shared standard.
That leaves me with a practical question: would an app that runs its own Matter controller using matter.js to support these features be eligible for publication in the Homey App Store?
You’re essentially free to implement this however you like, though I suspect you’ll quickly run into memory constraints. The bigger question is whether this is the most user-friendly approach. Doesn’t Yeelight also provide an API for these devices?
I’ve already tested the app, and it uses around 75–80 MB of RAM. Unfortunately, Yeelight’s local LAN API doesn’t expose the Cube’s clock and built-in effects, which are precisely the features I wanted to support. That’s why I ended up using Matter.
