[personal profile] 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.

IP lawyers

Date: 2015-09-20 11:24 pm (UTC)
From: (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

Date: 2015-09-21 01:27 am (UTC)
From: [personal profile] 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.
Edited Date: 2015-09-21 01:29 am (UTC)

Re: Long history of this

Date: 2015-09-21 01:46 am (UTC)
From: [personal profile] jonsmirl
I believe GE is buying their chips from Philips. Zigbee has almost zero market share.

Lowe's Iris system is an example of someone who perverted Zwave. Insteon had an open system for a couple years and then closed it.

It's too bad we don't see a lot of bulbs based on the ESP8266. It was originally designed to be a light bulb chip and it is rated at 120C. Then the bulbs would speak wifi and not need a hub. It is about $1 in high volume.

Zigbee will be replaced by 6lowpan (ie Google Thread) but I still don't think it will do anything. My preference is for all AC connected devices to speak wifi, and then anything battery powered to be Bluetooth Low Energy. Next version of ESP8266 due in October speaks wifi/BT and it is same price. TI has great BLE chips that will last seven years on a coin cell.

Re: Long history of this

Date: 2015-09-21 01:57 am (UTC)
From: [personal profile] jonsmirl
Smart light bulbs in general have close to zero share. Hue leads the small market, but it is tiny. Smart dimmer/switches are sold in much higher volume than smart bulbs.

Power consumption when off is more a function of power supply design. NXP engineers are probably better at power supplies than the LIFX people. Yes wifi takes a little more power when off, but it is not much.

Espressif is trying to build a reference design for the new ESP chip that will meet the EU standard of less than 0.5mW average when off. If you meet that standard you are allowed to advertise it as zero power consumption when off. It will be a wifi bulb. They have not managed 0.5mW yet but they are close.

Re: Long history of this

Date: 2015-09-21 01:49 am (UTC)
From: [personal profile] jonsmirl
Actual they both buy from NXP which Philip spun off. NXP has some nice 802.15.4 chips.


Date: 2015-09-21 03:42 am (UTC)
From: (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.

Re: OpenHAB

Date: 2015-09-21 09:33 am (UTC)
From: (Anonymous)
OpenHAB has a Hue binding, so …

It could be a temporary anomaly

Date: 2015-09-21 07:11 am (UTC)
From: [identity profile] 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!

Re: It could be a temporary anomaly

Date: 2015-09-21 09:37 am (UTC)
From: [identity profile] smurfix.livejournal.com
There's too many standards because there are too many incompatible ideas, most of which are somehow patented. So if you do anything high-volume it's cheaper to "invent" your own crappy protocol.


Date: 2015-09-21 08:48 am (UTC)
From: (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.

From: (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
From: [identity profile] smurfix.livejournal.com
dizmo is of course commercial and cloud-ish.
Control a whooping three devices for only $49!?!
(Or ten for $99.) Or $59/year if I want to actually develop something. WAT.

Nah. The overriding point of a smart home is that it's my freaking home. I want to be IN CONTROL in my own home.

welcome to independent development

Date: 2015-09-22 08:26 am (UTC)
From: (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...


andy - rants @ koipond org uk


Date: 2015-09-22 12:48 pm (UTC)
From: (Anonymous)
It sounds like you should check out http://josh.ai

Insteon Hub

Date: 2015-09-22 04:53 pm (UTC)
From: (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.

Re: Insteon Hub

Date: 2015-09-22 05:07 pm (UTC)
From: [personal profile] jonsmirl
Note how Insteon did the hub thing to HomeKit. They built a bridge. So they have to pay Apple $3 for the encryption chip and then 7% of $149 = $10.40 royalty. By making a bridge they avoided putting the $3 chip plus 7% fee into every socket and switch. But that doesn't make a good HomeKit experience.

The Bluetooth vs Airplay is more a function Bluetooth being a point to point network compared to the full networking in wifi. You like Airplay because it is wifi based. BTW - many of those Airplay speakers aren't paying the 7% royalty; Apple only chases the big companies. Apple has closed that loophole now by making you incorporate their encryption chip for Homekit.

Open standards are growing

Date: 2015-09-23 05:26 pm (UTC)
From: (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

Re: Open standards are growing

Date: 2015-09-23 05:30 pm (UTC)
From: [personal profile] jonsmirl
AllJoyn is a trick. The lower levels are open and free, but the upper levels are patented. Try to get the spec for AllPlay.

Dystopian future

Date: 2015-10-01 04:24 am (UTC)
From: (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.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags