The Internet of Incompatible Things
Sep. 20th, 2015 01:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
IP lawyers
Date: 2015-09-20 11:24 pm (UTC)Long history of this
Date: 2015-09-21 01:27 am (UTC)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.
Re: Long history of this
Date: 2015-09-21 01:34 am (UTC)Re: Long history of this
Date: 2015-09-21 01:46 am (UTC)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:48 am (UTC)Re: Long history of this
Date: 2015-09-21 01:57 am (UTC)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)OpenHAB
Date: 2015-09-21 03:42 am (UTC)Re: OpenHAB
Date: 2015-09-21 06:03 am (UTC)Re: OpenHAB
Date: 2015-09-21 09:33 am (UTC)Re: OpenHAB
Date: 2015-09-21 02:58 pm (UTC)It could be a temporary anomaly
Date: 2015-09-21 07:11 am (UTC)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)Overoptimistic
Date: 2015-09-21 08:48 am (UTC)Combining incompatible subsystems on a comnon surface
Date: 2015-09-21 11:24 am (UTC)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
Re: Combining incompatible subsystems on a comnon surface
Date: 2015-09-21 02:55 pm (UTC)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)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
Date: 2015-09-22 12:48 pm (UTC)Insteon Hub
Date: 2015-09-22 04:53 pm (UTC)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)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)Re: Open standards are growing
Date: 2015-09-23 05:30 pm (UTC)Dystopian future
Date: 2015-10-01 04:24 am (UTC)...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.