Access to Matter “characteristic” in a HomeKit app?

Hi there,

I am working on a (Mac Catalyst) HomeKit my own private application, which observes different characteristics of different accessories. This works (also thanks to the advice here, thanks again to all who helped!) like a charm.

Now I've found that one of my outlets which is connected through Matter supports power consumption (in Home.app), but there is no characteristic for that, all I can see is its power state. Self-evidently, access to the consumption would be something Matter-specific.

At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow? I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing).

Thanks a lot!

Answered by DTS Engineer in 907330022

At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow?

It is, though you'll need to get your head around the device Matter configuration, which will probably involve some degree of wading through the Matter spec. The problem here is that Matter and HomeKit's accessory architectures are different enough in design and vocabulary that jumping between the two isn't trivial. This is also why HomeKit's support for Matter is tied to specifics instead of providing a more "generic" mapping solution- the specs are sufficiently different that there isn’t a good way to make a generic mapping “engine”.

In any case, this forum post goes through the full details, but the basic overview is that one of MTRDeviceController initializers actually creates a "bridge" into HomeKit's ecosystem controller (instead of creating your own). Once you have that controller, you can use it to create an MTRBaseDevice, which can then be used to communicate with the accessory using Matter.

I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing).

I'm afraid I don't have anything I can share, but please let me know if you have any questions.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Accepted Answer

At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow?

It is, though you'll need to get your head around the device Matter configuration, which will probably involve some degree of wading through the Matter spec. The problem here is that Matter and HomeKit's accessory architectures are different enough in design and vocabulary that jumping between the two isn't trivial. This is also why HomeKit's support for Matter is tied to specifics instead of providing a more "generic" mapping solution- the specs are sufficiently different that there isn’t a good way to make a generic mapping “engine”.

In any case, this forum post goes through the full details, but the basic overview is that one of MTRDeviceController initializers actually creates a "bridge" into HomeKit's ecosystem controller (instead of creating your own). Once you have that controller, you can use it to create an MTRBaseDevice, which can then be used to communicate with the accessory using Matter.

I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing).

I'm afraid I don't have anything I can share, but please let me know if you have any questions.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you very much!

Thank you very much!

You're very welcome, and good luck!

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Well one more question please. I've found meantime I can read e.g., the Power Measurement cluster using

[mybasedevice readAttributesWithEndpointID:nil clusterID:@(0x90)  ...]

Are there symbolic constants which I could use instead of the ugly 0x90? Can't find them anywhere :(

Thanks again!

Are there symbolic constants which I could use instead of the ugly 0x90?

I believe this would be "MTRClusterIDType.electricalPowerMeasurementID".

BTW, just in case you weren't aware, the Matter framework itself is open source, and that project can be useful both for general reference and background context. For example, this check-in describes why MTRBaseClusterElectricalMeasurement was deprecated, and here is the definition of MTRClusterIDTypeElectricalPowerMeasurementID in MTRClusterConstants.h:

 MTRClusterIDTypeValveConfigurationAndControlID MTR_AVAILABLE(ios(17.6), macos(14.6), watchos(10.6), tvos(17.6)) = 0x00000081,
    MTRClusterIDTypeElectricalPowerMeasurementID MTR_AVAILABLE(ios(17.6), macos(14.6), watchos(10.6), tvos(17.6)) = 0x00000090,
    MTRClusterIDTypeElectricalEnergyMeasurementID MTR_AVAILABLE(ios(17.6), macos(14.6), watchos(10.6), tvos(17.6)) = 0x00000091,

...which lets you directly "skim" the ID list when you know the value but you're not sure of the constant declaration. You can also download the full project, so searching is faster and easier. In any case, once you've got the C definition, you can use that to guess/infer and find the right Swift constant.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Aha, I see, and indeed I didn't know the project was OS and available. Thank you very much!

(Sorry for the delay, for a while I had to lay aside the Matter support and focus on other things.)

Thanks a lot for all the support! And if you can bear with one more question relevant to this thread: is there a way to find the particular Matter cluster/attribute IDs which match a HomeKit characteristic?

To better explain the question, I wonder where and how to get values for “???” in this code:

HMCharacteristic *chr=...; // for any reason, I'd like to check the chr.value “mirror” Matter-side

HMService *svc=chr.service;
HMAccessory *acc=svc.accessory;
MTRDeviceController *mtrC=[MTRDeviceController sharedControllerWithID:acc.home.matterControllerID xpcConnectBlock:acc.home.matterControllerXPCConnectBlock];
MTRBaseDevice *mtrD=[MTRBaseDevice deviceWithNodeID:acc.matterNodeID controller:mtrC];

[mtrD readAttributesWithEndpointID:svc.matterEndpointID clusterID:??? attributeID:??? params:nil queue:... completion:...];

Thanks a lot for all the support! And if you can bear with one more question relevant to this thread: is there a way to find the particular Matter cluster/attribute IDs which match a HomeKit characteristic?

In terms of the matter spec, you can determine what a device provides by reading and parsing a specific cluster ID (MTRClusterIDTypeDescriptorID), but you'll need to look into the matter spec for the details of that process. As a side comment on that, you shouldn't think of the Matter Framework as a "complete" API that's designed to be read and understood on it's own. Somewhat like HomeKit, most of it's details and behavior are driven by the underlying hardware spec, so the framework only really makes "sense" when you start with the hardware spec[1], not the framework.

In terms of mapping those cluster IDs back to HMCharacteristic, no, we don't have API for that. The assumption is that you're moving down to matter to access non-HomeKit characteristics, which means the mapping wouldn't be all that useful.

[1] This would be a huge problem with the HomeKit framework, except that most HomeKit apps are written by hardware vendors who have access to the MFi spec. However, the problem was still significant enough that we released the non commercial HAP spec.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware