Home Alone with HomeKit — Part I
X10 and how it scarred me.
I was thrilled when Apple announced HomeKit, home automation is something I have been patiently and unsuccessfully trying my hand at for almost twenty years. When, many years ago, I first looked into home automation, the tech of the day was something called X10.
X10 was a really clever idea, remember in those days there was no ubiquitous internet, and there was no WiFi. X10 relied on the existing cabling that was used to transmit electricity. There’s a certain logic to this, everything that is capable of being automated also requires power to drive that automation, so exploiting existing copper infrastructure was smart. Now, as I am sure you all know, we generally don’t transmit electricity over copper as DC ( direct current ), we use AC ( alternating current ) although you might be surprised to know just how many electronic devices actually use DC. Using DC to transmit electricity is just not efficient ( although these days it can be done, and is sometimes better for really long distance transmission). Given that we use AC for transmission to the consumer, some bright spark realized that since most domestic current uses two out-of-phase waves of power to motivate electrons to scurry along the copper, there is a point in time in every cycle where there is no transmission occurring on the wire.
During this period of quiet, a device can happily and clearly transmit whatever signals it likes across the power network in your home, as long as it is quick about it. That’s the concept of X10 in a nutshell. Clever idea. HORRIBLE implementation.
Farm Life and the Hard Lessons of Triple Phase
In those days I lived on a farm, and I used to spend ages walking around turning water pumps on and off, and ensuring that gates were closed. I had these grandiose visions of sitting at my Power Mac G5 in my study, using a sexy little Cocoa application I was planning on writing, to turn my water pumps on and off, and to poll the gates and close them if necessary. Wow, was I ever wrong. Nonetheless I purchased the necessary kit from the US but when it arrived, I was horrified to find out I had to talk to an RS232 serial interface. We are not talking about USB here folks, we are talking about a really clumsy slow protocol that transmits one bit at time down the wire, and it was not duplex. If someone was talking down, no-one could talk up. I had developed software before to talk to a REUTERS data feed on a serial interface, and it was hell. It took me ages to get right and debugging it was a nightmare. So I quaked. Nevertheless, I perservered and eventually, <fanfare> I was able to switch a light on in the next room from my Mac with code I had written in C. Now for the house, or so I thought.
My next attempt was to get a lightbulb switching on and off upstairs, while I remained downstairs in my study, BUT — IT — WOULD — NOT — WORK. It baffled me, it worked perfectly if all the kit was downstairs but it would not work upstairs. Eventually after trying everything I could think of, and polishing my code, I gave up, because this was becoming too hard and taking too long. It was only many years later that an electrical engineer friend of mine explained why. As I mentioned I lived on a farm, and farms make use of triple phase electricy. What had transpired, was that the electrician who wired the farmhouse had used cycle 1 and cycle 3 to power the ground floor, and had used cycle 1 and cycle 2, to power the first floor, naturally the X10 device only had half a circuit when trying to talk upstairs, of course it didn’t work. I thought it was just because I was useless at programming serial interfaces ( well that’s probably true ), but at least the fault was not mine.
Things have improved considerably.
I’m pleased to say the experience in the modern age is much improved. What finally convinced me to explore HomeKit was an advertisment I saw on takealot.com. They were advertising a Phllips Hue Starter Kit for just under R3,000. When I consider the time and money I wasted on X10, this was a bargain. So when my package finally arrived, I was excited to get going, but nervous after my experiences of the past.
A word to the wise, if you decide to go this route, perform two checks I neglected to make. Ensure that the Kit or Accessory you purchase fits the sockets you have in your home, and secondly, that it comes fitted with a plug that works with South African power sockets.
The Phillips Hue Starter Kit
The Kit I purchased contained a Bridge ( which we will get to shortly ) and two Phillips Hue Light Bulbs. It never occurred to me that they might send me screw-in bulbs when most of us use bayonet fittings for light sockets. Alas, I received two screw-in bulbs, but was surprised to find that two of the lights I had earmarked for automation were in fact screw-in bulbs. I also purchased an additional two bulbs, fortunately both of those were bayonet fittings. The Kit comes with a Bridge that talks the HAP ( HomeKit Accessory ) Protocol, a transformer to power the Bridge, an Ethernet cable for connecting the Bridge to a network ( so make sure you have a free RJ45 port somewhere ) and a VERY slim manual.
The Phillips Hue lightbulbs talk a private protocol over WiFi, I think one of the reasons for this being that Apple demands that all HomeKit Accessories that talk directly to apps on iOS are not only certfied by themselves, but also contain an Apple Authentication Coprocessor. Apple takes privacy and security very seriously, and quite frankly given the opportunities for malicious use of IoT, I think their concern is appropriate. Of course, they are also looking to get their slice of the Apple pie.
Apple’s HomeKit
HomeKit’s concepts are few and simple. There’s HAP, the HomeKit Accessory Protocol, a bespoke protocol developed by Apple, which is documented, freely available, and free to use for non commerical purposes. The protocol has two carriers, IP or Bluetooth. HAP is used by Accessories, which are pieces of hardware ( or perhaps as we discuss later, software ) that directly interact with HomeKit on iOS or tvOS. Additionally there are situations where devices don’t necessarily want to talk directly to HomeKit ( the Phillips Hue bulbs are a good example), in that case a Bridge will interface with HomeKit via HAP and “publish” the private devices via HAP to HomeKit. In order to automate HomeKit you need a HomeKit Hub which may need to be some device other than your iPhone ( more on that later ).
Making it all work together
Connecting the Hue Bridge to my iPhone was a trivial exercise, Apple has given a lot of thought to how an average non technical user will cope with this, and they have a number of mechanisms to facilitate the pairing of an Accessory and HomeKit. Many of the Accessories have QR codes on them or their packaging and the HomeKit App on iOS lets you simply scan the code and have them pair that way. Alternatively if the Accessory is Bluetooth enabled you can just hold your iPhone near it, and if they can discover each other they pair that way. The third way is by means of an identification code associated with each Accessory, typing the code in on your iPhone initiates their discovery. The final way is for devices that directly talk HAP. HomeKit scans the network and uses Bonjour ( Apple’s DNS based publication service ) to try establish a connection.
So in no time at all I had the HomeKit application configured and my lights working. The HomeKit app on iOS has a simple but elegant interface that allows you to group your Accessories by room or by favourites. The primary interface shows you what is configured, what’s on and allows you to control the details of each Accessory by pressing and holding the icon representing the Accessory in question.
Automating Your Accessories
Automating your Accessories presents an interesting problem, in order to schedule automation events, the device generating the automation events needs to be in the same physical location as the Accessories ( after all sunset where your iPhone is, may not be sunset where your home is ). This means you can not use your iPhone to do this unless you never move it out of your house ( which is quite unlikely ). Hence, to do automation of your Accessories, you need to define what is known as a HomeKit Hub. A Hub can be any iOS device that never leaves your home ( such as an iPad you leave at home ), or a tvOS device. Setting my Apple TV up as a HomeKit Hub was really simple, I had to navigate to Home Kit in the tvOS settings app and turn Home Kit on, and then reboot the Apple TV. There is however a caveat :- HomeKit uses iCloud to share it’s pairings and configurations, which means you have to be signed in under the same iCloud account on your HomeKit Hub as what you are signed in on your iPhone. The simplicity of this mechanism for distribution of your HomeKit configuration is both an advantage ( because it’s so simple ) and a disadvantage ( because sharing your Apple Id like this may not always be convenient ).
Being able to use an Apple TV as a HomeKit Hub is really quite useful. Once you have defined your Hub, you are able to use the Home app on your iPhone to set up automations. This is really cool because if you are away from your home, your Hub can perform any set of operations at specified times, such as Sunrise, Sunset or any other time defined by the Hub. The automation also includes support for simple GeoFencing, in that you can add conditions such as “When Everyone Leaves Home”, in that case HomeKit will monitor when everyone that it knows about ( not necessarily everyone in the house mind ) leaves the house, and then initiate an action.
Now for the Fun Bit
Of course, as developers, creating our own software is always more fun than using someone else’s. In order to develop software for HomeKit you will need a Mac with at least Xcode 6 installed, and membership of the Apple Developer Programme. You may be thinking at this stage, that if you don’t have any HomeKit enabled Accessories, there is nothing you can do, well not quite. Apple thought of that, and very kindly created the HomeKit Accessory Simulator. This is a really neat application that allows you to create virtual accessories on your Mac for you to play with when you are writing code. Of course, if you do have HomeKit Accessories on your network you can test your code with them as well.
The HomeKit Accessory Simulator does not come preinstalled with Xcode, you will need to download and install it yourself. Sign in to your account on developer.apple.com, and navigate to the Downloads section. At the bottom of the page you will see a link that says “Don’t see what you are looking for, See more downloads”. Click on that link and expand the link that is labeled “Additional Tools for Xcode 9”. Here you will find a link to a DMG file called “Additional Tools for Xcode 9.dmg”. Download this dmg, mount it, and copy the “Xcode Tools” folder into your Applications folder. In the “Hardware” folder of “Xcode Tools”, you will find the HomeKit Accessory Simulator. Running this application will give you a window that looks like the image below. Use the File menu to create as many Accessories or Bridges as you wish.
You can for example wrap your monitor camera in a HAP wrapper by using the “File >> New >> IP Camera…” menu item, as shown in the image below :-
An Alternative Simulator
The Apple HomeKit Accessory Simulator got me thinking, HAP is just a software protocol, and Macs speak IP and Bluetooth perfectly, so what if one wished to take a non HomeKit enabled component ( such as a Raspberry PI,a feed from the Cloud or something else of that nature ) and make it look like a HAP enabled Accessory, how would one do that ? The first thing I did was take a quick read of the HAP protocol specification. It’s long, detailed and looked like a lot of work to implement from scratch, but I was certain that someone must have been thinking along similar lines to me and implemented it. Sure enough, a few minutes of searching on the internet and I found the following on GitHub
This is a nicely documented and virtually complete implementation of the HAP protocol in Swift. It makes use of the Kitura Web Services framework from IBM and provides a really nice base to start working from. The project was developed using the SPM ( Swift Package Manager ), which is an alternative way of managing dependencies to CocoaPods and Carthage. Personally I’m a big SPM fan, but if you haven’t developed for Swift on Linux you may not have explored SPM yet. Before I could generate an Xcode project from the SPM project, I needed to install libsodium ( an open source cryptography library ), but this was easily accomplished using HomeBrew ( brew install libsodium ). Once that was done I had to generate the Xcode project using the SPM ( swift package generate-xcodeproj ), I didn’t need to do this because I could have built the package from the command line using SPM ( swift build ) but I wanted to look at the code, and Xcode was the best for that. After I had generated the Xcode project I found that some of the dependencies were a bit out of date for Swift 4, and it took me a while to update the Package.swift file before I could get the project to build. My Package.swift file ended up looking like the one below, changing the version numbers of the packages the project depends on to the ones below allowed the project to build cleanly ( not without warnings, but without errors ).
After tweaking the name of the Swift HAP Bridge, and building and running the hap-server scheme in Xcode, I was able to successfully find the bridge ( Sapphire Swift Bridge ) in my Home app on my iPhone and add all the ( virtual ) accessories from the virtual bridge ( as you can see in the image on the right below )
This is a really neat way of adding custom solutions to your HomeKit ecosystem. For example, there are a limited number of IP cameras that currently support HomeKit, but I’m planning on buying one with an API and then writing a Swift virtual Accessory for it using this toolkit and integrating it into my HomeKit ecosystem that way.
Part II of this article will explore using the HomeKit Framework supplied by Apple.
