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