Apple Home sends Cool instead of Auto for Matter Room AC device type (works correctly as Thermostat)

Filed as FB25164477 (logs and repro attached). Is this a known issue?

Yes, though it may take some time to fix. The problem here is a side effect of an existing detail in the HAP (HomeKit Accessory Spec) and how Matter accessories are then mapped onto that spec.

In its initial release, the HAP spec defined "10.8 Thermostat," which basically matches a typical "American" thermostat— Off/Heat/Cool/Auto states, plus corresponding temperatures. However, with the benefit of hindsight, it turned out that this definition was EXTREMELY naive, as the range of HVAC solutions is extremely large and, most notably, large portions of the world exist that either "Heat" (but never "Cool") or "Cool" (but never "Heat"), with an extra "bonus round" of places where the device can either "Cool" OR "Heat" but can NEVER switch between those two (typically because doing so involves moving a water pipe). Unfortunately, all of Thermostat’s characteristics were required, which meant it couldn't be used for any of those cases.

In any case, this was a huge problem, which led to the creation of "10.34 Heater Cooler,” which replicated the same basic functionality as Thermostat, except that the various characteristics were now optional. Unfortunately... there was one difference, which was that the new service did NOT include "Auto.” The (reasonable at the time) assumption was that a “full-featured" device would just use "10.8 Thermostat,” so that the main reason an accessory would be a Heater/Cooler is that it DIDN'T have a way to switch between those two modes.

That then leads to the Matter spec, which was clearly written by someone (likely a lot more than one) with a very wide HVAC perspective. Case in point, the Matter spec defines no less than 8 valid modes, not 4, delightfully numbering them 0–9 except for number 2. The thermostat spec is also ~21 pages compared to at most 3 pages for Heater/Cooler.

In any case, Matter Thermostat was mapped onto HAP Heater/Cooler because that was the only option (as I noted above, Thermostat is too inflexible). Unfortunately, that mapping was an imperfect match (since Heater Cooler lacks "Auto"). Ironically, that also means that the bug here isn't actually that we're not sending "Auto,” but that we're presenting the "Auto" option at all.

In any case, all of that is why fixing this properly may take some time.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you very much for the quick reply — I read it in an instant like an interesting book, and it was really interesting to learn the history behind those HAP services. Honestly, I don’t think I’ve ever met a single person who was fully satisfied with the Matter standard; it seems the creators of Matter did a colossal amount of work to foresee absolutely every scenario, so that nobody would ever get the idea of creating their own protocol because something is missing in Matter. :)

On the other hand, I can’t fully agree with you — Auto mode is needed, and as far as I can see, with the Thermostat device type Auto mode already works perfectly in the Home app. Given that both the Room AC and Thermostat device types (naming the device type and its main cluster the same was an unfortunate choice — how many misunderstandings it has caused ;) ) are driven by the very same Thermostat cluster, from the outside it doesn’t look like a big change, though I may well be missing something: whatever mapping makes Auto work for Thermostat should apply to Room AC as well.

But getting back to the thermostat — are there any plans to fix this so that the Room AC device type becomes usable?

Thank you!

Thank you very much for the quick reply — I read it in an instant like an interesting book, and it was really interesting to learn the history behind those HAP services. Honestly, I don’t think I’ve ever met a single person who was fully satisfied with the Matter standard; it seems the creators of Matter did a colossal amount of work to foresee absolutely every scenario, so that nobody would ever get the idea of creating their own protocol because something is missing in Matter. :)

Yes, I think that's a not unreasonable perspective. The problem with a standard that's for "everyone" is that you can't really tell anyone "no"... because then they won't be able to use the standard. Add enough different people (or, in this case, accessory types) and pretty soon you end up closer to "encyclopedia", instead of "book". Having said that, the HID spec has similar issues for similar reasons, so this isn't necessarily a bad thing.

On the other hand, I can’t fully agree with you — Auto mode is needed, and as far as I can see, with the Thermostat device type Auto mode already works perfectly in the Home app.

So, to be clear, what I was describing is the context of why the issue was occurring, not claiming the behavior was correct. One thing to understand here is that the reason these mappings exist and are fairly "rigid" is that HomeKit is designed so that commands can be sent over a very broad set of transports (direct from the controller, from the controller to the Home Hub, from the controller to the cloud to the HomeHub...) in a way that's intended to be invisible to the user. Keep in mind that different devices can also be running different system versions, so any change in command behavior means both updating all of our operating systems and ensuring that any changes don't cause problems when older system versions are involved.

These issues also have a huge impact on what changes are considered "safe" enough to be in a software update ("26.x") instead of being held for a major system release ("27.0"), which receives significantly more testing. One thing to understand here is that managing the "safety" of a given bug fix is THE single biggest factor in determining when a particular bug fix is available in our public releases.

It's possible there's a safe way to get this working properly, but if there isn’t, then the safer option would be to remove "Auto".

Given that both the Room AC and Thermostat device types (naming the device type and its main cluster the same was an unfortunate choice — how many misunderstandings it has caused ;) ) are driven by the very same Thermostat cluster, from the outside it doesn’t look like a big change, though I may well be missing something: whatever mapping makes Auto work for Thermostat should apply to Room AC as well.

I think the thermostat device type works because it's using HAP's "10.8 Thermostat", which would actually be problematic as well if you were to try to use a "Heater Only" or "AC Only" thermostat. However, in practice that doesn't actually happen — virtually all smart thermostats are dual-mode devices, so the issue doesn't come up.

As an aside, if you're working with the accessories firmware, then it's very likely that the issue is avoidable by altering how the accessory presents itself. I'm not an expert in the Matter spec, but it looks to me like Room AC is really just a more standardized composition of the HVAC types. Indeed, my guess is that it primarily exists because it's expected that there’ll be a significant number of Matter ACs (I have actually have one myself) and heaters, and they wanted to provide a more standardized "pattern" for those accessories to follow.

But getting back to the thermostat — are there any plans to fix this so that the Room AC device type becomes usable?

Unfortunately, Apple's future plans aren't something I can really discuss. I can confirm that it's a bug, but I can't provide any specific guidance about if/when it might be addressed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware