Thanks a lot! As for how the user actually interacts with your app and how important the "current" state is within that context well this is the very private local app of mine we are debating elsewhere (https://developer.apple.com/forums/thread/849339) and the one and only user is yours truly :) Its main purpose is to create and keep a log of (a) all the temperatures[1], (b) closely related characteristics (like e.g., a power outlet which controls a heater, or the current state of a radiator valve). [1] but for HomePod's, whose API is private. I've filled a feature request FB21802284, but actually, never mind that; I've simply placed a cheap temperature sensor nearby :) As for the reason why I do that, I am working on my own home heating control, tailored to my own needs. Among others, I need to analyse the previous temps. None of the thermostats out there which I've checked worked the way I'd like to, so I am going to DIY (well DIMyself :)) Given that, the current values per se are not that important, and missing a temperature event or two is a small issue. Contrariwise, alas, missing an event from a power outlet is sort of inconvenient, for I would not know that the appropriate heater was on (or off) at all.

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.)

Filled an enhancement request FB25066661.

Thanks! The issue is FB25066661.

this one captures the issue better That was the very reason why I created it. Anyway, above there are links to all the relevant other threads, which I'm going to check now :)

Thanks a lot! Meantime, pursuing the problem further, I've found there are other problems as well, e.g., an absurdly near expiration date generated in the profile. Not to hijack my own thread :), and, more importantly, to allow any other user who might perhaps bump into similar problems to find the debate under a more apt name, I've started a new topic for this at https://developer.apple.com/forums/thread/849339.

... The users HomeKit configuration is considered fairly sensitive both for privacy reasons (they could be used to identify users) and general security/disruption risk (using HomeKit to disrupt the user) ... I believe I sort of understand these issues. Still, I also believe there should be a simple and easy way to tell the OS “hey, allow this application to do darn anything, for I completely trust it and won't complain of any problems it might cause” (typically since I wrote it myself). Unlike the nuclear option (far as I understand it properly) this would not decrease the system security regarding anything but this one particular app: all the other threat vectors will remain just as perfectly (or imperfectly) covered as if nothing was changed at all. After all, the effects would be essentially the same as if I just copied the project down and built and ran that application in Xcode on the target machine. Only there are (completely irrelevant) reasons why there is no Xcode on the target machine, typically not space enough on the HDD, or too old hw, ie too old macOS, ie too old Xcode to understand the current projects (actually the case of my mac mini). Always solvable, of course, but through lots of hassle :(

Just to wrap loose ends, I checked that indeed the darned profile is a requirement for HomeKit: if I remove the capability from the target, macOS Provisioning Profile immediately turns to None Required. Soon as HK is added back, it's again at Xcode Managed. Sigh.

