The Internet of Incompatible Things

[mjg59]

I have an Amazon Echo. I also have a LIFX Smart Bulb. The Echo can integrate with Philips Hue devices, letting you control your lights by voice. It has no integration with LIFX. Worse, the Echo developer program is fairly limited - while the device's built in code supports communicating with devices on your local network, the third party developer interface only allows you to make calls to remote sites[1]. It seemed like I was going to have to put up with either controlling my bedroom light by phone or actually getting out of bed to hit the switch.

Then I found this article describing the implementation of a bridge between the Echo and Belkin Wemo switches, cunningly called Fauxmo. The Echo already supports controlling Wemo switches, and the code in question simply implements enough of the Wemo API to convince the Echo that there's a bunch of Wemo switches on your network. When the Echo sends a command to them asking them to turn on or off, the code executes an arbitrary callback that integrates with whatever API you want.

This seemed like a good starting point. There's a free implementation of the LIFX bulb API called Lazylights, and with a quick bit of hacking I could use the Echo to turn my bulb on or off. But the Echo's Hue support also allows dimming of lights, and that seemed like a nice feature to have. Tcpdump showed that asking the Echo to look for Hue devices resulted in similar UPnP discovery requests to it looking for Wemo devices, so extending the Fauxmo code seemed plausible. I signed up for the Philips developer program and then discovered that the terms and conditions explicitly forbade using any information on their site to implement any kind of Hue-compatible endpoint. So that was out. Thankfully enough people have written their own Hue code at various points that I could figure out enough of the protocol by searching Github instead, and now I have a branch of Fauxmo that supports searching for LIFX bulbs and presenting them as Hues[2].

Running this on a machine on my local network is enough to keep the Echo happy, and I can now dim my bedroom light in addition to turning it on or off. But it demonstrates a somewhat awkward situation. Right now vendors have no real incentive to offer any kind of compatibility with each other. Instead they're all trying to define their own ecosystems with their own incompatible protocols with the aim of forcing users to continue buying from them. Worse, they attempt to restrict developers from implementing any kind of compatibility layers. The inevitable outcome is going to be either stacks of discarded devices speaking abandoned protocols or a cottage industry of developers writing bridge code and trying to avoid DMCA takedowns.

The dystopian future we're heading towards isn't Gibsonian giant megacorporations engaging in physical warfare, it's one where buying a new toaster means replacing all your lightbulbs or discovering that the code making your home alarm system work is now considered a copyright infringement. Is there a market where I can invest in IP lawyers?

[1] It also requires an additional phrase at the beginning of a request to indicate which third party app you want your query to go to, so it's much more clumsy to make those requests compared to using a built-in app.
[2] I only have one bulb, so as yet I haven't added any support for groups.

Comments

IP lawyers

[(Anonymous)]

In response to your rhetorical investment question, IPH limited is a listed company of IP lawyers. But that would be a bit like chumming.

Long history of this

[jonsmirl]

This has been going on in home automation for about 40 years now. The problem is that the end devices (bulbs, switches, thermostats, etc) are low margin. The controller hubs are high margin. So companies keep building controller hubs to connect with everyone else's low margin end items. These companies just want to make the high margin hubs and have nothing to do with the end devices. Of course the makers of the end devices make hubs too and they don't like losing the businesses. So the same solution occurs over and over -- the end devices employ encryption (or secret protocols) to keep the hub only companies out.

And we're setting up for this cycle again in spades with Apple HomeKit. You'd have to be an idiot of a device vendor to sign up for it. Not only does Apple control the hub, you also have to pay them 7% of your revenues to connect to it and buy a custom encryption chip from Apple to put into your product. This is going to make HomeKit devices twice the price of the competition and no one will buy them.

OpenHAB

[(Anonymous)]

