There's an interesting open source project OpenHAB (http://www.openhab.org/) that aims to connect all these devices. There are quite a few plugings available (e.g. Philips Hue, Tesla, Sonos etc).
The author had this to say in reply:
"[OpenHAB] provides a consistent interface, but unfortunately it doesn't provide the right consistent interface - the Echo only speaks Wemo or Hue, so I'd still need something to bridge from there to OpenHAB"
When you start to move in the area of building automation tech, we have to deal with Luteon. And that means MSSQL database, and "pain and suffering". And there's no way to dynamically extract that data, so it's a little island of all its own.
We've been working with Citrix for quite some time. And they purchased IoT automation company Skynet, and rebranded it OctBlu. Seems good, really good. Well, until I decided to build my own sensor net using cheap tech.
All I should really need for a sensor is a 8 bit micro, a sensor, and a nRF24L01+ board. Turns out, from China, those little boards are a whopping $.67/each. Add that to the $1.87 arduino clone, and a sensor (starting with PIR, $.82) along with a dinky project box comes to $5-$6 per node. MySensors library for arduino/nRF24L01+ works superb. Simple API, mesh healing just works.
Well, after building a few nodes, I wanted to connect them together in a sort of a dashboard that makes programming them easy. We're already working with Citrix/Octoblu so what about that? Well, there is a MQTT-gateway for MySensors, using an arduino-ethernet module. No. I didn't want these sensors directly hanging off the internet, as our IP's are fully routable. Same with ESP8266-gateway. I wanted something more secure than "put it on the internet".
So, I made a mySensors-serial gateway. Plugs in via USB, and provides a serial port of all the data on the network. Simple and effective. From there, I have it going in to a linux machine running Node-Red. Turns out, this is what Octoblu uses. They just provided some pretty dockerizable instances and whatnot. But I have data coming in via serial port, through a mySensors decoder block, and then rest of the logic laid out nicely.
It's easy to see how the data flows through the system. I can control how it's logged, as well as where data is terminated. With potential fears of data leakage, I can provably show that the flowchart doesn't leak data. (well, aside mathematically proving said code: we're not doing that).
I've written my own 'hub' software for just this purpose.
I know that ZWave doesn't get much love from the OS crowd because 'proprietary' and 'Zigbee is an open standard', but ZWave works quite well wrt interoperability - because the ZWave consortium does some active interop checking and because everybody needs to use the same (debugged) chips and software, you don't have the situation of everybody writing their own slightly different implementation which is usually the source of 'interop in theory but not in practice' problems. Which is what is happening to Zigbee now, for that hand full of Zigbee devices you can actually buy.
> ...the idea behind OpenHAB is the way forward...
Tragically, the folks who make the hardware disagree. :(
"Tragically, the folks who make the hardware disagree. :("
Not all of them do, actually most don't; but even for those who do, the good thing is that we don't need them (mostly). Most of these protocols aren't rocket science, so even those where manufacturers tried to lock it down, people have reverse engineered it (e.g. Somfy). And the good thing is that because it's hardware, vendors can't just roll out a 'patch' or break the interface in the next cycle because that'd leave their existing customers in the cold.
Look, I understand the point, and it would be great if everybody went kumbayaa around The One Perfect Standard, but the situation is not as fundamentally flawed as the OP laments.
Are you sure about that? I thought the whole point of IoT devices was to be attached to an IP network and to -often- be field upgradable.
> ...the situation is not as fundamentally flawed as the OP laments.
I believe you when you say that these protocols often aren't rocket science. I don't know for sure -because I've not looked at any specs-, but I would suspect that -most of the time- reason #1 for building a new "smart home" control protocol is to create a new walled garden to call your own.
The situation is rather bad. Consider the difference between the current state of email and IM:
With email, you use any IMAP or POP3 client of your choosing, input your username, password, and email server hostname, and you're done. Anyone who uses email can send an email to you using any software of their choosing at any time.
With IM, you have one scenario for reachability, and two for client choice.
Reachability:
In order for someone to contact you on any IM network that's not a federated XMPP network [0], they must first create an account on that network. Users of one network -with rare exception- cannot contact users of another network.
So, to speak with a friend, you must know their username, the network that they use, and you must have an account on that network.
Client choice:
There are two scenarios here:
1) You and your friend use an IM network built before ~2008. You get to use the official clients, or Trillian, or a libpurple-powered client. Hooray for you! All your messaging can be handled in a single piece of software!
2) You use a contemporary IM network. To speak with a friend, you have to dig up the official client for the network that your friend uses. If you have friends in multiple networks, you have to use other, entirely separate pieces of software to speak with each group of friends. Hope your device of choice makes switching between applications quick and easy. :)
With email, you get your choice of clients and can contact any other person hooked to the Internet who uses email. You know that if you send a message to a valid email address, it will eventually get there. With IM, the situation is far more complicated and uncertain.
So, to tie it back to lightbulb control protocols:
A standard, comprehensive, vendor-independent control protocol -let's call it SmartBulb- assures you a few things:
* A non-technical consumer goes out and buys any SmartBulb equipment from any store. He knows that it'll work without hassle.
* When your current lightbulb vendor goes belly up, you can purchase bulbs and controllers from any other players in the industry.
* You can switch to more capable or better designed bulbs and controller models without rendering your existing devices useless to you.
With a fragmented market, there are a few hazards:
* Folks who would reverse-engineer proprietary protocols and sell devices to interoperate with multiple vendor's hardware are opening themselves up to great uncertainty in the form of frivolous legal action. [1]
* Non-technical users must purchase equipment from a single vendor or cabal of vendors. If those folks go belly up, these users will likely have no place to go to replace their hardware when it eventually wears out.
* Somewhat-technical folks who use gratis [2] controllers that are the product of reverse-engineering still have to live with the uncertainty that future revs of products that worked well with their controller no longer do, because of changes to the protocol, or use of parts of the protocol that the reverse engineers were unaware of.
If all that is not compelling, then consider this: How would your life change if you couldn't be certain that your electronics worked in any given building? That is to say, what would you do differently if -to reliably use your electronics on the go- you had to carry around a fat sack of adaptors, and -even then- sometimes you didn't have the right adaptor on you?
There's a lot of value in having a single, comprehensive standard.
[0] These days, effectively no IM networks are federated XMPP networks. Noone is sadder about this than I am.
[1] Just because it's frivolous doesn't mean that it's not expensive and time-consuming.
[2] Free-as-in-beer