SO, let me actually start here:
I can easily find all accessories which are wifi attached by using: isBriged == false and uniqueIdentifiersForBridgedAccessories == nil
Unfortunately, that doesn't actually work. First off, HomeKit also supports bluetooth and thread as native transports, neither of which will be bridged. Note that "HomeKit over thread" is NOT the same as "Matter over thread".
Further complicating things, it doesn't actually work for bridges either. It'll work "well enough" that you can trick yourself into thinking it does work, but it will miss identify lots of accessories. The issue here is that HAP (HomeKit Accessory Protocol) basically defines a bridge as an accessory that publishes more than one accessory as part of itself. Most of the accessories that work like that are bridging between protocols (true "bridges"), which makes it seem like it works under "basic" testing.
However... there are edge cases. Off the top of my head:
-
There are accessories that have been allowed to present themselves as bridges which are NOT in fact bridges at all, simply because that was the only way for the accessory to reasonably function. For example, some HVAC units work by using servo controlled motors to open and close individual vents, often using control wires run through the vent tubing. That unit is in fact a single accessory, but it's presents itself to HomeKit as a bridge because that's the only way it could put individual vents in the room they belong in.
-
There are multiple (unlicensed) products for "presenting" accessories to HomeKit and many of those products present they're accessories as bridge regardless of the underlying protocol.
That leads to here:
I'm trying to browse my Homekit accessories and try to show the different accessories communication protocols, i.e. Wifi, Thread, Zigbee, Z-wave! Zigbee and Z-wave I can have hard-coded depending on model because I have so few! But….
As things stand, I don't see any reliable way to do this as, by design, HomeKit has never exposed the underlying transport bus. Any attempt to infer state is quickly going to fall apart as edge case proliferate.
Case in point:
However, I can see that some of the accessories are thread enabled (I have read the documentation for the accessory) but still in the list. So, my questions: Are there any attributes in the accessory that is unique for a Thread accessory?
No and, again, the edge cases make this very messy. For example, the obvious approach would be to infer thread based on Matter support and, again, that approach would appear to work reasonably well. Currently, most matter accessories use thread, so it's easy to assume matter means thread. However...
-
HomeKit supports Thread as a transport layer.
-
Matter supports WiFi and bluetooth as a transport layer.
...and I'd expect both of those cases to become more common over time, particularly Matter over Wifi.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
