HomeKit Concepts

Apple’s HomeKit is a platform that allows you to control your home directly from your iPhone or iPad. You can do things like turn on and off the lights, control your central heating, and collect data about the home environment. Unfortunately, it doesn’t seem to be terribly well documented so far, so I thought I’d have a dig through the developer documentation and see if I could explain the concepts in a slightly more friendly manner. Mostly this is so that I can get the concepts right in my head, but I thought it might be useful to others, too!

There are lots of nouns used to describe the various bits that combine together to make up a HomeKit home. We’ve got homes, rooms, and zones, for organising our devices in a way that makes sense to us. Then there are the devices themselves (Apple calls them accessories), which sometimes live behind a bridge. Each accessory has services and characteristics that allow us to observe and control their behaviour. We can collect together services from different accessories into service groups so that we can control several things at once. Then we’ve got actions, action sets, and triggers, which allow us to control accessories when a particular event occurs. Finally, we’ve got the users of HomeKit. Let’s tackle the last one first since it’s the easiest one.

Users

In HomeKit, there is a primary user for a home. This is typically the person who sets up HomeKit for the household, and who then has control over the home layout (rooms, zones, etc). The user is identified through their Apple ID (iCloud login) so if you’ve got multiple devices — an iPhone and an iPad, for example — then you can maintain HomeKit from any of the devices you’re logged in from. I suspect the reason for having a ‘primary’ user is that the data about the home is stored on iCloud, and that data has to be associated with a single account.

The primary admin can invite additional guests to HomeKit. A guest can interact with accessories that have been set up already, so they can perform the normal operations that they’d want to in the home, like turning on lights, or changing the temperature of the heating. They can’t change the layout of the house, and I don’t think they can add new accessories. (I need to borrow a guest to test this out — the developer documentation says that guests can ‘identify accessories’ but I’m not sure if that refers to adding new ones, or just making the lights blink on existing accessories!)

The Home

All HomeKit devices belong to a single home. A user can have multiple homes, so you would typically have a home for each of the properties you want to control. For example, I might have an entry for the family home on the south coast of Devon, and another entry for the holiday villa in France (I wish!). You designate one of the homes as your primary home. You can then refer to stuff in that home more easily. This mostly comes into play when we start talking to Siri — if you ask it to “turn on all the lights in the house”, then it will apply the command to all the lights in your primary home.

Homes just have a name associated with them. I’ve used the first line of the address to identify ours. You can invite additional guests to a home, and you can be the admin of one (or more) homes while being a guest of others.

Rooms

A home can have multiple rooms, and each room belongs to a single home. These are pretty much as you’d expect. You can create rooms in thehome that correspond to each of the physical rooms in your home. An accessory always belongs to a room within a home, but if you don’t place it within a specific room, then it gets associated with the ‘default room’ of the home. I’m deliberately not using the default room at all. That way, when I add a new accessory, and I see it’s been associated with the default room, I know I need to move it to the room in which it really belongs.

We’ve got rooms in our HomeKit home to correspond to each of the rooms in the house — one for each bedroom, the living room, kitchen, bathroom and office. Our hallway is on three levels (we’re in a mid-terrace town house) interconnected with stairs, so I’ve represented that as three separate rooms: the upstairs hall, main hall, and downstairs hall. It seems useful to keep them separate, and we can combine them together again later in another way. I’ve also got a ‘room’ for outside the house called ‘Balcony’ where the weather station lives (which I’ll cover in another article).

Each room gets a name. You can use this name with Siri to refer to all the devices in that room.

Zones

We can group together multiple rooms within a house into a zone. A home doesn’t need to have any zones, but can contain several of them. A room within a home doesn’t have to be in a zone, but can be in several zones. This allows us to create logical groupings of rooms. Each zone just has a name, which we can then use to refer to all the devices within that zone.

