The value is 2 Boolean values stored as bits 0 and 1 in a UInt8. I chose the value I was trying to set as one that could be represented as a “Boolean”, but when I tried that as the type I still got the code 133 error. My firmware guys told me about the 1.3 Boolean State Configuration, I’ll try learning more about that and if it is a simple rename perhaps I can use something from 1.2 instead. I’ll also see if the firmware guys can tweak something to make it work.

Hi Kevin, thanks for your clarification, as usual. I'm trying to use InvokeCommand() now and it is enough different that I decided to start a new topic. If you wouldn't mind taking a look it is thread 775616. Thanks again!

Thanks! I am very grateful for you sharing that even though I feel I should have thought of it myself. 🤪 That's how it goes sometimes! You seem to have figured writes out yourself, but I tried reads first and saw the way data comes back. After naively trying to write just the value I tried sending something back that looks like what I got via a read and it worked fine. The comments I have seen in the code you referenced hint that I may need an additional key in the dictionary I'm sending to invokeCommand so I'll keep digging. Good luck with subscribe - my interaction with DTS leads be to believe if you are building your own fabric it will work, but if you are using the process described by DTS in reply to my original question to get your MTRBaseDevice then subscribe will not currently work. An alternate process is apparently in the works which sounds like a forward-looking statement from a company that doesn't make them so I feel lucky to have that much. If you get it to work I'd love to hear how you did it! Thanks again!

I'm going to share a couple of things, I'll let you decide if they are helpful at all. #1 This conversation I had with Kevin has more back and forth than I see in this thread that includes your comments. I suggest you search again and see if you can find the full conversation. #2 A key part of the missing conversation referred to in #1 suggested that I submit a bug for the subscribe APIs not working. I did that and received the following information, which give no timetable 'cuz Apple doesn't talk about anything unannounced. In the bug report I specifically called out the process Kevin provided in this thread for accessing Matter devices via HomeKit and that process is what they were referring to when they say "this HomeKit API". Here is what they said: "MTRBaseDevice.subscribe API is not supported by this HomeKit API to create Matter Controllers for Apple Home via Node ID. In the future, we'll be adding a new API that makes use of MTRDevice interface, which is better suited for subscription via this interface."

Hi Kevin, I hope you are willing to reply to this thread one more time. What you say about 3rd party apps is spot-on. In a perfect world they would be all about custom configuration. The problem for me is devices I am working on have custom sensors that result in custom alerts. HomeKit has a number of "standard" alerts it will handle in the ecosystem without the vendor app's involvement. An example of this is Leak Detection. Matter 1.3 specs have a standard for leak detection but as far as I know the Home and HomeKit implementation using Matter do not support these at this time. Matter 1.3 also has a freeze alarm which is something I don't believe HomeKit has done in the past, or currently does for Matter devices either. What I really need is to be able to have a Matter device be able to raise an alarm similar to these as well as for other custom conditions - like temperature or humidity is outside a user-configured range. Does the current Matter implementation via HomeKit support notifications for alarm conditions of any kind from a Matter based device? If not would it be reasonable to expect this will be implemented at some point in the future? I also need to be able to do custom configuration on the device such as set the ranges mentioned earlier and I currently have all the tools needed to do that, thanks in no small part to your kind assistance. Subscriptions will be nice so I can keep the settings shown in the UI up to date while the app is running without polling. Detecting and notifying the user of alarm conditions is the only reason I would need to run in the background at all, and frankly I would rather the Home ecosystem take care of that for me as was done in many cases with HomeKit. As you point out attempting to do this with background processing on a device that isn't always in the home isn't a great solution. What is the alternative?

I have submitted this as a bug: FB14928319

Thanks for the further clarification, I will file bugs that include what I am trying to do as well as the APIs I want to use to implement those things. I did try the "subscriptionEstablishedHandler" and discovered it doesn't work for me if I only pass a "subscriptionEstablished" handler. That may be due to the fact that I am using Swift and the "errorHandler" is also required, though it appears that may not be the case in objectiveC? I've been away from objectiveC for a while. Consequently my error handler is called, not "subscriptionEstablished".

Thanks Kevin! - for another very helpful answer. I appreciate you giving such answers rather than avoiding topics I may not want to hear - I really do want to know all I can to make things work in the Apple ecosystem. I know Apple is VERY stingy with background operation of apps and this is why my iPhone battery life is both long and predictable - one of the reasons I stick with iPhone and probably many others as well. I will try your subscription suggestions and will file a bug as well. Thanks again.

The response from Kevin has been quite helpful - I have been able to read data from a Matter attribute I obtained using the process he described. However, I have not been successful with subscribe methods. The specific subscribe method Kevin linked returns an HMError #48 to my errorHandler closure when I call it. The localized description of that error is "The operation couldn’t be completed.", which certainly tells me something went wrong but provides no actionable remedies. The name of code 48 in HomeKit.HMError is "operationNotSupported" which is similar and yet somehow more discouraging. In the spirit of Kevin's suggestion that I "explore the API and look for alternate paths before assuming the general approach here 'doesn't work'." I tried the other 3 subscribe methods that haven't been deprecated. Two of them give me the result above via my reportHandler. The remaining one, subscribeToEvents, never calls my reportHandler closure (where I would get an error or a report) and also never calls my subscriptionEstablished closure. These methods appear in the documentation as though the docs were auto generated and have no further description of how to use them. Can anyone provide any insight into how these methods should be used as well as some insight into what I might be doing wrong? Frankly the subscribe method Kevin linked looks the most useful in my situation, but I can't make it work. I am using Xcode Version 16.0 beta 2 (16A5171r) and have tried these methods on an iPad running iPadOS 18.0 Developer Beta 3. I also tried the subscribe:with method an iPhone running iOS 17.5.1 and got the same result. Thanks for any additional insight you can offer.

I posted a separate question about this and got a answer that was helpful to me, perhaps it will help you too? https://developer.apple.com/forums/thread/757458

This is exactly what I wanted but wasn't hopeful I would get it. Thanks so much, I'll start implementing this!

I have this question too. I have used the debugger and print() to examine what I get from the HomeKit APIs for a Matter device and I'm not convinced I am getting custom clusters. It would be very useful to know if this is possible and if so how to make it work. If not, it sounds like I would need to commission the device using the Matter Framework rather than HomeKit with my own certificates and if I do that it isn't clear that the device would appear in the Home app. If that were the case I suppose the user could commission the device twice but that would be a terrible user experience. Thanks in advance for any assistance offered!