HomeKit is Apple’s entry into the smart-home arena. Following in the footsteps of Google’s recently acquired Nest system (as well as Google’s seemingly forgotten Android @Home initiative), Apple now provides an SDK as well as certification for smart devices in a more contextually aware home.
Apple announced HomeKit back in June, during its annual WWDC conference. The system will allow users to seamlessly hook up smart devices via Bluetooth or Wi-Fi. What will this look like in your home? Well, imagine everything from a toaster than can alert you when your bagel has popped up to a system that adjusts the lighting and turns on the television when you enter a room.
As with its HealthKit, the focal point of Apple's HomeKit initiative is a unifying protocol--standardization via a singular SDK--to act as the conduit for devices or gadgets to communicate with iOS. This goes along with the consistent theme we have seen in iOS 8 and OSX Yosemite: contextual awareness through technologies such as Continuity or handoff. Via HomeKit, smart devices know when you are in a room, when you are going to use something and when you are finished using something--and take action accordingly.
Building the Home of the Future
We don't expect HomeKit to explode in popularity and use--at least not right out of the gate--but Apple's (and Google's) weight will certainly go a long way toward boosting the smart home market.
Apple has given us the SDK; now all we have to do is figure out what to do with it--that is, coming up with creative ways of unifying home appliances and gadgets with iOS. There are some obvious candidates for "smart-enablement," in the home, including thermostats, garage door openers and cameras. But developers should also think outside the box--perhaps working to build an automated pet feeder or backyard grill.
Developers should also be keeping in mind future Apple TV software, as well as the much-awaited release of the Apple Watch (slated to arrive in 2015). Both of these systems will have some sort of interaction potential with HomeKit, paving the way for more interesting and contextual apps and projects.
For our pet how-to project, we will actually create a pet feeder (pun intended)--a hypothetical accessory that stores pet food, sets storage temperature and dispenses food to your dog or cat.
Getting Started
Class Hierarchy
It’s important to first familiarize yourself with the various classes that are part of HomeKit, and understand how each class and subclass relate in the hierarchy.
The most prominent class is HMHomeManager, which represents a collection of one or more homes (locations). Within that collection, each house is represented by an HNHome, with each room represented by an HNRoom.
Each room can contain one or more accessories (HMAccessory), which are the actual physical home automation item.
Looking at the individual Accessory (HMAccessory), it would normally expose or provide a service (HMService) such as "roll down the garage door" or "turn on the security camera." Services belonging to an Accessory are grouped as a HMServiceGroup, making it easy to address accessory services as a single logical entity.
Accessories are also organized according to zones (HMZone). This allows developers to group parts of the home according to different locations, such as kitchen or second floor. This provides indicative metadata to allow you to direct communications toward a certain area of the home. (This also plays in well with Apple's Siri voice-enabled app, which will become evident later on.)
Finally, each service is made up of specific attributed characteristics (HMCharacteristic), which expose certain properties for interaction--such as a Boolean (on or off, yes or no), string or floats--to signify a certain state of the service (for example, whether it's turned on or what the current temperature of the accessory is).
Classes
(Source: Apple Dev)
Class | Abstract |
|---|---|
| |
An | |
An | |
| |
An | |
An | |
An | |
An | |
An | |
A home manager object manages a collection of one or more homes. | |
An | |
An | |
An | |
An | |
An | |
An | |
An |
Protocols
Protocol | Abstract |
|---|---|
| |
The | |
The | |
The |
Setting Up the Environment
We are building a simulated accessory, so we will use HomeKit’s Accessory Simulator, which comes bundled with XCode. (The system may prompt you to download it if it hasn’t been downloaded already; it can be accessed as follows: Choose Xcode > Open Developer Tool > HomeKit Accessory Simulator.)
To add the pet feeder device to the simuator, select Add and choose New Accessory. Then, set its properties, from manufacturer to serial number:
You will then be presented with:
During our tests, we then set the Service to expose a switch that would determine whether the feeder is On or Off. (Set to On during vacation, of course).
Next, we set Characteristics, which let us control the accessory. We started by setting up the ability to control the temperature of the device.
We added another Characteristic that will let users read the temperature of the accessory.
We set up a custom Characteristic type, setting float as the type format for Celsius. We also set maximum and minimum temperature points, as well as the step value (or incremental value). We used a freely available online generator for the UUID, but you can also use the NSUUID class in Cocoa to generate a unique identifier.
Easy enough, right? We'll cover the coding aspects of HomeKit in greater detail in How to Code the Home of the Future with HomeKit.
