Here is my blog series on this IoT project to automate some key home functions using a variety of IOT devices from many manufacturers.
Here is my “Buy/no buy/might buy list and IOT landscape article here”
Here is my “What are the integration points for IoT article here”
Here is my “Why would you want to integrate IoT devices article here”
Combining Services from disparate devices
There is a question where to integrate different IOT devices. Conceptually integrating different devices would be best done locally since there would be less latency and there would be less dependency on outside systems or loss of connectivity to the cloud. However, almost everyone wants to be able to control their devices from the cloud so cloud connectivity is needed anyway. Also, if any of your devices collect data you may want to have that data in the cloud because of issues around backup at home. If you build the automation locally you will still want to have access in the cloud so you will have to build or have access to your automation in the cloud.
Whether you decide to do your integration locally or in the cloud the decision is also affected by what is available. Devices have a variety of compatibility with local hubs. Some hubs can support some devices. Nothing can support all devices, not even the Homey which seems to support virtually every protocol out there. The reason is that device manufacturers still feel they have the option to invent their own protocols and hardware or there may be a devices from the ancient past that use something before the latest craze that still need to be integrated.
Some IOT devices offer SDKs for development of applications on computers or for SmartPhone apps. Some offer APIs to talk to the device directly. Some offer APIs to talk to a Web Service in the cloud. Some offer “standard protocols” such as Z-Wave or Zigbee, CoAp, etc which provide a way to talk to numerous devices in a standard way locally. Some only offer a Web Service. Some offer all of these and some offer only a few. So, how do you build automation across numerous devices of different protocols and approaches and where?
One way is to buy only devices which fit a certain profile so that you are sure that all your devices can be communicated with in a way you will support. This is almost certainly to some extent required as the variety of different protocols and device integrations can be extremely costly and time consuming beyond the utility of a particular manufacturers device features.
For integration locally we have the hubs on the market. For integration in the cloud we have a service like IFTTT. Let’s discuss each.
Local Integration Compatability of Protocols
The IOT market is beset with hubs galore at this time. Here are 13 hubs that are either in the market today or soon to be. 7 of them are shipping today and 6 are soon to be shipped.
| Manufacturer | Protocol | Programmability | ||||||||||||
| Shipping | Wifi 802.11 | Bluetooth Low Energy | Near Field | ZigBee | Z-Wave | Lutron 433Mhz | nrf24l01+ | Insteon | Infrared | Cell | Apple HomeKit | Other | ||
| SmartThings | Y | Y | Y | Y | Groovy | |||||||||
| StaplesConnect | Y | Y | Y | Y | Y | NO | ||||||||
| Wink | Y | Y | Y | Y | Y | Y | Robots | |||||||
| Insteon Hub – Microsoft | Y | Y | Y | Y | Insteon, dual band, wireline | YES | ||||||||
| Honeywell Lynx | Y | Y | Y | Y | 345Mhz, Power Backup | NO | ||||||||
| Mi Casa Verde Vera | Y | Y | Y | Y | Y | YES | ||||||||
| HomeSeer | Y | Y | Y | Y | Y | LOCAL ONLY | YES | |||||||
| New Smartthings | N | Y | Y | Y | Y | Y | Power Backup | Groovy | ||||||
| Ninja Sphere | N | Y | Y | Y | Y | Y | Gestures and Trilateralization | YES | ||||||
| Apple Hub | N | Y | Y | Y | ?? | |||||||||
| Homey – Kickstarter | N | Y | Y | Y | Y | Y | Y | Y | Y | JavaScript | ||||
| Oort | N | Y | Y | NO | ||||||||||
| Almond+ | N | Y | Y | Y | NO | |||||||||
If you want to integrate your devices locally then you face the issue if they are all available through a single hub device. Wifi devices tend to be devices that are powered by a plug since 802.11 requires more power although it is ubiquitous. BLE is gaining popularity but few devices are BLE in my experience. Zwave is the most popular protocol and is supported by almost all hubs. Zigbee close behind. A requirement to do sophisticated integration is that the hub support programming. The Wink hub looks promising but it’s robot language may not be sophisticated enough for some applications. This leaves the SmartThings, MiCasaVerde, HomeSeer, Ninja Sphere and Homey as contenders. I discarded the Insteon as it refuses to support recent protocols. It may be a viable entry if you have a lot of legacy X10 and other devices from the past.
The first 3 SmartThings, Vera and HomeSeer are the only currently shipping products.
In its infinite wisdom Lutron which has a history of making lots of lights and other devices decided to use a 433Mhz frequency protocol which is not well supported by all the hubs. NRF24L01+ is a hobbyist protocol. The infrared protocol can be mitigated by purchasing irBeam kickstarter devices. These devices support BLE and allow you to automate transmission of IR commands to control all your IR based home entertainment devices. Therefore, by having a BLE enabled hub and some automation you can probably support IR devices without having support in the hub. Some devices have a backup Cell Phone connection capability in case your internet connection fails. The new SmartThings has power backup as does the Honeywell Lynx. However, the Lynx isn’t programmable.
It is possible that like the Infrared option there may be “point solutions” that could offer additional protocols through a proxy. A company is proposing to build such point solution products with no user interface so you can buy them individually. However, this is a kickstarter project not quite past the conceptualization stage. The Davis weatherstation uses a proprietary protocol and hardware for communicating between its weather sensors so this required me to purchase the weather envoy which consolidates all their devices and allows me to deliver that locally and to the internet through an application on my Mac Mini. Similarly Honeywell has a history of devices using the 433Mhz frequency that work very well for security and won’t interact with anything but a Honeywell device.
The Ninja Sphere deserves mention because it has 2 very cool technologies built into it besides the standard ones. The Ninja has a capability to detect the location in the house of the devices it is talking to. So, by attaching a “Tag” device to anything in the house or from the movement of devices it is listening to it can triangulate an approximate position. It uses this to detect if things are moving in the house. Another feature of the Ninja is the ability to detect hand gestures around the device itself. So, they can support the idea that tapping the device will turn on things or a movement of your arm a certain way above the device will cause the temperature of the house to go up or something else. The Ninja also has the ability theoretically to support Spheramid’s which they say can be used to attach any future protocol that someone wants to. It’s also kinda cool looking.
I bought a MYO armband which requires you wear something on your arm but the MYO works throught BLE and if your hub uses BLE and had an integration with the MYO then you could support gestures anywhere not just near the Ninja.
Local Integration Automation
Once you have a hub selected to do all your automation you need to be able to program it to the devices you are supporting. In my case there are several devices on my list that aren’t supported by any hub so a hub can’t do it all for me. In addition you may require, like me, the use of external web services to support some of the functionality and intelligence.
For instance, I need to go to PGE web site to find rates and times of rate changes. I need to go to a weather service to find predictions for future weather which I want to use in my automation. I also want to look at my cell phone’s movement to detect my movements and I want to automate some things around the car (Tesla) and all of these will require external web services to work. So, my hub must allow a programming environment powerful enough to allow me to include these external services as well as the data coming from my devices that are connected to the hub. Even if I do the integration on a local device I will need internet connectivity to implement all the intelligence I want.
The SmartThings, Homey, Vera and Ninja claim to support a full language that can allow the complexity I would want.
Cloud Integration Compatibility of Protocols
All of my devices connect to the internet either directly or through a device locally. So, my electric meter is monitored by PG&E which stores data on the Opower website. I also collect real time data via a HAN compatible device which funnels the real time information to the internet as well as locally. The Davis weather station data is available locally but also is delivered to WeatherUnderground to be accessible from the Internet. All my Z-Wave devices talk to the Lynx 7000 locally but also deliver their status to the cloud. So, whether I want it or not everything is in the cloud anyway. To be truthful some of the devices could be set up so they didn’t go to the cloud but most of the time people want to be able to access devices from the cloud so it makes sense to have the data and control in the cloud too.
The spreadsheet for supported services in the cloud is much sparser than the HUB market above:
| Service | Integration of | ||||||||||||||||
| F=Future Planned | Prod? | WEMO | Google Mail | Drop Box | SMS | TESLA | GPS Following | HAN Energy | UP Jawbone | Weather | Hub Support | MYO | Carrier | irBeacon | ATT DVR | MyQ Liftmaster | |
| IFTTT | Y | Y | Y | Y | Y | F | F | F | F | ||||||||
| Google Home | N | ||||||||||||||||
| myHomeSeer | N | ||||||||||||||||
| ATT Digital Life | |||||||||||||||||
| DeviceHub.net | |||||||||||||||||
| Vera | Y | Y | Y | Vera | Y | ||||||||||||
| SmartThings | Y | Y | SmartThings | ||||||||||||||
| Ninja | N | Ninja | |||||||||||||||
| Homey | N | Homey | |||||||||||||||
Google Home or Android@home is a concept at this point. I am not aware of a delivery date. myHomeSeer is a service that promises to allow you to control your HomeSeer devices from the cloud. ATT Digital Life is still a concept from what I can see. I am surprised there are not more IFTTT like clones out there.
Basically, only IFTTT at this time seems to support doing automation in the cloud. There are a number of IFTTT like services including: Zapier, Yahoo!Pipes, CloudWork, CloudHQ. None of them seem to provide any IOT support at this time although they could all in theory help in building the automation I am considering.
You could of course create your own virtual server in the cloud, run your own application and implement whatever automation you wanted. You can use any of a number of PaaS services in the cloud that allow you to build and run applications in the cloud. This requires a complete knowledge of development and you building your own application from the ground up.
You could also build your own Ios application or Android application and run it on your phone. That’s even more complicated.
IFTTT allows you to specify a channel as a trigger. The channel can be any of 70 different services they support today. So, I can say that when I send an SMS message to IFTTT it will turn on a WEMO switch which turns on something in my house.
IFTTT is far from perfect as well. It supports a very few devices directly and I will need to leverage some clever tricks to get IFTTT to do some of the automation I want. For instance, IFTTT allows you to specify when an email with a specific subject comes in to do something. So, I can build some automation either locally or in some PaaS service that will perform some of the automation I want and gather information and then send a message to IFTTT through either an SMS message or google email or other channels that already exist in IFTTT to trigger the functionality I want.
IFTTT is working on a development platform that will allow people to build their own channels and actions. They also have a large number of Future items that many people seem to be working on. I suspect in a year the IFTTT story will be very much more complete and compelling looking at the comments and momentum it seems to have garnered.
Could this be simpler?
Of course I am tackling a difficult problem because I am trying to stretch what IOT can do today and how smart it can be. There are choices I could have made to make life much simpler. If I had stuck to virtually everything being a Z-Wave device it would have eliminated a number of complexities. If I relaxed some of the requirements, like knowing my location or trying to integrate my Tesla, BodyMedia, Myo, Carrier devices it would make things easier.
Things are rapidly evolving
The state of things is rapidly evolving. Some of the hubs I am talking about are due out soon. I expect there will be a lot more automation available in all the platforms and more compatibility. There will still be numerous legacy things that can’t be changed and there will be vendors who refuse to be helpful. A number of new entrants will undoubtedly confuse things. It’s early in the IOT space. Many vendors are trying to stake out ownership of the whole space. Too many protocols and different models of how things can be integrated exist than can be supported. I suspect in a year things will be better but also I don’t think the wars between the participants are nearly won.
Where to put the automation?
I am going to decide on a hub and put some integration and intelligence into the hubs and some into the cloud. I will describe more of how I propose to split the work and the data in the next blog. I will also address how to get around some of the thornier problems if possible.
CloudRamblings 