4 Implications of Apple’s HomeKit

HomeKit defines a language, API, taxonomy (albeit for IOS devices only) to discover, pair, and control home automation devices (more about it here). The technology is very interesting, but it has implications and raises questions:

1. AllSeen/AllJoyn defines a protocol for a proximal network (i.e. local to the premise) and is limited to Wi-Fi with some support for Bluetooth. HomeKit is solving a very similar if not identical challenge. What would manufacturers prefer – AllJoyn/AllSeen or HomeKit? With limited resources would they give priority to AllSeen/AllJoyn?

2. The basis of HomeKit, appears to be a common database where information on the Accessories is stored – there location within home, the common name given to them, rooms they are in etc. Would for example the IOS App for Comcast Xfinity Home or AT&T Digital Life be willing to give access to their devices to other app developers? I am willing to bet because their solutions are anchored on professionally managed security, they probably will not.

3. AT&T and Comcast (as an example because their home automation & security service is widely deployed in the US) may not open up access to devices their systems control in their IOS apps however consumer apps for Philips Hue or NetAtmo using HomeKit would probably allow access. Do you think the likes of Philips Hue or NetAtmo would be ok with that? Or would be their policy controls in place during app approval or access controls allowing some degree of control to Philips and NetAtmo as an example?

4. HomeKit will have complex scripting capabilities – going beyond what IFTTT can do. HomeKit possibly solves the software challenge much better than Revolv with its consolidated app for controlling many things through its hardware (in reality controlling the Wi-Fi or Ethernet connected devices such as Philips Hue or Sonos does not require their hardware/gateway). What role do companies like IFTTT (from a HomeAutomation perspective only, not the many other functions it provides. IFTTT has simple if-then rules only today operating through the latency of an internet connection) or Revolv play with HomeKit? Did Apple disintermediate the likes of IFTTT for Home Automation and Revolv?

Advertisement

8 Things to know about HomeKit

I had an opportunity to review Apple’s HomeKit (by reading here, here and here), here is a short summary of what it is, and how it works:

1. HomeKit is positioned very well to solve the the “App Fragmentation” problem on the IOS device – it is a framework that will enable having an application that can control multiple Home Automation devices through a single User Interface. The foundational premise of HomeKit for solving the challenge is to have a common database, and a common taxonomy. Apps using HomeKit will store the information related to the Home Automation devices (or Accessories as Apple calls them) in common database locally on the IOS device. Apple is enabling developers to go after the really hard part of having the best user experience of using home automation by coming up with HomeKit.

2. Apple with its HomeKit has defined a common language and hierarchy to discover, define, and communicate with devices – or what are called “Accessories” in the Apple parlance. The root of the hierarchy starts with the “Home”, then works its way down to the “Room” and to “Accessory”. Accessory is the “thing” – the lamp or the switch that controls the lamp – and it has characteristics. There are ’services’ associated with Accessories.

3. Zones, Scenes, and Service Groups can be created.

4. HomeKit supports APIs for discovering, pairing, and organizing accessories, and associated actions with them using the extensive, but simple to use HomeKit framework. Accessories, and services to an extent can be assigned names – and here is the interesting part – because they have ‘names’ – Siri can be leveraged. Xcode will support a simulator that would mimic accessories supporting the HomeKit protocol – allowing developers to get started.

5. Common accessories such as Garage Door Openers, Lights are defined and to open up the eco-system – both Custom Accessories and Custom Services can be defined by manufacturers and partners.

6. There is “HomeKit” protocol defined between the IOS device and the Accessory (or the thing/device). The APIs on the HomeKit leverage this protocol to communicate with the accessory.

7. While no specific mention of ZigBee or Z-Wave was made, non-HomeKit accessories or things will be supported using the notion of a “bridge” [for example the Philips Hue bridge, whose functioning I covered here]. The bridge would be a device or piece of software that can translate between the HomeKit protocol and whatever is on the other side.

8. My guess is that ‘licensing’ the HomeKit protocol is covered under the MFi program (just as AirPlay is Apple-licensed protocol).

 

Year In Review: Programming

Beginning of the year I embarked on a getting back in touch with my programming skills… and this year has been really successful. Here is what I accomplished, over the weekends and late nights:

·         I programmed extensively in first of half on the year on IOS, especially IOS5 and iPad. I still need to work on my design skills but I covered a lot of ground Table Views & Controllers, Storyboards, Network Programming, XML parsing, Notifications, Pull To Refresh etc.).