You might want to look into using OpenHAB (http://www.openhab.org/) - it doesn't support every device out there, but it does give you a consistent interface for the ones it does support. Requires a lot of setup, though.

It could be a temporary anomaly

[grok-mctanys.livejournal.com]

I think it's going to be temporary.

Like the personal computer, which started out as a bunch of different incompatible systems, before someone (accidentally) brought out a cheap, open system that anyone could re-implement and develop for (the IBM PC), which pretty much took over the world. Ditto the various not-quite-compatible proprietary X servers of days gone by, and, in fact, proprietary Unices. We're just about getting to the "free and open" part now with document file formats and ODF finally gaining some traction.

Sure, it might take 20 years or so to sort itself out. But that's progress for you!

Overoptimistic

[(Anonymous)]

For most of them the goal is to make you control devices via their web serviced through theit web site which means they can sell all your activity data. However it also means as many of the pioneers go under users will be left with inoperable or at best insecure junk.

Combining incompatible subsystems on a comnon surface

[(Anonymous)]

I agree with what has been said, that this is a problem Smart Homes and therefore IoT are suffering from for decades now. For a long time, and still today, most engineers believe the only way to solve the problem is to write a new layer on top of the incompatible protocols / bus systems in order to integrate them. Unfortunately up till today many if not all of these approaches have suffered from the fact, that they usually end up with the smallest common denominator between these subsystem. So the more systems are integrated in a common layer the less functionality will be left that is useful. So by definition you either integrate just a few systems (typically two or three) with a reasonable set of features available or you have a larger number number of subsystems integrated and there is not much more left than turning devices on or off.
There is however a solution that may deal with that problem, which tackles thins from a slightly unusual angle: If you create a surface that shows subsystems in a modular and complete way to the end user and you make it possible to couple those systems you will get a surface that allows to monitor and control a large number of systems on one simple to use surface but you still can provide all the nitty gritty details each if those subsystems allows to do. So combining an infrared controlled TV set with a Philips Hue lamp and a door sensor from let's say Smarthings will become trivial just by arranging their visualization on the same surface. Now add to that the capability to «dock» these control elements to live exchange states and events and you are pretty close to a very practical solution to the problem described. And if you are looking for a system that provides the kind of surface described have a look at dizmo.com

welcome to independent development

[(Anonymous)]

So you are bitching (quite correctly) about embedded providers not being compatible with one another. I happen to agree that this is not in the user's best interest. I suspect that most of your readers are of a software persuasion, and would like to point out the hypocrisy here.

This is no different from incompatible software ecosystems.
At the highest level M$ doesn't want its latest products to be (fully) compatible with the previous version (why else would you upgrade something that already does what you want?) Further down you have incompatible platforms, you can't run your Linux app on this Windows box or vis versa without your bridging software (in this case cygwin or wine could be considered for that role), lower still you cant run binaries for an ARM on a AMD64 (without a bridging tool such as QEMU).
I say there is no difference here.
You may say that the difference is the boundary of the physical device, I disagree. The Boundary is a commercial ecosystem with each commercial (or FLOSS/FLOSH) entity controlling their own vertical silo (damn I was trying so hard not to use buzz words). Is this any different from building your infrastructure in the USA vs building it in France? One would use Imperial units and the other Metric. That fundamentally means that every thing is different between the two ecosystems, sure you can modify and bridge between the two (the UK does this all the time) but reality is if you build something in metric then take it into an imperial dominated area maintenance is a bitch.... replacing broken parts is still a nightmare, interconnecting the two systems is a real pain because everything physical is repeated for metric and for imperial.
I guess what I am trying to say here is that two or more systems developed independently will NEVER compatible be it light bulbs or word processors. Your article whilst correct in sentiment, shows your naivety in this area. Enter any new sphere, and you will find different eco systems, there will be a call for a single standard to encompass everything. Great we now have standards+1 to bridge between, for now and forever...

http://imgs.xkcd.com/comics/standards.png


/Andy
andy - rants @ koipond org uk

Josh.ai

[(Anonymous)]

It sounds like you should check out http://josh.ai

Insteon Hub

[(Anonymous)]

Like others have said, this isn't some dystopian future thing, it's the past few decades of home automation summed up. I'm actually very encouraged that HomeKit by sheer force of Apple's will is designed to encourage best practices in low power bluetooth management, and obviously promote interoperability with other HomeKit devices. I'd say look for the price of the devices to mirror what happened with Airplay speakers– I can pick up an iHome W1 with airplay all day for the price of a comparable bluetooth speaker, but I can also stream to it simultaneous to several other airplay speakers using a PC, something I can't do with a bluetooth speaker. The same heretical comments about Apple forcing vendors into a scheme to pay for Airplay was said a few years ago when those speakers were first introduced, but all they did was make their own wifi system, which turns out to be much cheaper and even more open when compared to Bose, Sonos, Samsung and the like.

What's most encouraging about HomeKit protocol as it relates to hubs is what has come out of Insteon. I'm a huge fan of their dimmers– they give me redundant and reliable communication that my Lutron RadioRa2s didn't, and their new Insteon Hub Pro (http://www.smarthome.com/insteon-2243-222-hub-pro.html) actually integrates HomeKit scenes into other open protocols. To me this box alone is a game changer for the casual home integration user.

Open standards are growing

[(Anonymous)]

There are open standards out there that are growing. In particular AllJoyn is fully open source and the Alliance behind it has nearly 200 members including most of the biggest players in OS, chips, white goods, and consumer electronics outside of Apple, Google, Intel, and Samsung. LIFX

Dystopian future

[(Anonymous)]

...it's one where buying a new toaster means replacing all your lightbulbs...

I think in such a scenario it's far more likely that the bulk of people are going to say "screw it, I'm going to toast my bread the old-fashioned way, get back to me when this rolling fuckup is over".

If the companies involved want to build a bigger home automation market, they're going to have to wake up to the fact that they need a great interoperability story.