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

Thanks a very big lot for the detailed explanation! All clear now. (I wonder if it might be perhaps worth the effort to add this information to the standard HomeKit documentation.)

Kevin, thanks for a quick response! the HomePod (and derived sensors) aren't actually "HomeKit Accessories". Aha, I see. I (along with the OP, it seems) got misled by the fact they are presented through the Home application (but of course, I can see there's no reason why Home could/should not use different and probably private APIs to communicate with these, aside of its primary task to present and control the HomeKit). In that case I quite appreciate that presenting the HomePod temperature sensor through an appropriate HomeKit API, albeit technically possible for sure (perhaps just at the software level, without a need to change the underlying protocols Pods actually use to communicate), might well be complicated enough not to be worth implementing. What's the bug number? Let me see... FB21802284 what do you actually want to do with these sensors at the "app" level Myself, I'd like to keep track of all the temperature sensors in my home to implement a smarter temperature control. (I've checked a number of HomeKit-enabled thermostats and so far found none which would fulfil my needs, so I am about to write one myself as a HomeKit application, primarily for my own usage — at this moment I seriously doubt the result would ever make it to AppStore.) did you include those details in the bug? Oh, I did not; I regret to admit I had considered “whatever one might want to do with all the other HomeKit temperature sensors should be possible with the one in HomePod just as well” as self-evident as not worth expressing explicitly. Sorry for that. Should I add essentially the contents of this reply to the ticket? Or just a link to here? What's better? Thanks!

I might be wrong, but I understand Apple intentionally hides Pods (and ATVs) from the public API. Whilst there might be a point in doing that with more sophisticated characteristics for privacy and safety, with the temperature sensor it's patently absurd :( I've just filled a feature request with Apple. The more of us does the same, the better chance we get the access.

P.S. As for the privacy concerns — for the moment, I write the code just for myself; I am struggling with some weird behaviour of an Eve Thermo when controlled through automations... well no point to detail here I guess, completely irrelevant. If it ever grows into a publicly available application (which I very seriously doubt), I'll of course check these concerns in detail (starting with the primary question whether it is all right to record the HK characteristics at all). Offhand I'd think the user should be able to see which of his devices the values were recorded on (by the very device name he assigned it himself), but I admit I did not think it through much and might well be missing some important point. Anyway, for the time being, it's rather at the moot side :)

Thanks a lot!

Thanks, Quinn! What specific information are you looking for here? Well ... information of the device and operating system the code really runs on would be sort of nice. It's pretty weird to ask the code which runs on Mac for the device it runs on and get “iPad”. I could understand this when running as “Designed for iPad”, in which case the code might really need to be lied to, for it was designed for iSomething originally. But in the Catalyst mode, where the code is designed for Mac, it seems really at the strange side. And what do you plan to do with that information? At this moment, I just wanted to save it for possible further interest, along with other things my application stores (see please below). Currently the only practical part would be to determine whether I can store my data into any file in any folder (as on Mac), or whether I should stick with Application Support sub-folders (as on iWhatever). Given that, I’m not sure Mac Catalyst is your best option Well the main purpose of my application is to observe the characteristics of some HomeKit devices and save their value changes along with timestamps. To these stored data I wanted to add the information on which device this happened, purely for possible further interest (most probably nothing more than “recorded on XXX” :)) Do please correct me if I am wrong and if I overlook something of importance, but I understand there is, triple alas, no HomeKit API available amongst the native macOS APIs. Thus — far as I got it right — to write a macOS HomeKit application, I am, alas, forced to stick with Catalyst.

Thanks again :) Test please at your leisure at your side this project: https://ocs.cz/CD/catalyst_test.zip Note: my application is intended primarily for macOS, should be able to run also with lower priority, essentially as a side-effect, on iPadOS. Thus I believe “Catalyst” to be a much better destination than “Designed for iPad”, or am I wrong here?

Thanks, Kevin. Well yes, I'm bitterly aware of that — just lately I've bumped to the ugly problem that there's no way for us lowly 3rd parties e.g., to create a trigger-owned scene. It's wrong, you know — would make sense for privacy- or security-related APIs, but... well, this is no place to discuss this (and of course, I completely appreciate it was not your decision :)) As for the 3rd party app (whose creator I won't reveal for obvious reasons) ... hmmm, given your answer that the API is not public (alas!), I've re-tested a couple of times, and it seems it actually sometimes works, sometimes it does not, rather randomly. I guess they hacked-out some unreliable undocumented way to do that, most probably. Reminds one of https://openradar.appspot.com/7044974 sort of :)

Thanks! If I get the “target” thing right, it says “My Mac (Mac Catalyst)”. There's no other option; the selection looks like this ... hm, there's no option here to paste a pic? Darn, like this: https://ocs.cz/CD/run-options.jpg I'll prepare the test project soon, pbbly in a couple of hours, am a bit at the busy side :)

The runloop-based approach so far (up to iOS17) did work for long years without one single problem. If there indeed is a hardware were it would have failed with older iOSen, then it seems none of our many clients ever used that hardware. Weird. The API which needs to show an alert and return its result is multi-platform and I can't really refactor it. Hmmm... I guess I might be able to run it completely in a background thread, for all the other callbacks which do not have this problem use performSelectorOnMainThread or something like that, and for this one just let the background thread wait on a semaphore or another kind of lock, run the alert on the main thread normally, and when done, let the background thread go on. Offhand I guess it should work. Nevertheless it seems an indecent heap of work for such a triviality. Apple's UI frameworks did support such things from the first moment they ever existed, compare please the original NSRunAlertPanel (and current -[NSAlert runModal) APIs. It seems really extremely weird that i(Pad)OS would itentionally not support such a basic functionality :(

https://ocs.cz/CD/testModalAlert.zip