In our case, I’ve created a zone for each floor of the house — upstairs, main level, and downstairs — and I’ve grouped together all the hall rooms into one zone called ‘Hall’. This means that I can issue commands to all the lights in a particular zone, telling Siri, “turn the hall lights on,” for example. This also illustrates the idea that a room can be in multiple zones — the downstairs hall is in the Hall zone and the Downstairs zone.

Accessories

Accessories are the physical devices in HomeKit. These are your lightbulbs, door sensors, room monitors and central heating controllers. An accessory belongs to a single room (the ‘default’ room if you don’t specify one) in the house. For example, in our living room, we’ve got four accessories: a door sensor that indicates whether the balcony door is open or shut, a couple of overhead lights, and an environmental monitor which tracks temperature, humidity, and air quality.

The process for adding a new accessory is pretty clever. (It feels especially clever if you’ve seen some of the other attempts that hardware manufacturers have come up with to connect devices to a secure home network!) When you get a new HomeKit accessory, you set the hardware up as required, and make sure it’s switched on. Then you launch your favourite HomeKit app on your iPhone and ask it to search for new accessories. The browser will automatically find unrecognised nearby accessories, and give you a list to choose from. You select the new accessory from that list. The app will then use the camera on your phone to take a photo of an ID printed on the accessory, and use that information to set it up.

That’s it. The device is now part of your HomeKit setup, and it’s communicating with your iPhone. (How it does that is still a bit of a mystery to me. I suspect there’s a mixture of Bluetooth Low Energy, Wifi, iCloud, the iPhone and possibly some involvement with the Apple TV that’s sitting in the corner of the living room. When I figure that out, it’ll be the subject of a future article!) You can even observe and control your accessories when you’re not at home, which compounds the mystery!

Services

Each accessory exposes one or more services to HomeKit. A service describes something that an accessory does. A simple accessory like a lightbulb might just expose a single service — that of the light itself. A more complex accessory might expose several services. For example, a room sensor might have services for a thermometer, an air quality sensor, and a humidity sensor. Battery powered devices will typically have a service that allows you to query the current state of the battery — whether it’s charging or discharging, if it has reached its low threshold, and the current charge level.

Services are defined by the manufacturer of the HomeKit accessory, so you don’t have any say in what services are available, and how they expose their data. You can supply a name for the service. In practice, I’ve found naming things to be a bit tricky — especially in finding unique names for accessories and their services — so I’ll talk about that a bit more in a future article. Apple defines a number of standard services for different types of sensors (CO₂, air quality, light, temperature, motion, etc) and actuators (switches, mostly).

Manufacturers can also define custom services, but hopefully these will be used sparingly! One of the beauties of HomeKit is that it disaggregates the hardware devices from the software that manages them. I can pick and choose which bits of hardware I want to use, mixing and matching accessories from different manufacturers, each of whom specialise in their own particular platforms. On the iPhone side, I can pick and choose whichever bit of software I like best for handling my HomeKit devices. (I’ll come round to apps in yet another future article!) Each of the phone apps is able to control all the hardware in my HomeKit home, so long as that hardware is exposing standard services. I’m not forced to use the crappy app that a hardware manufacturer had an intern write over the summer because they were obliged to provide something as an afterthought for managing the accessory. This is made possible because HomeKit itself defines the services and characteristics in a standard way. (This pattern has been used — and abused — for years. It’s the same sort of concept as USB class drivers, or Bluetooth profiles.)

Characteristics

Speaking of characteristics. These are the actual bits of data that an accessory exposes. In the case of a temperature sensing accessory, it might expose the ‘Current Temperature’ characteristic as part of its thermometer service. Most characteristics belong to a service, though there are characteristics defined globally on the accessory, too. These seem to be limited to general read-only information about the accessory (manufacturer, model, serial number, firmware version, that kind of thing).

Characteristics can be read-only, read-write, or write-only. The current value of a sensor would be a read-only characteristic. An actuator that doesn’t provide any feedback (e.g. a dumb switch) could be a write-only characteristic. A more intelligent switch, which was able to determine its own current state could be a read-write characteristic. To take an example, let’s look at an accessory for controlling the central heating boiler at home. We’d probably have a read-only characteristic which allowed us to gather the current temperature. We’d have a read-write one which allowed us to get and set the desired target temperature. And we’d probably have a read-write switch that allowed us to query whether the boiler was currently switched on, and to override its current state by switching it on or off.

The characteristics are hard-wired by the manufacturer, who gets to give them a description, a type (string, boolean, number, etc), the units associated with them (celsius, percentage, etc) and describe the acceptable range of values. Apple pre-defines a long list of standard characteristics which allow us to describe most of the things we’d want to monitor or control around the house. (Interestingly, energy usage isn’t amongst the predefined characteristics, and a measure of energy use isn’t amongst the standard units, which I’m hoping will be rectified in a future update!)

Bridges

The last piece of the puzzle for HomeKit is how to interact with devices that don’t directly speak the HomeKit Accessory Protocol. There are tonnes of home automation devices already on the market, and it would be a shame not to be able to make use of them. Manufacturers can offer a bridge device that sits between HomeKit and their own devices. It exposes their own devices to HomeKit in the standard way that it recognises (providing services and characteristics) then translates between them. In my case, I’ve got several Philips Hue bulbs around the house, which I’ve had for a while. I had the old bridge, which connected the bulbs themselves to the home network. (I could grumble about how I’ve had to buy a new bridge to HomeKit-enable them, when it feels like it should just have been a firmware upgrade, but I suspect HomeKit requires a Bluetooth LE radio, and the old Philips Hue bridges didn’t have one, so a hardware upgrade was necessary.)

The Philips Hue bridge talks its own native protocol to the lights and switches in its network (using Zigbee, I think). You can use Philips’ own app to interact with the lights using your iPhone. But the new bridge also exposes the lights to HomeKit, making their services and characteristics available to HomeKit for other apps to interact with. This means that I can use other HomeKit enabled apps on my iPhone and iPad to interact with the lights, and I can control them alongside all the other home automation devices around the house.

Putting it all together

It’s quite a complex model, really. But once we’ve got all the pieces in place, we’ve got a rich picture of what our house looks like, and what the current environment is like. I can tell you that it’s currently 17.9ºC in our kitchen (according to the central heating system’s thermostat), 19.1ºC in the living room, and 20.5ºC in our bedroom. All the external doors are closed, and the lights are all switched off. I can ask Siri to turn the hall lights on to light my way down to the kitchen when I finish up this article and head down to make a fresh cup of coffee.

I haven’t covered action sets and triggers yet, mostly because I haven’t started to play with them yet. I’m sure they’ll be the subject of a future article. Speaking of which, I’ve promised you a few future articles:

• An overview of the accessories I’ve evaluated so far in playing around with HomeKit.
• The iOS apps I’m currently using to monitor and manage all these accessories. The short version is that I’m using a combination of Elgato Eve because it’s delightful, and draws pretty graphs of historical information. I’m also using Home — Smart Home Automation because it exposes all the bits of the HomeKit model.
• A dive into action sets (often called ‘scenes’) and triggers for automating the house in response to events.
• I want to talk a bit about naming things (accessories, services, etc) and how that translates into things you can tell Siri to do, or to ask about.
• I want to dig into how HomeKit works in a little more detail. How does the setup process work? How do the devices communicate with your phone? Where is all the data stored? It all feels a bit magic to me, and I don’t trust magic. I like to know how things work, and how they’re likely to break!

I’ll link to these articles as I get around to them over the next few weeks. Meanwhile, if you want to keep an ear out for new articles, you can follow me on Medium, or follow @mathie on Twitter.

If you’ve enjoyed reading this article, I’d really appreciate it if you recommended it on Medium (hit the 💚 below) and shared it with your friends on Twitter. You might also be interested in reading my first article on HomeKitting out the House or a bit of background on what I’m trying to achieve, in HomeKit Goals.