Yeah sorry my post reads like 'I know it's possible', it was more meant as a 'it's theoretically possible, if it's not possible right now it's because nobody has done it yet'. The OP sounds like its a fundamental problem, my point was that it's just an implementation problem.
"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.
> 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.
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.
"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.