I suspect that your profile lists your development machine but not the other machine. You can confirm this... Seems so. Far as I understand the description right, it looks like there is only one computer ID in the profile indeed (see my steps below). --Incidentally, how do I find the ID of a particular computer to make completely sure? Though the probability 00008132-0016495E2199801C is my development machine is, of course, extremely high.-- Found it meantime in System Information as “Provisioning UDID”, of course, checks. As for the solution, that seems the hard part, since HomeKit is a must in case of this particular app :( Can you see any, aside of my switching to a paid team? Thanks a lot! 1062 ocs /Volumes/ocs/Desktop> security cms -D -i HomeLog.app/Contents/embedded.provisionprofile -o /tmp/p.plist 1063 ocs /Volumes/ocs/Desktop> plutil -extract ProvisionedDevices xml1 -o - /tmp/p.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <string>00008132-0016495E2199801C</string> </array> </plist> 1064 ocs /Volumes/ocs/Desktop>

Aha! I guess the culprit would be most probably that the profile linked to my personal team BHHT72562H is available on the machine where the app has been developed, but not on the other ones (the MacOS apps work since they are not signed, but for Catalyst ones this seems to be mandatory). Sigh, this is a qagmire :( How do I get it there (there is no Xcode on the other machine; otherwise I would simply moved the project there and built)? I've actually tried to go Settings / Apple Accounts in Xcode on the original one open my account, and inside of it, open my Personal Team Manage Certificates export the certificate to a p12 move the file to the target computer and import it to its login keychain through Keychain Access. Alas it did not help, not even after a restart :( What's the proper way to do that? Or am I on a completely wrong track and the culprit would be elsewhere? Thanks a lot!

Thanks! On the other computer, where it does not run: ocs@iMac Desktop % codesign -d --entitlements - HomeLog.app Executable=/Users/ocs/Desktop/HomeLog.app/Contents/MacOS/HomeLog [Dict] [Key] application-identifier [Value] [String] BHHT72562H.cz.ocs.HomeLog [Key] com.apple.application-identifier [Value] [String] BHHT72562H.cz.ocs.HomeLog [Key] com.apple.developer.homekit [Value] [Bool] true [Key] com.apple.developer.team-identifier [Value] [String] BHHT72562H [Key] get-task-allow [Value] [Bool] true ocs@iMac Desktop % ./HomeLog.app/Contents/MacOS/HomeLog zsh: killed ./HomeLog.app/Contents/MacOS/HomeLog ocs@iMac Desktop % To compare, on the one where the app was built and runs all right: 1048 ocs /Volumes/ocs/Desktop> codesign -d --entitlements - HomeLog.app Executable=/Volumes/ocs/Desktop/HomeLog.app/Contents/MacOS/HomeLog [Dict] [Key] application-identifier [Value] [String] BHHT72562H.cz.ocs.HomeLog [Key] com.apple.application-identifier [Value] [String] BHHT72562H.cz.ocs.HomeLog [Key] com.apple.developer.homekit [Value] [Bool] true [Key] com.apple.developer.team-identifier [Value] [String] BHHT72562H [Key] get-task-allow [Value] [Bool] true 1049 ocs /Volumes/ocs/Desktop> ./HomeLog.app/Contents/MacOS/HomeLog 2026-09-30 16:59:19.512 HomeLog[64856:4105486] sysname: 'Darwin' nodename: 'Mac.OCSluj' release: '27.0.0' version: 'Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:57 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8132' machine: 'arm64' 2026-09-30 16:59:19.512 HomeLog[64856:4105486] hw.model: 'Mac16,12' 2026-09-30 16:59:19.520 HomeLog[64856:4105486] *** HomeLog v1.0b1 running on 'Mac.OCSluj (arm64-Mac16,12)' E3C0147F-0447-599D-9537-6A13B4F09282 ^C 1050 ocs /Volumes/ocs/Desktop> Seems pretty much the same :(

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!

Thank you very much!

Thanks a lot! As for simulating an accessory on iOS isn't really all that useful I guess in my specific case this would not be a big problem, for I can either — for the time when I actually need to observe those automations, which would be limited to days, weeks at worst — keep my app foreground on an iPad; or simply run my application on a Mac, where there are no background-execution limits at all, far as I know. Thus, unless I overlook some other hurdle, this would be OK. I am a bit wary of the “large-scale projects” though: for me, this functionality is not extremely important (rather “just a bit helpful”), and if the only way to achieve it would mean to write, test and maintain heaps of complex code, I can do without (e.g., for automations triggered by HMCalendarEvents I've already wrote a tool which reads the fireDateComponents and then simply keeps track of the time; whilst there of course could be a small difference betwixt the time the trigger assumed to fire and the moment it actually did, usually this makes no real problem for me). Is there a documentation or even a public sample code for this anywhere, which i could check? If not, well I guess I'll focus on other and more important tasks for the time being :) Thanks again!

Thanks a lot, I've added the info to the ticket. (Does not seem to me to be a bug, rather a feature request, or a “suggestion” type feedback. That's probably quite unimportant :)) Incidentally, not really all that different than what HAS (HomeKit Accessory Simulator) does is there a public API which would allow me to do (essentially) the same, namely, to create a HomeKit pseudo-device (or bridge) purely by software in my application code? I've tried to find such an API, but so far, in vain. The goal here is, I would like to be able to keep track in my application of when/whether at all some HK automations did actually fire. If I added such a pseudo-device of mine to the appropriate scene (action set), I presume it would get the characteristic-change event, and thus I'd get the desired information this way. (I happened to notice that there is a software out there which for a similar goal uses shortcut-based automations which open specific URLs. I don't like that approach myself, and if it happens to be the only possibility to achieve the goal, I've decided to do without.)