Posts Tagged ‘IOS’
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?
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).
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]