Instead of using the MatterSupport framework to commission a device, I'd much rather throw the process over to the Home App if possible. I noticed that if I open my camera app and scan a Matter QR code, that starts the process to commission the device in the Home App. That means the Home App must be able to handle a url scheme with the QR code details. Is this available for developers to deep link into the Home App?
Launching the QR code as a url itself does not work so Apple Home isn't capturing the MT url scheme. Otherwise I can open Apple Home with com.apple.home:// but have no idea what params would need to be passed to that scheme.
if let url = URL(string: "MT:E9.01EEI141RUX5.210") {
UIApplication.shared.open(url) { result in print(result) }
}
Is there something in the documentation I'm missing that allows for this?
Let me start here:
Instead of using the MatterSupport framework to commission a device, I'd much rather throw the process over to the Home App if possible.
Making sure this is clear, the MatterSupport framework is NOT what I'd expect/want most accessory manufacturer to be using. The MatterSupport framework primarily exists to support other general ecosystem vendors that have their own ecosystem platform. The line between "accessory manufacturer" and "general ecosystem vendor" isn't formally defined and there may be technical reasons why you might choose to use MatterSupport instead of going through the HomeKit->Matter link, but even a basic ecosystem implementation is quite complex, not to mention all of the additional complexity a "great" implementation would require (for example, maintaining accessory key security while also sharing keys between your ecosystem app running on other devices).
In any case, if you're an accessory vendor that's simply trying to send matter commands to your own accessory, then you do NOT need to implement the full matter ecosystem "stack", but can actually send matter command through HomeKit's own ecosystem stack. The details of that process are somewhat involved* but take a look at this and then this forum post for the details of what's required.
*Note that this complexity is quite relative. This is still FAR easier than implementing the full matter ecosystem stack.
Note that this process is COMPLETELY independant of the original pairing proces and doesn't require any special "work" from your app. A user could download your accessory app weeks/months/years after they'd paired the accessory through Home.app and your app will immediately be able to communicate with your accessory through matter as soon as the user has granted it HomeKit access.
I noticed that if I open my camera app and scan a Matter QR code, that starts the process to commission the device in the Home App. That means the Home App must be able to handle a url scheme with the QR code details. Is this available for developers to deep link into the Home App?
Yes, though it's through a HomeKit API, not through deep linking.
Is there something in the documentation I'm missing that allows for this?
Yes, though the top level documentation doesn't specifically say "this pairs matter accessories", which is why you may have missed it. The API for this is HMAccessorySetupManager.performAccessorySetup(using:completionHandler:). That API presents the full pairing interface from collecting the pairing data all the way to placing the object into a home. The HMAccessorySetupResult returns the UUID of the newly paired accessory and the home.
You'll notice that the API takes an "HMAccessorySetupRequest" object, which is used to specify the properties of the object you want to pair with. What isn't obvious is that, by design, ALL of those properties are optional- they exist for cases where a developer need/wants to restrict. An "empty" HMAccessorySetupRequest presents the same pairing flow as Home.app, including pairing matter accessories.
Lastly, two quick notes/pointers:
-
Our sample projects are still using the previous HMHome.addAndSetupAccessories(with:completionHandler:) and need to be updated to the new API. However, the difference here is really overall API improvement, not basic capability, as the old API will pair matter accessories just like the new one and the actually UI experience is nearly identical. The main differences between the two APIs are that the new API handles choosing the home (this was always an annoyance with the old API) and the new API is structured better for handling edge cases. Note that this second point is the main reason the new API exists.
-
Our sample projects can be very useful development tools, not just pure examples. Notably, "Interacting with a home automation network" basically lets you see an explore the full service/characteristic hierarchy of your HomeKit accessories, which is incredibly useful when you're trying to understand how the HomeKit API maps to your matter accessory. It also shows you everything visible through the HomeKit API, even characteristic/services which would otherwise not be user visible. This makes it easy to see cases where a mapping is occurring (so that endpoint is "visible" through HomeKit), it just isn't occurring to the "right" type (so Home.app isn't showing it to you).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware