
The Internet of Incompatible Things - simoncion
http://mjg59.dreamwidth.org/37522.html
======
voltagex_
I have the same issue with chat protocols. Some of my friends are on iMessage,
some on Hangouts, some on Whatsapp. None of these talk to each other and I'd
really just rather use TextSecure.

We had a standard for chat, it's called XMPP, and before that we had IRC. I
know they're all non-optimal for mobile use but some goddamn standards (tm)
would make my life easier.

I can't believe we were better off in the heydays of Trillian - at least all
my contact lists were in one program!

Maybe I should go back to SMS.

Now, on home automation. I came to some of the same conclusions as the author
- we're screwed when it comes to being at the behest of big companies and
proprietary protocols to control devices we should own.

I just dread having to write yet another home automation framework when I do
finally automate my doors, windows and lights. Now where did I put my keys
again?

~~~
buffoon
Ugh this is the bane of my life. We use basecamp, hipchat, Skype, Skype for
business, email and google hangouts all at once. My kids use hangouts,
WhatsApp, Facebook messenger.

None of them work properly. None of them has everyone on it. None of them add
any value to communication. All of them throw ten minutes to the wind finding
everyone to start with. I've missed 20 minutes of many meetings dealing with
audio problems, network problems and firewall problems when we could have used
a simple dial in conference system that has been around for over 10 years.

And I'm treated like a Luddite because you have to call me, SMS me or email
me?!?

I don't want this any more. After a rant yesterday about WiFi and how it sucks
and I've switched back to wired ethernet. I have to suggest that there was a
technological singularity around 2005 which was 'peak utility' before the
proliferation of sharecropped communications, technology with false utility,
high cost and pay-per-everything.

To add other things to this problem set is going to cost me more money and
time of which both are finite and at least one runs out uncontrollably.

~~~
voltagex_
One of the things I was hoping would take off was SIP: URIs - in theory you
could "dial" my email address and the call would be routed to wherever I was
at that moment. Texting is built in too. Goddamn standards strike again.

~~~
buffoon
Yeah that was a great idea. Until NAT, firewalls, your average contracted out
MSP at an SME sysadmin who's idea of admin is lock everything down and pay
£300 to open a port (I have to deal with this at least one a week).

~~~
voltagex_
If normal Skype supported SIP it could just be bounced to Skype in that case.

Also, IPv6 FTW!

~~~
buffoon
Yes that's true although I've lost count of the hours I've thrown out on
Skype.

Yes IPv6 definitely FTW. We just migrated our office and two data centres to
it. Life is good now. V6 firewalls are just packet filters; all our nets are
in the public address space.

~~~
simoncion
Stupid question:

Just in case you want some nets to _not_ be globally routeable, you guys are
aware of the Unique Local Addressing block?

~~~
aexaey
You can make a non-routable subnet if you need one by configuring a
firewall/access list. Pretty much any router can do that. Plus you get way
better granularity in controlling access - office-local subnet, DC-local,
branch-local, country-local, whatever-local access - unlike venerable RFC1918.

But never use non-globally-unique addresses as other commentators suggest with
wonky probabilistic allocations. There is absolutely zero benefits for that,
and it will inevitably end up to be a huge PITA down the line. IPv6 used to
have 6-to-6 NAT and site-local addresses, but sanity won, and both were
dropped from the current slew of RFCs.

~~~
simoncion
Sure, you can go to all that hassle.

Or, you can use RFC4193 (AKA ULA) space, which allocates a /48 and is
_designed_ to be non-routable, unless an admin _chooses_ to make it routable.

RFC4193 specifies a prefix generation method and lays out the probability of
collision. If you join _two_ networks together, you've a (1.81x10^-10)% chance
of prefix collision. If you join ten-thousand networks together, you have a
0.0045% chance of collision. [0] If my math is right [1], this means that
you'd need to join 2,500,000 _networks_ [2] together to have a 1% chance of a
prefix collision.

I am _squarely_ in the "If there's a _chance_ that it _can_ happen, it _will_
happen." camp. However, I'm _rather_ okay with those odds.

[0] Either my figures are right here, or you need to take those percentages
and divide them by 1000 to arrive at the correct figure.

[1] And it _may_ not be right!

[2] Networks -each with its own /48- as opposed to hosts.

