Next month sees the launch of several highly anticipated HomeKit accessories, which were debuted earlier this year at CES. With HomeKit-enabled accessories finally coming to market, it’s time to create iOS apps that utilize Apple’s home automation APIs.
HomeKit is designed to bring an end to individual apps for smart home accessories. Gone are the days where you will be switching between apps to set up a perfect movie night scene; instead you’ll have one app, which communicates to all of your accessories using HomeKit.
HomeKit has a couple of core concepts that form the basis for the entire API. The general idea of HomeKit is that you interact with a Home, which has Rooms, which have Acessories, which have states. In order to get started, you’ll need to create a Home Manager. The Home Manager is your entry point to HomeKit – it keeps a common database of Accessories and allows you to manage your Home(s). It also notifies you of changes, which makes it easy to deal with changes to the HomeKit configuration from other HomeKit-enabled apps.
General Setup Tips
If you’re looking to test these APIs, it’s worth noting that you’ll need access to a physical iOS device running iOS 8 at a minimum. HomeKit doesn’t currently work within the iOS Simulator and the exception thrown doesn’t hint towards this. Because you’re running on the device, you’ll need to make sure you’ve set the entitlements for the project to allow for HomeKit. You’ll probably also want to grab a copy of Apple’s Hardware IO Tools for Xcode. The Hardware IO Tools for Xcode allow you to simulate HomeKit-enabled devices for testing your app. You can fetch this from the Apple Developer Center if you’re an existing member.
Creating a Home
To create a Home, we must first create an instance of the Home Manager.
var homeManager = new HomeKit.HMHomeManager();
Once we’ve done this, we can go ahead and add a Home to the homeManager object.
homeManager.AddHome("Guildford", (HomeKit.HMHome home, NSError error) =>
{
if (error != null)
{
// Adding the home failed. Check the error object for why!
}
else
{
// Successfully added home!
}
});
All Homes within your HomeKit configuration must have a unique name, so if we have two homes in the same city, it might be worth finding another naming convention. Homes must be uniquely named because we will be able to interact with them using Siri once Apple fully enables HomeKit (hopefully later this year). For example, we’ll be able to say, “Hey Siri, turn my lights off in Guildford,” and like magic, all of the lights in your Home in Guildford will be switched off.
Once you’ve added a Home, the DidUpdateHomes event will be raised. This allows other apps to ensure they’ve processed any new Homes that have been added to the database. We can subscribe to the event with the following API.
homeManager.DidUpdateHomes += (sender, args) =>
{
foreach (var home in homeManager.Homes)
{
var alert = new UIAlertView("Home...", home.Name, null, "OK");
}
};
Creating a Room
A Home also contains Rooms, each of which has a list of Accessories that are unique to that particular Room. Much like the Home, a Room can notify you about any changes and must also be uniquely named. This again allows you to interact with the Room using Siri. The API for creating a Room is almost identical to creating a Home.
home.AddRoom("Kitchen", (HMRoom room, NSError error) =>
{
if (error != null)
{
//unable to add room. Check error for why
}
else
{
//Success
}
});
Accessories
Accessories are where HomeKit starts to become a little more interesting. Accessories correspond to physical devices and must be assigned to a Room. They have a device state which allows you to query them. For example, you can query the intensity of a light fixture or the temperature of a thermostat. As you’ve probably already guessed, Accessories must be uniquely named, but this time only within the Home where they reside. Accessories will also notify you of changes to the state so you don’t have to constantly query them to ensure your app is up to date; one common event that you can be notified of is when the device is reachable.
accessory.DidUpdateReachability += (o, eventArgs) =>
{
if (accessory.Reachable == true)
{
//we can communicate with the accessory
}
else
{
//the accessory is out of range, turned off, etc
}
};
A few of the more interesting aspects of Accessories are Services and Characteristics. A Service represents a specific piece of device functionality. For instance, Apple gives the example that a garage door accessory may have a light and a switch Service. Users wouldn’t ever create Services or Characteristics as these are supplied by the accessory manufacturer, but it’s your job as a developer to make sure they can interact with the Services.
Action Sets and Triggers
Actions are by far my favorite feature of HomeKit. Actions and triggers allow you to control multiple Accessories at once. For example, when I go to bed I like to turn the lights off and turn my fan on. I can program this action with HomeKit to set the state of the Accessories and then use triggers to call the action. I personally have an iBeacon stuck to the underside of my nightstand which could detect my proximity and then call my action set for sleeping. As with almost every aspect of HomeKit, each action set has a unique name within the Home that can be recognized by Siri.
Conclusion
I’m extremely excited about the prospect of HomeKit evolving into the go-to solution for home automation. With HomeKit-enabled accessories finally coming to market, there’s never been a better time to create an iOS app that utilizes Apple’s home automation APIs.
To start integrating HomeKit into your apps today, check out our HomeKitIntro sample, which will give you everything you need to build amazing home automation apps with HomeKit.
0 comments