The Cloudiness of Things

[jay (support)]

Forgive the blog-like post, but since we don't (yet) have a blog, I thought I'd post here just to get my thoughts out there and see what others are thinking.

Much has been made of the “Internet of Things”, and with good reason - the more that we are able to identify and interact with the objects in our environments the more we can see patterns in how those things interact. This is particularly interesting in the area of Domotics (Home Automation).

Lately, we’ve begun seeing a lot of new home automation products using WiFi to one degree or another. These products are also, seemingly invariably, delivered with their own iOS app. It’s obvious, right? You want to turn on the lights? Just fire up your iOS app. You want to change the setpoint on your thermostat? Just fire up our iOS app. You want to run your sprinklers? Just fire up our iOS app.

I see a problem with where this is leading: want to control your music? There’s an app for that. Want to turn off your coffee maker? There’s an app for that. So, let’s take inventory: lights, thermostat, sprinklers, music, coffee. That’s 5 different apps. Following this course, your iPhone and these apps are going to turn into the 21st century version of having 5 remotes on your coffee table, one for your amplifier, one for your TV, one for your VCR, one for your DVD, one for your Cable box.

People will eventually find it impractical to search for the right app to do what they need. Further complicating this scenario is the fact that many of the hardware makers are completely ignoring the need to provide an API which would allow their hardware to be integrated into a larger “system”. Out of 5 different WiFi-based devices I randomly selected, only 2 provide an actual API (others were reverse engineered which I don’t believe is a dependable solution).

Another issue with current approaches is that they seem to be paired with another concept: “the cloud”. The cloud refers to the ability of these devices to talk to some cloud-based service to deliver at least part of the functionality of the product. It’s a great marketing buzzword that will definitely attract some technical customers and, perhaps more importantly, media and potential investors.

Here again, though, we have a problem: if the company doesn’t provide access directly to the hardware from other systems, and the device is dependent on a “cloud” service existing, what happens when the network connection goes down? When the company’s service provider has a problem? When the company goes out of business (or exits the device business)? You now have expensive paperweights that hopefully can be hacked to continue functioning. When I asked the Product Manager for one of these products this question, the response was "most routers provide 3G network connectivity backup so the network should always be available". And perhaps the most scary part was that she was totally serious.

So, let’s recap the issues as I see them:

• single-purpose control UI - one app per hardware type
• no API for integration into larger systems
• dependence on a “cloud-based” service

I’m calling these collective issues “The Cloudiness of Things”. I believe that many of these vendors aren't seeing the larger picture because they're focused on immediate profit. Understandable - everyone has to make a living. However, "The Internet of Things" doesn't stop at identifying the things in our environment and directly controlling them, I believe it also means the ability for those things to interact in useful ways. Taking a vertical approach to design without giving any thought to interactivity with other components is a short-sighted view. I feel it's our responsibility to help educate both manufacturers and consumers.

I think as time goes on it’s only going to get worse.. Apple are the poster child for closed ecosystem and being one of the few tech companies making a profit in these harsh financial times i think most businesses are going to try and emulate their business model.. and the core of that is “Don’t let anyone else touch your stuff”..

Jay

I agree with your basic premiss that multiple apps and cloud reliance are not the way to go. However we can't wish it way so we have to work with what we have.
This is where Indigo can be a great force to bring things together and although I agree that reverse engineering is not the best way to go, I think it is very useful for some products.
Sonos is a good example where Nick was able to put together a great plugin this way. In some cases third parties have done a lot of the reverse engineering work like the Nest.

I sure don't like it but that is where we are.

Terry

Jay

I agree with your basic premiss that multiple apps and cloud reliance are not the way to go. However we can't wish it way so we have to work with what we have.
This is where Indigo can be a great force to bring things together and although I agree that reverse engineering is not the best way to go, I think it is very useful for some products.
Sonos is a good example where Nick was able to put together a great plugin this way. In some cases third parties have done a lot of the reverse engineering work like the Nest.

I sure don't like it but that is where we are.

Terry

