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

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.

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!

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

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 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!