Every tech monopoly has their own proprietary smart home standard; how better to lock in your customers than to literally build a particular solution into their homes? Among the these players Apple is traditionally regarded as the most secretive, a title it has earned with decades of closed standards and proprietary solutions. This reputation is becoming progressively less deserved when it comes to HomeKit, their smart home gadget connectivity solution. In 2017 they took a big step forward and removed the need for a separate authentication chip in order to interact with HomeKit. Last week they took another and released a big chunk of their HomeKit Accessory Development Kit (ADK) as well. If you’re surprised not to have heard sooner, that might be because it was combined the the even bigger news about Apple, Amazon, the Zigbee Alliance, and more working together on more open, interoperable home IoT standards. Check back in 2030 to see how that is shaping up.
“The HomeKit ADK implements key components of the HomeKit Accessory Protocol (HAP), which embodies the core principles Apple brings to smart home technology: security, privacy, and reliability.”
– A descriptive gem from the README
Apple’s previous loosening-of-restrictions allowed people to begin building devices which could interact natively with their iOS devices without requiring a specific Apple-sold “auth chip” to authenticate them. This meant existing commercial devices could become HomeKit enabled with an OTA, and hobbyists could interact in sanctioned, non-hacky ways. Part of this was a release of the (non-commercial) HomeKit specification itself, which is available here (with Apple developer sign in, and license agreement).
Despite many breathless mentions in the press release it’s hard to tell what the ADK actually is. The README and documentation directory are devoid of answers, but spelunking through the rest of the GitHub repo gives us an idea. It consists of two primary parts, the HomeKit Accessory Protocol itself and the Platform Abstraction Layer. Together the HAP implements HomeKit itself, and the PAL is the wrapper that lets you plug it into a new system. It’s quite a meaty piece of software; the HAP’s main header is a grueling 4500 lines long, and it doesn’t take much searching to find some fear-inspiring 50 line preprocessor macros. This is a great start, but frankly we think it will take significantly more documentation to make the ADK accessible to all.
If it wasn’t obvious, most of the tools above are carefully licensed by Apple and intended for non-commercial use. While we absolutely appreciate the chance to get our hands on interfaces like this, we’re sure many will quibble over if this really counts as “open source” or not (it’s licensed as Apache 2.0). We’ll leave that for you in the comments.
I made a smart home bridge. Just need a Mac and Indigo home automation.
https://github.com/jsammarco/IndigoHomekitBridge
http://consultingjoe.com
HAP is the protocol, ADK is the implementation of the protocol. Previously, Apple has distributed only the protocol specification (and only to licensed developers), but there was at least one well known third-party implementation – OberonHAP, which was also available only to Apple-licensed developers.
It just so happens that the CONTRIBUTORS file in ADK lists “Oberon microsystems AG” as the first contributor, so it would be reasonable to guess that ADK is based on rebranded OberonHAP code.
The 4500-line header file is mostly comments, and pretty well written comments at that. Would separate documentation be better? Of course. But it’s hard to complain about the code that they’ve given us.
Yeah, it really is, when you add laser:
https://www.youtube.com/watch?v=ozIKwGt38LQ
The code has been published under an Apache license, so welcome to the non-free-rider side of Open Source: if you want more or better documentation, you have a legally protected right to study what’s there and publish your own.
The much-touted strength of FOSS is that many people working independently can contribute to a project, and the accumulated sum of those contributions makes the project better for everyone. FOSS is not and never will be justification for free riders to sit around demanding that ‘someone’ create what they want, then hand it over to ‘the community’ for free-as-in-beer.
The FOSS community has a duty to walk its own talk in situations like this. If we want companies like Apple to take FOSS seriously, we have to stand up and say “let’s contribute to this.” If we don’t, it will become accepted wisdom that ‘Open Source’ means ‘Open call for free riders with lists of demands’.
This is an area of controversy about exactly what the ‘FOSS community’ means; but there’s an argument to be made that walking one’s talk in this case would involve examining this software for anything useful; but then running away as far as possible.
From the documentation:
“It can be used by any developer to prototype non-commercial smart home accessories. For commercial accessories, accessory developers must continue to use the commercial version of the HomeKit ADK available through the MFi Program.”
So it’s open source as long as you only want to tinker with your eccentric little nerd ecosystem; but all the historic restrictions continue to apply if you want to actually get anywhere near the portion of the market where Apple sees its ecosystem interests as giving it considerable power.
If the software turns out to be better or easier than the current standard for roll-your-own-automation-devices then that is certainly a plus; but this is overwhelmingly one of those situations where ‘Open Source’ is being strategically deployed by a vendor that has zero interest in letting go of their grip on an area, pretty much as an alternative to the more traditional free/cheap and crippled personal/prototype-kit licenses one sees.
Especially since all commercial development is required to be based on the commercial ADK it’s far from clear that Apple would even want external input, with the possible exception of work that is fully given over to them such that they can incorporate it into their proprietary branch without issue.