Communicate with, configure, and control home automation accessories using HomeKit.

Posts under HomeKit tag

36 Posts
Sort by:

Post

Replies

Boosts

Views

Activity

Scanning Thread accessories in HomeKit
I'm trying to browse my Homekit accessories and try to show the different accessories communication protocols, i.e. Wifi, Thread, Zigbee, Z-wave! Zigbee and Z-wave I can have hard-coded depending on model because I have so few! But…. I can easily find all accessories which are wifi attached by using: isBriged == false and uniqueIdentifiersForBridgedAccessories == nil However, I can see that some of the accessories are thread enabled (I have read the documentation for the accessory) but still in the list. So, my questions: Are there any attributes in the accessory that is unique for a Thread accessory? for accessory in accessories { if(accessory.isBridged == false && accessory.uniqueIdentifiersForBridgedAccessories == nil ) { // Can be a Wifi device but need more controls // requiresThreadRouter??? if (true) { wifiAccessaries.append(accessory) } } }
3
0
434
Dec ’24
Anyone who encounters "hmmtrAccessoryServerStateChange" error during Matter device commissioning?
Hello. I found that my iPhone has encountered same error continuously when I tried to commission my Eve Door & Window device. Nov 12 11:33:48 iPhone homed(Matter)[181] <Error>: Can't extract public key from certificate: src/crypto/CHIPCryptoPALOpenSSL.cpp:1911: CHIP Error 0x0000002F: Invalid argument Nov 12 11:33:48 iPhone homed(Matter)[181] <Error>: convertX509Certificate: src/credentials/CHIPCertFromX509.cpp:559: CHIP Error 0x0000002F: Invalid argument Nov 12 11:33:55 iPhone homed(HomeKitMatter)[181] <Error>: [4264877660/1(3180582119)] Couldn't get device being commissioned for network scanning: (null) Nov 12 11:33:55 iPhone homed(HomeKitDaemon)[181] <Error>: No unpaired accessory for server HMMTRAccessoryServer fa:e6:88:97:2a:ee Nov 12 11:33:55 iPhone homed(HomeKitMetrics)[181] <Error>: [4264877660/1(3180582119)] tag="hmmtrAccessoryServerStateChange" desc="Error in progress state" errorDomain="MTRErrorDomain" errorCode="1" state="19" Nov 12 11:33:55 iPhone homed(HomeKitMatter)[181] <Error>: [4264877660/1(3180582119)] CHIP Accessory pairing failed: Error Domain=MTRErrorDomain Code=1, <HMMTRAccessoryPairingEndContext, Step: HMMTRAccessoryPairingStep_GettingNetworkRequirement, Error: Error Domain=MTRErrorDomain Code=1 "The operation couldn\M-b\M^@\M^Yt be completed. (MTRErrorDomain error 1.)", Sourceerrordomain: MTRErrorDomain> Is there anyone who has experienced or solved the same error as me? Thanks.
0
0
443
Nov ’24
There was a problem with HCA TCL029 companion 2.4.3 in iOS 18.1
Hi all. I'm developing a homekit accessory, and I'm currently doing mfi certification. The developed product is smart door lock and supports homekey. Use below tools iPhone 13 , XR , 11 HomeKit Certification Assistant 6.4.0 HomeKit Accessory Tester 9.3.0 HomeKit Companion 2.4.3 I recently updated my iPhone 11 to iOS 18.1 and if I proceed with TCL0029 of HCA, there is a problem. Companion has no response to "SELECT step-up AID". (Unified Access Air Protocol Specification R1.1.pdf) The companion outputs the following message. "Step-up Encountered Error" There is no problem with iOS 17.x. Products that have already been certified are experiencing the same symptoms. There is no problem with using homekey in real life, only problem with companion.
0
0
434
Oct ’24
How to use HomeKit Accessory Diagnostics Function
I have some questions about the ADK6.3 Diagnostic function: If HAP_DIAGNOSTICS_MANUFACTURER is not enabled when compiling ADK, after adding the device through Home, the collecting log function cannot be found in the device settings. What is the reason? How to solve it? If HAP_DIAGNOSTICS_MANUFACTURER is enabled during compilation, the vendor URL needs to be added when transmitting the diagnostic log. How is this vendor URL defined? How to add it to diagnosticsURLParameters? How can I use the Home App in iOS device to test diagnostic functions before obtaining certification for HomeKit accessories?
0
0
491
Oct ’24
Matter controller permissions after device commissioning
I have tried filing a feedback, FB15509991, for help with this and that didn't go anywhere. Figured I would try the developer forums. Overview I am working on a matter device using the Matter SDK and the matter device basically consists of both a matter bridge and matter controller functionality. The bridge part is currently a none-issue, however trying to have our device be an additional controller for the existing matter fabric. The overall idea for our device as a matter controller is that it can be commissioned with Apple Home (via Matter BLE commissioning) and then view and control existing matter devices (over Wi-Fi network) on the Homekit matter fabric (convenient user experience), instead of our device having to form a matter fabric of its own and then having the user re-commission all their devices to add them our controller (difficult and possibly frustrating user experience), in order to have a consistent control experience between our device's display and Apple Home app. The big problem When we onboard our device via Apple Home app it does not have attribute write permission to other devices on the same fabric as we are seeing Unsupported Access (IM:0x0000057E) responses instead of expected attribute changes. Same for attempts to read valid endpoint/cluster/attributes. The possible solution Our operational device needs to be added to the access control list (ACL) with View and Operator permissions and then the ACL update pushed to all the fabric devices in order to give our device controller access to them. The next problem My question is what do we have to do in order for our device will be given control access permissions (View + Operator) in an ACL (access control list) update to other devices after our device has been commissioned? Because the matter specification does not define a "Controller Cluster" that could be used to type a device as a matter controller to make it obvious that the device wishes to have controller permissions post commissioning. So that means its up to each fabric administrator implementer as to how to accomplish what I'm requesting to do. I'm hoping somebody in the Apple team responsible for the Matter + HomeKit integration could give me some insight as to whether this is even possible at this time. Test environment The environment consists of: iPhone running iOS 17.7 iPad running iPadOS 18.0.1 HomePod Mini with software version 18.0 Realtek WiFi module running Matter Fan+Light firmware (Matter SDK 1.3) for target/controlee [our device] LCD display unit + Realtek WiFi module (Matter SDK 1.3) for controller.
1
0
634
Oct ’24
Commissioning Matter Thread Device without Hub
I have been looking at the new feature in iOS 18 where it is possible to pair Matter accessories without a hub. Using the Home app I can successfully commission and control a Matter Thread Light Bulb directly (without a home hub in the network). I have an iPhone 15 Pro which includes the thread hardware. I then tried to commission the same device in my own app using the MatterSupport framework. In this case the same user interface is displayed as when using the Home App but an error is displayed - "Thread Border Router Required." Is it also possible to connect directly to a thread Matter device when using MatterSupport or does this only work when using the Home app?
3
0
971
Nov ’24
Can an app be seen as a trigger device on Homekit?
Suppose I want to create a dummy switch for HomeKit using an app. I run the app for the first time, the app registers itself as a dummy switch and all accessories see the app as an OFF switch. The following day, I run the app again and turn the dummy switch ON. All accessories that were monitoring the status of that switch, adjusted themselves accordingly, run their automations and so on. Can an app do that in iOS, macOS, iPadOS, watchOS, etc.? If so, can you point me in the right direction?
1
0
694
Oct ’24
Matter development - Matter Accessory - Apple Ecosystem
Apple developer support could not answer my question which is the following: How are Matter developers supposed to test accessory pairing, accessory communication and accessory discovery if the Console logs provided by Apple (iOS, MacOS, iPadOS) are encrypted, incomplete or straight up non-existent. Current issue is mDNS-SD discovery, pairing and PAKE requests initialisation. Impossible to figure out why X or Y stopped on the Apple Device. Chip-tool (provided by PROJECT-CHIP) acts 100% differently than iOS (Home) or iPadOS(Home). Thank you
0
1
745
Sep ’24
Matter subscriptions not working with MTRBaseDevice obtained from HomeKit
I am working on an app for a Home automation device built on Matter. There are both standard and custom features/services/clusters on this device. HomeKit seems to pick up the standard ones except for one (leak detector) that is part of the Matter 1.3 spec. Of course HomeKit doesn't know what to do with the custom ones so they aren't shown in the Home app. I am trying to access those directly via calls to the Matter APIs so I can present them in a custom app. To access Matter APIs I am using a process suggested by DTS in a forum post that can be found here. The MTRBaseDevice I obtain in the suggested way responds appropriately to read and write commands, but subscribe doesn't work as expected. It returns an error code 48 which is described as "The operation couldn’t be completed." and the source that contains the error calls it "operationNotSupported". This is the subscribe call referenced in the DTS response to earlier post, however there are three more "subscribe" methods and I have tried them all. Two also return an error 48, and the last one never calls any of the callback handlers providing no data or errors. Since a subscription is supposed to return data periodically even when there have been no changes it doesn't seem that different than polling so I have written code for that and it works. However I don't expect iOS will let me poll in the background for alarm conditions and I am hoping subscription updates will be sent to a background app so it can notify users of these conditions. Is that a reasonable assumption? Here is the code I am using to test subscribe, perhaps I am doing something wrong? Originally I had shorter intervals but changing them made no difference. Do they need to be longer? let subscribeParams = MTRSubscribeParams(minInterval: 15, maxInterval: 900) if #available(iOS 17.6, *) { subscribeParams.shouldAssumeUnknownAttributesReportable = true } subscribeParams.shouldFilterByFabric = false subscribeParams.shouldReplaceExistingSubscriptions = true subscribeParams.shouldReportEventsUrgently = true subscribeParams.shouldResubscribeAutomatically = false print("Attempting subscribe:with") let localClusterStateCache = MTRClusterStateCacheContainer() matterBaseDevice.subscribe(with: OS_dispatch_queue_global.global(), params: subscribeParams, clusterStateCacheContainer: localClusterStateCache) { (attributes: [Any]) in print("subscribe:with attributeHandler: \(attributes)") } eventReportHandler: { (events: [Any]) in print("subscribe:with eventHandler: \(events)") } errorHandler: { (error: any Error) in let reportingError = error as NSError if reportingError.domain == "HMErrorDomain" { let hkError = HMError(HMError.Code(rawValue: reportingError.code)!) print("subscribe:with errorHandler: \(hkError.localizedDescription); UserInfo: \(hkError.userInfo); ErrorUserInfo: \(hkError.errorUserInfo)") } else { print("subscribe:with errorHandler: \(reportingError)") } } subscriptionEstablished: { print("subscribe:with Subscription established!!!") } resubscriptionScheduled: { (error: any Error, numericParam: NSNumber) in print("subscribe:with Resubscription scheduled; error: \(error); numericParam: \(numericParam)") }
7
0
1.3k
Oct ’24
Home Automation on Sensor and Time
Hi, I wanted to start the central heating if the temperature is below a certain level, I am home and the time is in a range. I created an automation but it didn't fire. I think it's because the sensor condition is "Temperature Drops Below" not "Temperature Is Below". In other words because the temperature was already below the level at the time the time window opened, the automation didn't fire. Does that sound correct? If so is it possible to do what I want which is to turn on the heating in the morning if it is cold?
0
0
455
Aug ’24
Support for custom Matter endpoints, clusters and attributes
I am working on an app for a home automation device. If I were using HomeKit exclusively I could add custom services or custom characteristics on standard services and these things would all be reported to my app via HomeKit. There is sample code from Apple that demonstrates how to do this. When a Matter device is commissioned using HomeKit you might expect custom clusters and/or custom attributes in a standard cluster would be translated to appropriate HomeKit services and characteristics, but this doesn't appear to be the case. Is there a way to have HomeKit do this? If not it seems I would need to use Matter directly rather than via HomeKit to access custom features. But if I commission the device using Matter in my app then I understand a new fabric is created and the device would not show in the Home app. Maybe the user needs to commission the device twice, once with my custom app and once with the Home app? That seems like a poor user experience to me. Perhaps that is the price paid for using a cross-platform standard? Is there a better way to get the same level of customization using Matter that I am able to get using HomeKit?
16
0
2.2k
Mar ’25
Commission Matter accessory added via Apple Home
Greetings! I've added a Matter accessory via the Apple Home app. In my app, I'm attempting to commission this device and add it to my fabric. However, when I try to open the commissioning window, I receive an error stating, MTRBaseDevice doesn't support openCommissioningWindowWithDiscriminator over XPC. It appears that opening a commissioning window via an XPC connection is not yet supported. Is there another method to commission the device? Can I retrieve the setup payload from the MTRBaseDevice object or the shared MTRDeviceController? Here's the simplified version of my code: var home: HMHome // HMHome received via HMHomeManager var accessory: HMAccessory = home.accessory[0] // my Matter-supported accessory let deviceController = MTRDeviceController.sharedController( withID: home.matterControllerID as NSCopying, xpcConnect: home.matterControllerXPCConnectBlock ) let device = MTRBaseDevice( nodeID: accessory.matterNodeID as NSNumber, controller: deviceController ) device.openCommissioningWindow( withDiscriminator: 0, duration: 900, queue: .main) { payload, error in if let payload { // payload not received } else if let error { // I'm getting here "Error Domain=MTRErrorDomain Code=6 "(null)"" // and "MTRBaseDevice doesn't support openCommissioningWindowWithDiscriminator over XPC" logged in the console print(error) }
1
0
1k
Aug ’24