Agreed, i was thinking of scrapping my sonos system and replacing it with something i could control from within indigo, as i got frustrated switching just two apps. Now i can control it from within indigo, i've actually expanded my sonos. I still get frustrated having to switch to the plex app and back again - I do have OCD though (diagnosed!!!)

Maybe a closed system within indigo is required - developers releasing controls to PA but with the understanding that somehow the product is not devalued. ie "works with indigo" approval, and perhaps a small charge for their locked "plugin".

[jay (support)]

Reverse engineering is fine as long as the user understands the risks associated with becoming dependent on the functionality. For stuff that's free, like iTunes, the risk is less since there's no extra monetary expense associated with it. Still a risk though as we saw with the iTunes 11 update.

However, if you go out and buy a Nest thermostat because there's a plugin for it - that could end up being a very expensive risk/gamble if the Nest guys change anything that breaks compatibility. While many of our current users perhaps understand that (particularly the ones that hang out on the forums regularly), I'm positive that just as many don't/won't which will lead to frustration and negative perception of Indigo (regardless of the fact that we have no control over it).

So, I stick by my statement that reverse engineered solutions are not generally dependable solutions, particularly for the less technically inclined users.

As for allowing 3rd parties to protect and obscure their IP - we're already internally testing/using a mechanism that allows for the sensitive parts of the plugin to be protected. We'll eventually allow 3rd party plugins to be protected in this way. I don't ever see Indigo plugins becoming curated as apps on the app store are but we will certainly improve the mechanism for how users find plugins (and we will find a way for plugin developers to monetize their efforts).

And, if the Nest guys came to us and said that they'd build a plugin if it could be protected we'd certainly do the protection for them immediately! Unfortunately, Indigo is a very small fish in the overall HA market so the chances of that happening are certainly approaching 0.

Jay,
Would you mind if I bring up some of the points and concerns discussed in this thread to the Ube folks on Kickstarter? I would be curious to their response. Or was UBE one of the company's you had already spoken to? Were you at SXSW?

With respect the "Internet of Things", I think it is very compelling to have a house "bathed in wifi" to quote another Indigo user taking advantage of that connection. Now as far as the Cloud is concerned, I see no issue with company's hosting their analytics and perhaps even charging a service fee to access those reports in the cloud. However, core functionality needs to be available locally should there be a failure in the commercial internet connection from the house.

I know that Nest is a polarizing device on the forums with some users not willing to touch it and the associate plugin with a cattle prod. I am in the other group that understands and accepts the risk. I have had some crazy Nest plugin issues which have since stabilized considerably but I think the Nest Plugin has been abandoned by the orginal developer. At least I haven't seen any posts or updates from him lately. When the plugin and the connection to the cloud work Nest & Indigo meet my needs and I am thrilled. When I have had a router hiccup or some other external outage, I just get up off my couch and adjust the temperature. Once again understanding that in my use case I am 'ok' with those typically short service disruptions.

Ube has recently extolled the benefits of the "Internet of Things" by creating API partnerships with other Kickstarter products to include: Almond+, Greenbox, Embrace+, and Smarthings. Before any of those alliances were announced I also backed Almond+ and Embrace+. All of these partnerships are once again very compelling however as Jay pointed out each of other devices will presumably have their own companion app. So which one will be the big papa and control the others?

Hopefully some of these questions will be sorted out by folks smarter than I. Having said that I can't wait for someone to take the ball and run with an Indigo Plugin crowd sourcing space for developers so I can post "Hey I have the funky internet connected bracelet with led's. Which Indigo developer can/want to make it talk to Indigo for $$?"

[jay (support)]

Yep, I've started that discussion with Ube among others. We'll see if I'm in the minority.

I avoid downtown like the plague when SXSW and ACL are going on - I don't like big crowds and that's about as big as they get here in Central Texas.

Not much to say here except "+1" (or "Like" or whatever your idiom of choice is). Private APIs are kind of a problem, depending on someone else being in the business of running a matching server is a bigger problem (See the recent furor over the new SimCity release for a somewhat more mainstream version of the issue). Matching private or reverse-engineered APIs with cloud servers and automatic firmware updates is probably the worst of all worlds - even if you do reverse-engineer it, it could change out from under you *and* stop working in its own right.

