Posts Tagged ‘Home Automation’
Amazon Echo: Bringing Voice to Internet of Things
Amazon is investing heavily in voice recognition – the Fire TV, and now followed by Echo. I have signed up for an invite to buy the Echo – but what I am really waiting for is Amazon opening up developer access to the Echo. Echo could be the Home Butler, the Digital Assistant to automate and manage the home. It is a step in the right direction – pulling out your Smartphone to control devices is not ideal – yes you don’t have to get up from the couch to turn off the lights (with the phone that is) but asking “Alexa” to do so wouldn’t be just cool, but mighty useful!
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?
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 t
o 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).
IoT Stories (Week Ending May 31st 2014)
Pew Research Center recently released a report titled The Internet of Things Will Thrive By 2025. This was, obviously, picked up by many news and blog sites. Washington Post’s Mohana Ravindranath wrote about it in a post titled “Some see possible drawbacks in ‘Internet of Things’”, and provides a good summary. The post has one typo – it claims 1,900 people responded, whereas actually of the 12,000 people canvassed 1,606 responded. He has summarized inputs fromVint Cerf, Andrew Bridges, John Senall and Miguel Alcaine. Mohana has captured good set of quotes from one of the authors of the report – Lee Rainie, director of Pew’s Internet & American Life Project. Wired has good summary of the report as well.
Scot Stelter over at RFID Journal mentions the report but points out the lack of coverage in that report with respect to RFID, his post (RFID Stakeholders Need to Prepare for the Internet of Things) has good insight into how RFID will be important, and professionals in the RFID field need to be prepared for IoT.
Alain Louchez over at InformationWeek takes another Pew Research report and explains how the manufacturing in the US can benefit with the aging workforce and IoT.
Last week was the week before Apple’s WWDC – and lot of speculation on how Apple is going to play in Home Automation and IoT started out by Financial Times in Apple seeks to work Jobs magic on the internet of things (paywall). GIgaOm’s Stacey Higginbotham explains it well in Here’s how Apple’s smart home program will work. EETimes in “Apple’s IoT ‘Good Housekeeping’ Label: MFi “ gets into a little bit more detail and indicate that it involves around the MFi program (just as Stacey’s post) but indicate that it would support ZigBee protocol as well. Roger Kay at Forbes jumped in with “Will Apple Play Nice On The Internet Of Things?“. Roger makes the case that Apple won’t be in a position to dominate unlike the Smartphone or Tablet segment. While I agree with that analysis, Apple may continue to influence and benefit because Smartphones & Tablets will be an integral part of most IoT solutions.
The Economist gets into the over-hype around IoT – a very nice and thought provoking article titled The internet of nothings. It covers the chart put together by ZDNet on showing the surge in Google search aassociated with IoT, how the acquisition of Nest marks a tipping point. Two interesting observations:
#1. The post points out the real challenge is connecting the Cloud and the Node (Sensor or Actuator):
Devising sensors and algorithms to handle the front- and back-ends of the IoT are the easy part. Unfortunately, few developers are tackling the really difficult bit in the middle—the myriad infrastructural gaps that lie between the sensors in things at the edge of the internet, and the data collection and analysis performed by servers in the cloud at the centre.
#2. It questions the numbers being published (on number of connected devices) especially claims being made by Cisco:
…while Cisco Systems, a network-equipment firm in California, expects there to be no fewer than 50 billion. Cisco is so enamoured of the IoT that it has installed a “connections counter” on its website. On May 26th, the number of “things” connected to the internet was over 12.4 billion and counting.
The vast majority of the billions of things connected to the internet on Cisco’s website, for instance, are not the toasters, refrigerators, thermostats, smoke detectors, pace-makers and insulin pumps that the IoT’s true believers enthuse about. Almost exclusively, they are existing smartphones, tablets, computers and routers, plus a surprising number of industrial components used to beam performance statistics back to corporate headquarters.
Talking about Google, Business Insider is covering its rumor to buy DropCam (originally reported by The Information). It is probably pure speculation but if it bears fruit – Google could be really powerful in combining Dropcam, Nest, and Android (and YouTube/GoogleTV/Chromecast in the living room) and bringing order to Home Automation & Monitoring. Dropcam cameras have motion detection, Nest has a proximity sensor and between the two they could make for a solid, self-managed security system as well.
This week’s links also has a story with a cliche headline “With ‘Internet of Things,’ your fridge will know when milk is low“. This resulted in an interesting exchange on Twitter which you can read here. The blog post title is misleading because the focus is more on security. It has been distributed over many different websites – for example you can find it here and here.
Intel, Qualcomm and Freescale are three semiconductor companies that tend to show up in IoT Articles. This week I came across a post by Lee Schafer that starts off going over the Texas Instruments Launchpad:
On the Texas Instruments eStore it takes only $19.99 to jump into “the Internet of things” by purchasing a Connected LaunchPad unit to bring an everyday device onto the Internet. Better be patient, however, because they are sold out.
Finally a post on Wired is definitely worth reading – ‘Beautiful mistakes’ will form groundwork for the internet of things. The essence of the post:
Similarly, it will take user-generated products and hacked physical connections for brands to make sense of the internet of things. It will be ugly, soldered-together networked devices (not the gamified toothbrush) that will light the way for them. Beautiful mistakes and unexpected outcomes that will form their strategies.
Trying the much-hyped Twine
Twine is probably the geekiest of all the Internet of Things projects from Kickstarter – 8 of which I covered here. Twine is not for the ordinary folk. And it is expensive – with the full sensor kit [kit at the Twine + the Breakout Board, Magnetic Switch, and the Moisture Sensor] – it is for $199.95.
The looks are also geeky. And to get started you need a PC or Mac and has a WiFi Interface. I had ordered my Twine in December 2012, and finally started playing around with it this week – actually my first try was in January [then either it quit working on me or the batteries died, I never quite figured out what happened].
Setup:
You need a device or a computer with a browser to setup the Twine, and whatever you use is compatible with 802.11b WiFi. Setup can be confusing even though Twine on has simple enough instructions. The orientation of Twine is important – when setting up you have to place it with its back [where the instructions are written] facing up and then go to TwineSetup.com.
The first time when I tried it in January it worked for me easily enough. When I set it up yesterday all over again – I could not get the web page to show me the Wireless network to connect to [this is the screen with no wireless networks listed in the pull-down]. So I had to set it up using the other screens that they have for configuring the Twine. In the last step you need to create an account with the Twine website.
Once it is setup, all the information from your Twine can be accessed on to your web dashboard at twine.supermechanical.com.
Initial Thought
s:
While the Twine is interesting I find it bulky – the size of Twine is bigger because it uses WiFi as its connection and it needs two AAA-sized batteries. The upside of using WiFi is the controller to talk to the Web is not separate from the sensor. Twine is a controller and sensors all in one. The integrated sensing capabilities of the Twine are limited to Temperature, Orientation and Vibration. Vibration has been added recently since when I tried it in January it was missing. Enabling Vibration sensing to show on the Web Dashboard requires that you first setup a rule.
One more change Twine has made is to configure how often the Twine updates the status to the Web – the slower updates consume less power and can run on batteries longer.
Twine can be powered by a USB connection but that makes it impractical to be used in some situations. Twine has a rubber jacket that slides to insert the batteries. I found the insertion of batteries or removal to be a major pain – the rubber jacket is not easy to slide. I wish that Twine had a better industrial design.
Use Cases:
The website lists many suggested use cases – the challenge is that for each of these you would need a Twine – do the math at 125 a pop – the 18 use cases listed [and screen captured and stored on my Flickr account] would cost you almost $2250!
This is the reason I find Twine to be an impractical IoT platform.
I would mu
ch rather prefer using the Wireless Sensor tags that I covered in my earlier post. Mounting the Wireless Sensor tags on the door to sense door opening using motion is so much practical compared to mounting the Twine. [Take a look at this picture of the Twine and the Wireless Sensor Tags side by side.]
What I have tried out, and I like:
Because the Twine connects directly to the Internet, the updates reflected on the Web dashboard are fairly fast. I was impressed (after enabling the Vibration sensing through the Rules) at how fast the dashboard on the website showed the vibration measurement after I just tapped my finger on top of the Twine.
My home has become an experiment for Internet of Things, and one of my favorite tests is to put the controller or sensor inside my refrigerator and do temperature-sensing testing and also range testing. The Twine worked pretty well. The ambient temperature sensor on the Twine took about 30 minutes after placing it inside the refrigerator to adjust or show the temperature [of the
refrigerator].
I also loved the packaging – it was nice, and the unboxing experience was fantastic.
The To-Do List:
I still have to try out the three sensors that I received. The sensors can be connected to the Twine via a connector and special cable provided. Of course – you can only have one connector at a time.
The power of Twine comes from being able to setup notifications that are delivered via email or text messages – that is next thing to be tried as well.
Bottomline:
My initial analysis – I would be opposed to using Twine for automating my home or connecting it to the Internet – the cost is high, the form-factor is bigger, and it also lacks smartphone or tablet apps. I will continue to review further and try to use it for different scenarios – maybe I will change my mind about it.
Philips Hue: Setup and Teardown
I setup my Philips Hue controller and bulbs yesterday. In summary – it is a fantastic product, very easy to install and it is a pleasure to experience this lighting system. Only downside, IMO, very expensive…. a Starter Pack of three bulbs and the Hue Controller will cost you $199.95!
Packaging:
I loved the packaging. It is very well designed. The front flap of the package has a cardboard wheel inside with the side of the flap exposing it – you can scroll/rotate the wheel to see the colors of the bulb changing – makes for a nice illustration. The same wheel inside shows the three steps of setup. You can watch it in action on the videos I have uploaded on Flickr.
There are four things included in the package:
1. Three Connected Bulbs – when you pick them – they are heavy. I did not weigh them but they are not light. You can feel the weight – I am assuming it is controller inside the bulb and the fact that it has multi-colored lighting makes it heavier. The weight of the bulb made it nice to hold – and strangely it comforted me with respect to the cost of the bulb (not that I am too comfortable but it made me understand that this is not a regular bulb – the bulb alone costs $60).
2. A Hue Controller – this is small circular light weight controller with three LEDs on the top and a large button used for Pairing function. On the side is an Ethernet port to connect to the home network and port to insert the power supply. Three LEDs to show the status of Power, Ethernet Connection and Internet Connection. [Note: Philips refers to this device as the “bridge”]
3. Power Cord – Nice white adaptor with long enough cable
4. Ethernet Cable – Once more white cable and long enough
[My remark above on long enough is relative – what I mean is that the length was sufficient unlike some products where to save pennies the length is too short]
Setup:
Before I get into the setup process – the Philips Hue connected bulbs are controlled using Zigbee. However in order to use a Smartphone or a Tablet to control the Hue bulbs (and smartphones do not have Zigbee) – you need the Hue Controller which connects to your home network and then in turn “controls” the connected bulbs using its Zigbee controller [sounds confusing, isn’t it – think of it as a Bridge between two different interfaces or protocols].
The setup was very easy. And at no point do you need a PC or a Mac to setup – everything can be done using a Smartphone or a Tablet. It was also easy because they have removed the complexity of getting the controller on the Home Network by sticking to using Ethernet. First screw in the bulbs into lamps, turn them on. And all the bulbs turn on just like normal bulbs do. Once all the bulbs are in and powered on – plug in the Hue Controller into an Ethernet port connected to your home router/gateway, apply power. The controller boots in less than 20 seconds. Now install the app from the AppStore on your IOS device [the MeetHue website is not explicit but I think they support Android as well]… when you fire up the app [and your phone needs to be on the same home network as the controller] – the app will instruct you to press the round button on the controller. As soon as you press the button the app discovers the Hue Controller (bridge as they call it) and you are all set. In my case it automatically discovered all the three bulbs, and they showed up in the app. I could from the App settings “rename” them to distinguish. To make things easier – as you start editing the process by selecting “one of the bulbs” in the app – the corresponding physical bulbs starts blinking to show you which once you have selected. Handy feature ….
The app comes with multiple scenes that create a certain lighting ambience when you select the scene – you can read more about that on the MeetHue website. There is an option in the app to add more Controllers (i.e. Bridges) or more bulbs. Of course I have not tried them yet…
Adding a new app, that is if you wanted another phone or tablet to be used for controlling – all you have to do is to download the app, fire it up, make sure you are on the home network (WiFi), and then when the app prompts press the button on the Hue Controller and it is paired [this works very similar to the Sonos app as well]. If you had edited the names of the bulbs (for example I called one of them “FormalDiningLamp”) – that’s what will show up – the settings are stored in the Controller.
To be able to control them remotely – that is – when you are not at home (i.e. not connected to the Home Network) – you need to have an account with MeetHue.com. These steps were all from within the app – from settings select “Login into portal” – this will open up the browser on your smartphone or tablet – take you to the account creation page on MeetHue.com. This page is well designed for smartphones or tablets. A few well guided steps and you are all set. The web page prompts to confirm if this “smartphone” or “tablet” can be paired, and once you say yes – now you can control the Hue lights from anywhere with the app.
Experience:
The lights look beautiful – it was fun watching the different combinations (or scenes) pre-programmed into the app. If it were not for the $60 per bulb – I could have seriously considered getting more bulbs….
Latency:
When your smartphone is connected to the Home Network over WiFi and you use it to control the lights – the lag or the latency from the time you select an action (for example you select a scene) to the time the bulbs change or turn on/off – is barely perceptible. The lag/latency goes up to the order of 8 to 12 seconds if you are doing this remotely – that is you are not at home (not connected to the home network). I simulated this by simply turning off my WiFi and forcing the control through the Internet. First of all it took about 8 or 10 seconds for the app itself to “connect”. Once connected – for the bulbs to change to a new scene or turn on/off also took in the order of 5 to 8 seconds. Point to be noted though – if you are away from home and you want to turn the lamps on or off for reasons such as security – the time lag is not important – because you are physically not there!
Teardown & Design:
I have images of the Hue Controller (Bridge) teardown on Flickr as well. There were two screws. Opening it up was a bit tricky because of the internal snap-in mechanism (image here).
The two main components are:
ST Microelectronics STM32F217VE Microcontroller
Texas Instruments CC2530 Zigbee Controller
There is also a RF range extender – CC2590 – coupled to the CC2530. The STM MCU has an integrated Ethernet controller – the design has very few components – the cost of this starter pack is NOT in the Hue Controller but in the bulbs.
Range & Interference:
As a follow on I need to do some range and interference testing – the Controller and the Bulbs are not really far apart – they are in adjoining rooms… I need to move either the bulbs around or the controller to see what happens to the functioning of the system. But this is for a follow on post…
Summary:
If money is not an object, and you have spare Ethernet ports available on your router or home network – I would highly recommend the Philips Hue…
———————
The New? Frontier: Home Automation & Energy Management
BTW – the new Belkin Logo looks minimal and beautiful!
All Things CC: 