~~~
aexaey
Collision probability is indeed low if you'll assume perfectly generated
prefixes, and even in an unlikely case of /48 collision, those themselves
would be pretty sparse, so again assuming perfectly random distribution,
chance of collision of say fifty /64s on one side with the same amount from
the other network is still pretty low.

But bigger point here is that often you will need external connectivity for
those ULAs, similar to what everybody used to do in IPv4 world (i.e. NAPT,
a.k.a. "nat overload" a.k.a. "IP masquerade"), and that is not something that
is available, really. Instead, IPv6 offers prefix translation (a.k.a NPTv6,
see RFC6296). So effectively that means that:

\- for each LAN segment (i.e. /64) you have to have a "private /64" and a
"public /64" (or same at coarser granularity up to /49 or even more). Twice
the number of networks to configure and keep track of;

\- "NAT as a security measure" argument flies out of the window, as NPTv6 is
_stateless_.

In other words, you get all the hassle of IPv4 NAPT with none of its (meagre)
benefits.

~~~
simoncion
> But bigger point here is that often you will need external connectivity for
> those ULAs...

The whole _point_ of using ULA space is for giving IP addresses to machines
that you don't expect to need to contact machines in the globally-routable IP
ranges. [0]

From the RFC:

    
    
       This document defines an IPv6 unicast address format that is globally
       unique and is intended for local communications, usually inside of a
       site.  These addresses are not expected to be routable on the global
       Internet.
    

If it turns out that some of those machines _actually_ need access to
globally-routable space, then advertise a globally routable prefix to those
machines and either keep advertising the ULA prefix, or -yanno-, don't. :)

Fixing this particular network planning error shouldn't be much harder than
unsetting some firewall and/or routing rules that break Internet access for
machines that have been assigned a globally-routable address. :)

[0] On my LAN, I advertise a ULA prefix, _as well as_ a globally-routable
prefix. Because my globally-routable prefix is _not_ static, [1] I use the ULA
prefix as an ersatz poor-man's Provider-Independent allocation. This setup
would be probably be somewhere between unreasonable and silly at a site that
_does_ have a static prefix assignment.

[1] Well, it's _effectively_ static, but I don't have an SLA, so... ;)

~~~
voltagex_
I wonder how I do this as a home user.

~~~
simoncion
I assume that you're asking "How do I advertise a ULA prefix on my LAN, as a
home user?". If you're not, then the following probably won't answer your
question. If you're already familiar with ULA prefix generation and IPv6
prefix advertisment, and are just trying to find out how to advertise on your
home router, almost all of the following will be redundant information. (I'm
happy to read the manual for your make and model of router and try to see if
you _can_ easily advertise prefixes on it. :) )

I'm not sure how much experience you have with screwing around with router
settings, your level of familiarity with IP networking concepts, or even what
software you're using on your router, so I'll give some background information
on prefix advertisement, and describe prefix generation and how you might
actually advertise a ULA prefix on a router running OpenWRT. Because the
underlying software that does the work _should_ be the same regardless of
router model, reading about how it is done on OpenWRT _might_ give you a
starting point to discover how it's done -if it is at all- on your router
model. I'm more than happy to clarify anything that's confusing, give
additional information, or track down and read documentation for a particular
router!

Background information:

Many routers use a piece of software called radvd to advertise IPv6 routes.
Radvd -effectively- takes a list of network interfaces, each with a list of
router advertisment options, and transmits advertisements on those interfaces.
radvd has a config file whose syntax is documented here [0]. A minimal radvd
config file would look like

    
    
      interface eth0
      {
        AdvSendAdvert on;
        prefix ::/64
        {
          AdvOnLink on;
          AdvAutonomous on;
        };
      };
    

This would instruct radvd to advertise whatever prefix had been assigned to
the interface named eth0 to machines attached _to_ eth0. Note that an
interface section can have multiple prefix sections. If you have a particular
prefix that you _want_ to advertise, replace "::/64" with that prefix. The
overwhelming majority of options in the radvd config file are both entirely
optional, and entirely unneeded in most situations.

Now, I suspect that on most routers that support prefix advertisement, you'll
never need to touch an radvd config file. Like I said, this is just background
information. So, let's get to generating your ULA prefix:

Generating your ULA prefix:

Get the MAC address of a computer that you control.

Go to
[https://www.sixxs.net/tools/grh/ula/](https://www.sixxs.net/tools/grh/ula/)
and plug that MAC address into the MAC address field on the page. You'll get a
value back that of the form: fdaa:aaaa:aaaa::/48 This is your ULA prefix.

Advertising a /48 is kind of awkward for downstream devices. You need to carve
out a /64\. So, take that ULA prefix, add a colon and four zeroes to it and
replace the /48 with a /64 like so: fdaa:aaaa:aaaa:0000::/64 You can now go to
advertise this on your LAN. [1]

Advertising the prefix:

I actually have no idea what the prefix advertisement option is called on most
consumer routers, or if it even exists on _your_ router. A quick look at
Belkin's and Linksys's support sites didn't turn up anything promising. I
would dig around in the IPv6 settings tabs until I found something that looked
promising, or had exhausted all options. [2]

If you're using a recent version of OpenWRT (That is, OpenWRT Barrier Breaker
or later), /etc/config/network has a ula_prefix option in the globals section
that's used for _exactly_ this. [3][4]

If you're using a version of OpenWRT _earlier_ than Barrier Breaker, you can
tell radvd to advertise your ULA on your LAN interfaces. The prefix section of
/etc/config/radvd is used for this. /etc/config/radvd is documented here [6].
You _can_ have multiple prefix sections for each LAN interface. [7]

Now, reload the network config (Call /etc/init.d/network with either the
reload or restart option, I can't remember which.), wait for a minute or two,
and machines on your LAN should have a new IPv6 address in the /64 that we
carved out of the ULA.

If everything's working, -optionally- register your newly-generated prefix
with SixXS at the page where you generated your ULA prefix.

Feel free to ask any questions that you have. :D

[0]
[http://linux.die.net/man/5/radvd.conf](http://linux.die.net/man/5/radvd.conf)

[1] Note that you can create 16 bits worth of networks out of your /48, not
just one network.

[2] If you can tell me the make and model of your router, I'd be happy to try
to find and read the documentation for it. :)

[3]
[http://wiki.openwrt.org/doc/uci/network](http://wiki.openwrt.org/doc/uci/network)

[4] Though, to be frank, I can't remember if you plug in the /48 and it
automatically creates /64s for each LAN interface that you have configured
[5], or if you can only plug a single /64 into it. I would try the /48 first.

[5] OpenWRT lets you set up multiple LAN interfaces. I found this useful when
I was using VLANs to make isolated WiFi guest networks.

[6]
[http://wiki.openwrt.org/doc/uci/radvd](http://wiki.openwrt.org/doc/uci/radvd)

[7] So, if you have IPv6 service from your ISP, you can advertise the ISP-
provided prefix _and_ your ULA prefix. Have one prefix section that contains
_no_ prefix option, and a second prefix section that contains a prefix option
whose value is the /64 that you created earlier.

------
plaguuuuuu
This is what happens when everyone focuses on services, rather than protocols.

~~~
drdaeman
Not quite. This is what happens when everyone doesn't give a damn about
interoperability. Whenever they build new protocols (that no one else uses
because not caring about interop) or unique services doesn't really matter.

There are many examples of non-interoperable protocols that do the same thing
in a mutually incompatible manner. The most famous one, I suppose is
GNU/Linux-surrounding ecosystem with its GUI toolkit mess and audio subsystem
jungle.

~~~
simoncion
There are three major ways to do audio on Linux:

* ALSA: Focusses on providing a unified API for audio driver and audio application authors to code to.

* JACK: Focusses on _very_ low-latency audio.

* PulseAudio: Sits on top of ALSA and makes it trivial to move audio streams on-the-fly between audio output devices.

There are three major GUI toolkits:

* QT: Used if you don't hate C++.

* GTK: Used if you _do_ hate C++.

* WxWidgets: Used if you want to always use whatever the "native" widget style is on your target platform.

If you want your audio _and_ widgets to work on Linux, Windows _and_ Mac, and
you only want to use _one_ toolkit, use SDL. If you want a higher-level widget
toolkit than what SDL provides, use QT or GTK, or -I guess- WxWidgets.

There's neither a mess, nor a jungle here. I suspect that you've been paying
_way_ too much attention to what Poettering has to say about the state of
Linux. :)

~~~
drdaeman
You're right - as a programmer, it's simple - there are plenty of choice. But
I'm looking at this from desktop machine user perspective.

And I really _do_ have a desktop with eight different somewhat differently
looking and behaving (although they try to co-operate and it's possible to
bring some consistency to be not too bothered) widget toolkits.

I'm not exaggerating - it's really 8 different toolkits here. Ok, I got lazy
and run KDE those days so it's primarily KDElibs+Plasma and plain Qt (which
has its own differences, like file dialogs being notorious one), which are
mostly consistent between each other. Then I have a few apps that use GTK2 and
GTK3, a few Wine apps, too. There are also KDE3libs for kTechLab, WxWidgets
used by pgAdmin3 and Swing for IntelliJ-based IDEs. There are also some old Tk
apps but I run those once in a blue moon, so they doesn't count. But on the
other hand, LibreOffice and Firefox have their own widget sets...

I've long given up on OSS4 (which, in my personal opinion, is^W was the only
Linux sound system with a KISS API) and surrendered to ALSA+PA stack many
years ago. And don't have apps that need JACK anymore (used to run some
streaming-related software). And ESD & aRts are dead. So, no objections here,
although I had quite unpleasant experiences making ESD+JACK+ALSA combo working
(that was at least a decade ago). That was before Poettering's rants - honest
- although I won't deny that the "jungle" part is obvious reference.

~~~
simoncion
> But I'm looking at this from desktop machine user perspective.

From a desktop machine user perspective, there is _no_ difference between the
various audio libraries. So, I'm not sure why you brought them up if that is
the perspective from which you were speaking.

> Then I have a few apps that use GTK2 and GTK3, a few Wine apps, too. There
> are also KDE3libs for kTechLab, WxWidgets used by pgAdmin3 and Swing for
> IntelliJ-based IDEs.

1) It's the same story on Windows. GTK, QT, Swing, WxWidgets are all cross-
platform UI toolkits.

2) The look and feel of a given piece of native Windows software (and its
stock dialogs) often differs _drastically_ depending on when the software was
written and whether or not someone has bothered to update its look & feel
recently. I can't speak to OS X, but given how iTunes and QuickTime player's
UI were so _dramatically_ different from what I understood the Mac look & feel
to be, I would be surprised if this "problem" was completely absent.

3a) There enough variance in the way you interact with different programs that
I have a hard time being sympathetic to the complaint that moving from QT's
file picker to GTK's file picker to the WIN32 file picker to a modern Windows
file picker is _tremendously_ hard on the computer operator.

3b) Most of have been required to hop into a one-ton missile whose control
layout and handling characteristics are radically different from all other
such missiles we've operated in the past. Despite these challenges, we almost
universally have great success in operating these unfamiliar missiles at
highway speed with only the most fleeting of self-generated and self-guided
training programs.

Unrelated to all that: I'm finding that I'm substantially more happy with JACK
than PulseAudio. I started using PA maybe around 0.9.2 or so. I was -for the
_longest_ time- SUPER excited about both transparent network audio
transmission and about the ability to move streams between audio sinks on the
fly. As time wore on, I discovered a few things:

* Apart from the week or so of demos to myself and friends, I _never_ made use of network audio streaming. [0]

* I _almost_ never had more than one audio sink attached to my computer.

* PA -on my hardware- has _widely_ variable audio latency. (I'm 100% okay with _rather_ large audio latency. I cannot tolerate unpredictable audio latency.)

Recently, I decided to take another look at JACK. I'd been shying away from it
because it had a reputation as being really hard to configure and work with.
Turns out that that reputation is undeserved! Additionally, JACK has -AFAICT-
rock solid audio latency, and manages to use less CPU in the process.

[0] I make _constant_ use of SSH's X11 forwarding, even between my desktop
machine and my laptop. This is something that I would _conceivably_ use, and
_thought_ that I would use _all_ the time.

~~~
drdaeman
1&2) Yes, you're right. All popular operating systems out there are more or
less plagued with the same issues. I'm not bashing GNU/Linux (or any other OS)
here - I use it and it's a good system. My only point is, that designing
protocols (as opposed to designing apps/services) doesn't really help to get
rid of inconsistencies and bring compatibility. Sometimes, yes, I bet having a
well-defined protocol saved many from inventing their own. But - in my
personal perceptions (and I surely could be wrong) - not even remotely enough.

3) They're not _hard_ , just _inconvenient_ to some degree. Given enough time
and patience, everything can be worked around (and there are compatibility
wrappers/hacks). But - honestly - it's still a mess, both on the surface and
under the hood. I really don't want to even think that this particular file
picker is unaware of "recent documents" list of another framework. Don't want
remember that PgAdmin3 has its own peculiarities interacting with clipboard
and selection. And, back to the original article's topic, surely don't even
ask myself whenever a smart bulb would be compatible with some phone app,
especially one that I may haven't even encountered yet.

@Unrelated: Thanks for the advice. I don't use those features either. Although
I don't have any complaints with PA, next time I'll have time and consider
messing up with my system I guess I'll give JACK a try.

~~~
simoncion
> All popular operating systems out there are more or less plagued with the
> same issues. I'm not bashing GNU/Linux (or any other OS) here...

Except that you _did_. From the comment that started this sub-thread:

> There are many examples of non-interoperable protocols that do the same
> thing in a mutually incompatible manner. The most famous one, I suppose is
> GNU/Linux-surrounding ecosystem with its GUI toolkit mess and audio
> subsystem jungle. [0]

> 3) They're not _hard_ , just _inconvenient_ to some degree.

More inconvenient and more of a mess than than operating a new and unfamiliar
car? :)

[0]
[https://news.ycombinator.com/item?id=10257834](https://news.ycombinator.com/item?id=10257834)

------
InclinedPlane
IoT is one of the least well thought out ideas in quite some time, right up
there with the "semantic web".

Hopefully it dies a quick death and is resurrected in a more sensible and
mature form years down the road. There are worthwhile ideas there, but running
headlong into a world where everything has the same quality and security as a
typical software project doesn't seem like a notch in the "advance of
civilization" column to me.

~~~
simoncion
What, _specifically_ is poorly thought out about IoT?

Is your beef with the typically abysmal quality of software written by
hardware companies, or is it something larger than that?

~~~
InclinedPlane
Is there any part of the "Internet of Things" that is _well_ thought out? The
idea of our lives becoming surrounded by hojillions of things that are
constantly connected to the internet running software written by whomever with
no standards, no testing, no regulation or certification, that doesn't seem so
great to me. Even the best software written by the most capable engineers who
continue to be dedicated to the projects they support is still a horribly bug-
ridden mess with occasional enormous security holes. Even if all IoT software
was written by, say, a division of Google, it would still be a nightmare. But
it will be far, far worse because IoT software will be, and is being, written
by anyone and everyone.

When you buy a networked device today, how can you tell what level of security
it has? What level of testing it's been subjected to? Who has signed off on
the design and the code? No such thing of course, it's all at the same level
as the kids down the street building stuff out of their garage for kicks. And
while there's some merit to that when it comes to innovation, for production,
in the modern era, it's not just naive, it's either insane or idiotic.

We need more rigor, more standards, and less vulnerability surface-area when
it comes to internet-connected devices. IoT is precisely the opposite of that.
It's already bad enough that there are millions of zombie PCs in botnets
around the globe, we don't need zombie to add toasters, garage doors, light
bulbs, and what-have-you to that mess. Anyone who thinks that we can get
security and quality in the IoT for free without making a concerted effort is,
again, either monstrously naive, insane, or idiotic. It's 2015, that naivete
is no longer defensible.

~~~
simoncion
> Even the best software written by the most capable engineers who continue to
> be dedicated to the projects they support is still a horribly bug-ridden
> mess...

This is far from universally true. While I agree that the actual security of a
system is currently nearly impossible for most purchasers to evaluate, and I
agree that in far, far, far, too many cases proper system design and
implementation appear to be the least important priority of commercial
projects, there _do_ exist well designed, secure, complex systems.

> Is there any part of the "Internet of Things" that is well thought out?

The part where we use this largely ubiquitous, globally accessible network to
give folks the power to control and/or monitor the devices that they own from
any place of their choosing?

I 110% agree with you that -for an _enormous_ slice of the consumer
electronics market- security is -at best- an afterthought. However, just for a
moment(!), assume that all IoT devices are secure and only exist to serve
_your_ interests, rather than the interests of a national intelligence agency
or corporate overlord. In this hypothetical scenario (that's _really_ far from
what we have today) doesn't the statement in my previous paragraph highlight a
thing that -at worst- provides _no_ benefit to society and -at best- provides
a large benefit?

~~~
pjc50
If we had such a great pony as described in your final paragraph, then yes it
would be great. But that's not what we're anywhere near getting at the moment.

And it's always worth questioning what value the "things" are providing. Home
automation has been around for decades and remains a niche. Even business
computerisation (other than communications and ecommerce) seems to result in
surprisingly marginal productivity improvements.

~~~
simoncion
> Even business computerisation (other than communications and ecommerce)
> seems to result in surprisingly marginal productivity improvements.

You must be joking. :) The spreadsheet is an _enormous_ force multiplier.
Email -when used for useful communication- often _substantially_ reduces the
time to close a decision making loop. You can point to telephones as a
replacement for email, but telephone switches -themselves- have been
computerized for many, many, _many_ decades.

> If we had such a great pony as described in your final paragraph, then yes
> it would be great. But that's not what we're anywhere near getting at the
> moment.

You appear to be talking as if I don't understand that the state of system
security in the consumer electronics space is dire. I... kinda covered that in
the comment to which you replied. There was no need to qualify your "Yes.". :)

(And yes, I do notice that you're not my original conversation partner.)

~~~
pjc50
I was referring to the Solow productivity paradox: computerised technology
certainly feels much more efficient, but in terms of the economic variable
"productivity per person-hour" the difference is not as striking as expected.

The qualified yes was really a no: I believe that the market structure can't
and won't deliver open, secure, interoperable devices in the forseeable future
(say 10 years).

~~~
JoeAltmaier
But, but, I'm on a desktop running an open, secure, interoperable device right
now. Just migrate this software into a device, right? The capability of
devices right now is comparable to desktop computers in the 90s. And way
beyond what it took to put a man on the moon. So it'll fit, soon if not now.

~~~
nitrogen
It's the capability of markets and coporations that is in question, not that
of devices.

------
rdeboo
There's an interesting open source project OpenHAB
([http://www.openhab.org/](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).

~~~
simoncion
This was mentioned by a commenter on the OP.

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"

~~~
roel_v
It's true that OpenHAB doesn't have plugins for _all_ possible hardware, but
it does have both Wemo and Hue bindings. Because the Wemo/Hue 'interface' to
the Echo it might be a bit combersome to set up or use, but the idea behind
OpenHAB is the way forward: one central vendor-agnostic hub that drives all
connected devices. This way, the only thing that needs to be done to add
support for a protocol/device is to write a driver for the 'hub'. Otherwise
each device needs to interface with every protocol out there, obviously
impossible.

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.

~~~
simoncion
Does the OpenHAB Hue plugin also pretend to be a Hue bridge, or does it only
talk to Hue bridges? If you've used it, and know that it can pretend to be a
bridge, you might want to reply to The Author's request for more info. :)

> ...the idea behind OpenHAB is the way forward...

Tragically, the folks who _make_ the hardware disagree. :(

~~~
roel_v
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.

~~~
simoncion
> 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.

[2] Free-as-in-beer

------
DarkLinkXXXX
From the Conditions of Use for the Hue Developer Program[1]: "We want all your
apps to work with our API to form a rich ecosystem of interoperable
applications, so it is a condition of access to our API documentation that you
do not use it to develop or distribute any bridges or devices which interpret
the hue API in order to control physical devices. Emulators are allowed
provided they only control virtual bulbs"

Umm… what are they trying to say? They want interoperability, but only if it's
done their way? Seems kinda elitist.

[1]:
[http://www.developers.meethue.com/documentation/conditions-u...](http://www.developers.meethue.com/documentation/conditions-
use)

~~~
warfangle
I think they're trying to say, "you can create an app that uses the hue api to
control virtual lightbulbs, but you can't build software/devices that accept
hue api messages that will also control your window blinds."

It makes sense: the hue api is for lightbulbs, not for window blinds or door
locks. You're free to create a layer on top of it that accepts hue api
messages for lightbulbs, and other messages for other things.

I think they don't want people to get your hypothetical hue-api enabled
deadbolt and mistakenly unlock their deadbolt by turning using the hue app to
turn their lights off.

On the other end of things, you could make an app that will unlock your doors
and turn the lights on, as long as the message that unlocks the doors does not
conform to the hue api.

~~~
mjg59
It's more that they're saying "You can't make a bridge that would allow a Hue
app to control a non-Hue lighting system"

~~~
warfangle
Succinct, but I think it's more restrictive than what they're saying - more
like, "You can't make a bridge/device that would allow a Hue app to control
something that isn't a lightbulb."

~~~
simoncion
They say:

"...it is a condition of access to our API documentation that you do not use
it to develop or distribute any bridges or devices which interpret the hue API
in order to control physical devices."

A lightbulb is a physical device. It seems clear to me that they distribute
this API and documentation with a license that ensures that you can _only_
write software to work with _their_ hardware.

------
jhaand
The real money for IoT is not in domestic appliances. But in companies that
already had networked devices. For example: Logistic, City automation, large
medical devices, factories, Transportation and more of these capital goods.
Which can afford to have these different vertical silo's for the coming time.

The domestic sector will remain screwed and you're better of to roll your own
open source solution. Another solution would be to use a blockchain or one
single database were the other appliances can see what is happening and roll
their own interpretation of it.

Or we remain screwed and only put in an automatic light in toilet and done
with IoT.

------
kaolinite
This is what Homekit[1] (and Brillo[2] from Google) is trying to fix. We're
early on in IoT - things are very immature right now but that doesn't mean the
entire concept is flawed.

[1]
[https://developer.apple.com/homekit/](https://developer.apple.com/homekit/)

[2]
[https://developers.google.com/brillo/](https://developers.google.com/brillo/)

~~~
buffoon
The very nature of there being two things is a problem already.

~~~
roel_v
No, it's not, it's actually great that there are literally hundreds of them.
They are just the 'hubs'. Whatever 'hub' implements most 'protocol bindings'
and provides the best added value on top of it, 'wins'. And if one gets
behind, you can 'easily' (depending on circumstances...) switch to another
without having to replace the devices.

------
aqwwe
Maybe the European government will do something similar to what they did for
cellphone's charging ports (require all manufacturers to use micro USB). And
as for the cellphone change, it would hopefully be applied mostly across the
board by manufacturers (in USA too).

~~~
ocdtrekkie
That bears the question of whether or not the law will select the right
standard, or be able to change it when practical.

For instance, with USB Type-C coming out, with EU law be permissive of this
transition? Or will the EU requirement adapt to allowing Micro-USB and Type-C
for a while, and then eventually mandate Type-C?

~~~
Someone1234
This is a common misconception.

The way the EU's "common external power supply" standard was implemented
allowed the manufacturers to pick the standard themselves.

Essentially the EU put a gun to manufacturer's heads, and said "pick a common
standard together, or we will!" And they did. So the EU never picked micro-
USB, the manufacturers did.

Additionally the original memorandum of understanding has since expired (2012)
but it has been deemed a "success" as all major mobile phone manufacturers
continue to utilise micro-USB.

So there's no specific reason why USB-C cannot become the new normal. And it
seems manufacturers have actually become used to the status quo of having a
common standard (except Apple of course).

I don't think you'd see the EU get involved if all of them together moved to
USB-C (from micro-USB), they would only get involved if they started to
developer proprietary ports again, or all had different incompatible
ports/chargers.

Now they just need to do laptops...

~~~
ocdtrekkie
That's a very helpful explanation, thank you.

------
kaendfinger
Our company has been working on an Open Source IoT Integration Platform to
connect services together into one single protocol that can be used to
integrate devices and services together. Notice that it's an integration
platform, not a platform for purely building devices on. It can be used for
that, but it's primary purpose is integration.

[http://iot-dsa.org/](http://iot-dsa.org/)

~~~
Someone1234
So you've created this: [https://xkcd.com/927/](https://xkcd.com/927/)

~~~
kefka
Yep. Node-red remixed with some MQTT in a non-supported way.

yay.

As for me, I'll roll my own and stick with Node-red, mySensors
arduino/nRF24L01+ stack. It just works, and it works Now. And compatibility is
easy to do. Connecting to Octoblu (or any MQTT broker) is 1 node away, and
just works.

------
dade_
For now, it either uses CoAP or REST web service, otherwise I won't consider
it. Easy to understand, human readable messaging keeps the integration open
and is the second most important concern for IOT (security being #1), but most
everyone wants to create a platform and lock in a user/customer base. No
thanks.