·         I refreshed my programming skills in Java by programming in OSGi Embedded environment…

·         And to complete my journey – I signed up for courses with edX and Coursera on Cloud Programming. I would have liked to do a project or two of mine but I had to be satisfied with the assignments and the tests that were done as a part of the course. I ended up learning about R, Ruby and Rails. I had signed up for a few courses but the three that I completed were:

o   CS169.1x Software As A Service @ edX

o   CS169.2x Software As A Service @ edX

o   Computing for Data Analysis @ Coursera [Data Analysis using R]

How to learn XML, HTML or for that matter anything in Programming

Over the last several years I continued to buy books on XML and HTML, and all of them went unread. This year I did end up learning both XML and HTML but NOT by reading books but by programming. In my recent hacking & prototyping projects with IOS and OSGi I had to use XML and HTML to exchange information between devices. I had to read and learn how to use NSXMLParser in IOS, it came with an excellent companion guide – “Introduction to Event-Driven XML Programming Guide for Cocoa” which was useful reading. I leveraged the hpple XML parser. Note the real learning came from my own programming, not from the tutorial or examples from books or websites. The real trick to learning XML and HTML was to understand how they are defined by observing the code working, iterating through several failures before I met with success. 

My 2c – yes read a programming, follow tutorials and examples from websites but the real learning comes when you embark on your own project! 

 

Footnotes:

– Google Search, Stack Overflow, Github and many other sites also serve to accelerate your learning only if you understand the solutions put forth by the community and adapt it to your own project. Blind copying never helps!

– Github is awesome!!!

– hpple is a great resource, I learnt the basics from the Ray Wenderlich tutorial: How to parse HTML on IOS by Matt Galloway 

User Interfaces & Interactions

User Interfaces & Interactions, including touch & gesture based interfaces will always be subject to individual bias, experience, style, and preferences. Individuals using new interfaces either because of it being on a new device (e.g. moving from Blackberry to iPhone) or a changed interface on the existing class of device (e.g. Blackberry Bold – Keyboard to Blackberry Storm – Touch) will learn to adapt – most people do so assuming that they are not turned off to give up the device entirely (either due to other functions such as Phone Call Quality or having compelling features forcing them to adapt to the new interface). 

Adaptation happens, I can safely say based on my own experience and those of my network – family, friends, and colleagues. For example several friends of mine initially remarked that they had trouble using the iPhone’s soft keyboard compared to physical keys of a Blackberry. Over a period these folks have gained a liking to the soft keyboard and adapted to it. This adaptation could be natural – they learn to adapt, and get better at it with each use (like learning anything – Golf for example). Or the adaptation could be ‘forced’ – that is you use the interface and ‘compromise’ with it because of other features on the device. One may learn to deal with the Apple iPhone soft keyboard because of the number of applications available on it. I for one still struggle using Soft Keyboards and I am sure there are others like me. I think interfaces, even touch, will be highly subjective to individuals. 

Apple’s single button for navigating the user interface on the IOS devices at times is constrained. Are consumers able to adapt and use it effectively – absolutely yes! But that does not imply that it is easiest way or the most intuitive way. And Apple may even move away from that one Button given the current release of IOS – 4.3 supports Multi-Touch gestures (I tried them and they work absolutely great – even better than using the Home Button).

Minimalism in design does not translate to simplicity. In other words, just because the device has minimal or one or no buttons, does not imply it is easy to use. Ease of use, or simplicity is a function of features, and the context of it being used. Assuming you are in a bus, with one hand held above to anchor yourself, and you want to access an app. In the multi-touch version of IOS – you have to use 4 or 5 fingers to ‘swipe up’ on the screen and then select the app to launch. Try doing that with one hand…  If this example is not practical enough imagine trying to call somebody by looking them up using one hand on a touch screen. That exercise can be made ‘simple’ by a search button – not a web search – but being able to search for anything – any contact, any app by touching the search button. I like that about my Nexus S and use it frequently. Search is not just about web search – but finding information on the device itself. And as we live more of our life in the Smartphone or Tablet – being able to search easily is critical.

Independent of buttons, simplifying use and removing redundancy is beautiful –  I find the extra press of “OK” after entering the 4-digit security code annoying on my Nexus S compared to an IOS device ….

————————

Notes:

Post Inspired By, and kind of response to Ross Rubin of NPD wrote an excellent blog post on the subject of buttons and touch-enabled devices.

Must Read: “Living With Complexity” by Donald Norman