Matter Media Playback Cluster

First off, a comment here:

Both types of accessories/devices can be commissioned in the HomeKit ecosystem seamlessly.

Each framework has its documentation: HAP: https://developer.apple.com/documentation/homekit/hmhomemanager CHIP: https://developer.apple.com/documentation/matter

While the frameworks are conceptually similar, I think it's a mistake to think of them as direct equivalents to each other.

The Matter framework is the easier of the two to explain— it's a hardware control framework you use to send commands to Matter accessories. There's a little bit of nuance in that you need to do pairing through the MatterSupport framework, but once you're paired, the behavior of the framework is relatively straightforward.

However, that's not really how HomeKit works. HomeKit works at a much higher level than that and is basically manipulating the "Home Ecosystem" that's built "on top" of HomeKit. So, for example, when you call a "basic" API like HMCharacteristic.writeValue(...), what that actually "does" could be one of at least three different things:

1. The device your app is running on connects to the accessory and writes the characteristic.

2. The device your app is running on sends a request to the current HomeHub, and the HomeHub writes the characteristic.

3. The device your app is running on sends a command to iCloud, the HomeHub receives that command, and the HomeHub then writes the characteristic.

...and which of those three happened is totally invisible to your app.

Finally, the other issue here is that the HomeKit framework also provides limited support for using the Matter framework to send commands to Matter accessories. In other words, instead of writing an ecosystem app that maintains its own pairing, you can connect to the accessory through HomeKit's ecosystem pairing. This forum post describes how that process works, while this one discusses one of its major limitations.

However, for your purposes, I believe the biggest issue is that I think you'd need to send all your commands directly through MTRBaseDevice, instead of being able to use the higher-level MTRClusterMediaPlayback.

Reordering questions a bit for clarity...

Why aren't they listed in HomeKit Accessory Simulator?

So, what the"HomeKit Accessory Simulator” actually does is simulate HAP (HomeKit Accessory Protocol) accessories. Indeed, one of its main uses is allowing HAP accessory developers to see what a given HAP accessory "should" look like, as well as allowing accessory developers to quickly experiment with different service configurations that will look in HomeKit.

I'll also note that the tools haven’t been updated in several years, so there are HAP accessories that it does not support (for example, televisions).

Are Matter Basic Video Players, (Media Playback) supported in HomeKit?

No, at least not directly. Going back to the support link you posted, in terms of the Matter specification:

"The Home app currently supports these types of Matter accessories: air conditioners, bridges, lights, locks, outlets, switches, thermostats, blinds and shades, and sensors (motion, ambient light, contact, temperature, and humidity)."

...that is a list of the cluster configuration HomeKit (and Home.app) support. However, two notes on that point:

1. Matter accessories are made up of collections of clusters and HomeKit will pair with an accessory even when it doesn't support everything it provides. FYI, this is actually very common, as many accessories include things like vendor-specific configurations.

2. I'm honestly not sure what will happen if you try and pair an accessory where HomeKit doesn't support ANY of its configuration, but I suspect HomeKit will pair the accessory but won't really "show it" in the home. That's something you need to try for yourself.

How can I add a Basic Video Player in HomeKit and display its Media Playback controls once I have added the device to HomeKit?

I don't think this is possible. Please file a bug on this and post the bug number back here once it's filed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hello Kevin,

I tried to open and fill in a bug as recommended on the page https://www.apple.com/feedback/home-app (see attached screenshot).

I did not recieve a bug number. Could you please assist and share the correct page I should access to fill in the bug ?

Kind regards,

David.

Hi David you can use the Feedback Assistant app on macOS, or https://feedbackassistant.apple.com to log a trackable bug, which you can assign to your self or your development team (if you are a member of one).

That other link seems to be for anonymous user feedback.

I did not recieve a bug number. Could you please assist and share the correct page I should access to fill in the bug ?

Sorry, I should have included my usual link to Quinn's post on bug filing. That points you to the right page but also includes a good overview of the bug process. But, yes:

Hi David you can use the Feedback Assistant app on macOS, or https://feedbackassistant.apple.com

...either of those work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hello and thank you both,

Kevin and ssmith_c for your assistance. I fortunatelly managed to file in the bug : FB20677188

I am adding it in the discussion for tracking.

Best regards.

David.

Kevin and ssmith_c for your assistance. I fortunately managed to file in the bug: FB20677188

Thank you! Looking over the bug, there was one point I wanted to comment on:

For the Matter "Media Device Basic Video Player Type" Apple Home does support the commissioning (adding the device to the list of accessories displayed in Home App), but no controls are displayed. Not even the mandatory required controls: ... This type of Matter Device, which is part of the standard, should at least expose the mandatory controls and commands.

The idea that Apple (and "general" ecosystem vendors more broadly) should try and support the full range of the Matter specification is, IMHO, one of those ideas which sounds reasonable on the surface but is, in fact, a very bad idea. First off, quoting myself:

"The Matter specification itself is sufficiently broad and complex that, in practice, I'm not sure it will ever really be possible to create a high-quality controller app* that actually supports EVERY possible accessory configuration in the way that actually provides a high-quality user experience. To put that somewhat more bluntly, I think it will always be possible to create an accessory configuration that will make an app like Home.app* look broken/silly/wrong. In practice, that means that accessories that want to "work right" in Home.app will need to conform to its "expectations" about how they should be configured.

*You can write a "generic" Matter control app that "blindly" presents the accessory configuration, but that's a very different user experience than what Home.app provides. As a concrete example of these issues, I'm not sure what Matter's cluster/endpoint limits are, but I'm sure they're MUCH higher than Home.app can "reasonably" display."

You can see this exact dynamic play out in "Basic Video Player" cluster. One of its mandatory clusters is "Keypad Input", proper support of which would require designing some kind of dynamic keyboard interface that could support an arbitrary subset of up to ~100+ key codes. It's certainly possible to build something like that; however, the work is considerable, and it's very difficult to see how you'd build an interface for that actually "looked good". Unfortunately, that's just where the problems start. Having done all that work:

• Support for "obvious" features (for example, "turning up the volume") is still missing.

• It's entirely possible that some of the required work will never actually be used. For example, "Content Launcher" is a mandatory cluster, but it's not clear to me how you'd integrate that into a generic control app in a way that's actually useful.

Keep in mind that this is just one device type among dozens, so the work required for all this adds up very quickly.

In any case, the key point here is that NONE of this is an issue if you're designing an interface for "real" hardware. We have to design that 100-button keyboard because someone MIGHT create that hardware, but you only need to support the buttons your hardware actually uses... and maybe not even then. For example, your hardware may support the "Input" key, but you might choose to do input switching directly through "Target Navigator". Fundamentally, you can build an interface that looks and works right for "your hardware" because you actually know how "your hardware" looks and works.

That last point is the most critical one here. It's not just that the work involved is quite large, it's that the final result is all but guaranteed to be "worse" than a solution that was built around a real product. A big part of what we choose to support in HomeKit is driven by trying to balance the benefit of integrating that accessory into Home.app against the "cost" of providing a user experience that doesn't match the reality of the accessory.

You can actually see this reality in the HAPs native TV support. Our support is focused on input switching and, optionally, volume control. It doesn't provide any support for actually navigating with the TV UI. That's because the goal of the service is to integrate the TV into the HomeKit experience ("turn on the tv and turn off the lights"), not replace the remote (either physical or a 3rd party app) that was actually designed to control the TV.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware