HomePod mini temperature sensor in HomeKit with Mac Catalyst

Hi,

Perhaps we are having the same issue. I see all my other accessories but only my HomePod is not being detected.

I think the HomePod is not part of the HomeKit Accessories and would more likely be connected through SiriKit (This is my intuition as of now).

I am not very knowledgeable about this, but for now in my project that is the same issue I'm running through.

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.

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 haven't looked into this closely, but I believe the main issue here is that the HomePod (and derived sensors) aren't actually "HomeKit Accessories". That means they don't implement HAP (HomeKit Accessory Protocol) so exposing them through the HomeKit API requires synthesizing a full HAP configuration, required metadata, etc.

I've just filled a feature request with Apple. The more of us do the same, the better chance we get the access.

What's the bug number? Also, what do you actually want to do with these sensors at the "app" level and did you include those details in the bug?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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!

Aha, I see. I (along with the OP, it seems) got misled by the fact that 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 from its primary task to present and control the HomeKit).

Keep in mind that HomePods (like AppleTVs) are HomeHubs, so there's already a control channel (either direct or over iCloud) that's relaying data between the device you’re running Home.app on and the HomePod. So the data is actually moving through that existing channel, not being sent on its own. To a large extent, that's also why the temperature sensor feature exists at all— it's not that we thought there was some great demand for integrated speaker/thermometers, it's that all of the most complicated work had already been done as part of HomeHub.

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.

The big thing to understand about this kind of bug is that the "goal" of your bug is less about "telling us about a problem" and more about explaining why it should be a priority. Taking this bug as an example, nothing about the current behavior is an accident or "surprise" to our engineering team, as it's a natural side effect of the overall implementation. Similarly, the work required is significant and perhaps time-consuming, but not really all that different than what HAS (HomeKit Accessory Simulator) does.

The real issue here is about evaluating engineer time (both the immediate implementation and ongoing maintenance) against the benefit provided. That's why your "story" and use case are so important— there's a big difference between "it's odd that this is missing" or "it's weird that app X can't see this sensor" and "I have this cool idea I'm working on which would be better if <insert change>".

Should I add essentially the contents of this reply to the ticket? Or just a link to here? What's better?

Add it directly to the bug. You can add a link to this post as well, but it's very helpful to have all of the information directly in the bug.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

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?

No, though there are several large-scale projects that implement HAP (HomeKit Accessory Protocol) in software. This is not something the system formally supports (for example, pairing one of these accessories triggers the same "uncertified accessory" warning as HAS), but they do "work".

However, the problem here is this:

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.

Strictly speaking, nothing prevents you from simulating an accessory on the same device Home.app is running on. Indeed, this is exactly what you're doing when you run HAS and Home.app on your Mac. The problem here is that this relies on your app being awake and "active", something iOS severely restricts. See "iOS Background Execution Limits" for a good overview of these issues.

In any case, that reality means that simulating an accessory on iOS isn't really all that useful.

(I happened to notice that there is a software out there which for a similar goal uses shortcut-based automations which open specific URLs.)

One clarification here. The "main" Shortcuts.app interface provides a very broad set of capabilities, run on device, and can be extended by apps on the device. However, that's NOT how HomeKit's "automation shortcuts" work.

It may not be immediately obvious, but if you look closely at what's possible inside a HomeKit automation shortcut, you'll find that it's limited to a smaller subset of what Shortcuts.app offers. The reason for this is that HomeKit's shortcuts don't necessarily run on the device that created them but are actually run by the HomeKit "backend", typically the Home Hub. That's why the command set is more limited, as the device running the automation simply doesn't have access to the same capabilities and data your app does.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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!