(Honestly, the bit about private/reverse-engineered APIs bothers me a bit about Insteon. While there is leaked documentation floating around online, I don't think I'm supposed to have access to the details without paying Smarthome some money, and I know that there are things, like the new i2CS interfaces, that are not available to me as a hobbyist).

So, what is to be done? It's true that it's a cost to the developers to make a publicly-consumable API. Sometimes the API itself needs cleaning up; sometimes you just (just!) need to write some comprehensible documentation; either way, you have to commit some resources to the stability of that API. If there's anything to be done, it's making it clear what the upside is - how third parties can make your product more valuable. This is at least plausible if the business in question is trying to sell hardware. If the business model has the hardware being sold at cost or as a loss-leader for the software service, this is a much tougher nut to crack, since openness then is in active conflict with their plans (CueCat, anybody?).

On one hand there is the idea that most consumers don't care. That an integrated home automation system is (can be) confusing. That it is simpler if someone just wants to control lights, they go to their lights app, etc. That may be true in some cases, but a good example is my wife's boss. He has asked a lot of questions the last few weeks about home automation and he gets the concept of having everything integrated... he says he thinks that makes more sense than having a separate app for each. He also sees the difficulty in getting everything setup to be able to do that and doesn't want to pay an integrator thousands of dollars to get it setup.

Additionally, he understands the concept of a lot of these solutions that are cloud based. Granted, having the internet now is like having electricity back when it was at the same age of development as the internet. I'm sure there were plenty of folks who said, what if the power goes out? then what? How will you be able to see? That being said, simply being connected to the internet and relying on a company for a service on the internet are two very different things. Unfortunately, or fortunately depending on your viewpoint, there aren't a lot of stand alone, non cloud based things being worked on.

In the grand scheme of things, I think the explosion of automation style devices is a good thing. The more people that get exposed and comfortable to controlling things like their lights, or door locks or sprinkler systems, the better these types of things will get, the more money that will get poured into the industry for development, and the better the end product will get. In turn, as people get more comfortable with these types of systems, I think a lot of people will see the value in tying everything together as well as making things reliant on their own system rather than a cloud based solution. Something as simple as turning an alarm on, turning off all the lights, making sure the garage door is closed and turning down the thermostat at night is a prime example. Who wants to open four different apps to do all that when you can simply hit one button (or no buttons if you truly want to automate) and go about the business of sleeping?

I think and hope there will be an explosion of devices, but I also think, inevitably, they will converge back to an integrated self reliant system. Until then, as Jay pointed out, I think there is business self interests that a lot of these companies are protecting. Maybe the Nest guys will never develop anything other than thermostats, and maybe they don't even know what they may develop down the road, but I'm sure they are going to fight tooth and nail to give themselves as many options as possible to further branch out their business in the future.

Until then, integrated people like us will have to continue to rely on reverse engineering things if they aren't publicly supported if we want the latest and greatest kit.

Yep, I've started that discussion with Ube among others. We'll see if I'm in the minority.

I avoid downtown like the plague when SXSW and ACL are going on - I don't like big crowds and that's about as big as they get here in Central Texas.

Hi Matt,
I'm sure you know by now that UBE was funded. Have they provided any further feedback or addressed any of your concerns since last posting? Just curious...

~Lou

[jay (support)]

I haven't heard anything else from them - I'm sure they're quite busy at the moment. We'll see how it plays out.

Hey Jay, nice writeup - captures my feelings perfectly on this business of accessing devices through the company's servers.

If it's cool with you, I'm going to put a link to this post on my blog...

[matt (support)]

Definitely -- thanks!

I'm wondering if things might be starting to change.. I've noticed over the last few months quite a few popular manufacturers opening up APIs for developers, and today Dish have announced opening up an API for their Hopper DVR units, which is interesting as i've found over the years cable/satelite providers are most stubborn when it comes to letting anyone mess with their stuff. Perhaps the tides are turning and this App-per-device attitude is finally going the way of the dodo.

[jay (support)]

We'll see - the Nest API appears to be a "cloud" API so you're still locked to their cloud.