[HH] MQTT

[Tom Metro]

[Also posted to G+ https://plus.google.com/+TomMetro/posts/JRPKoK3MFYZ ]

So what's the answer to your IoT devices being turned into paperweights
when the vendor shuts down the back-end servers, as happened here?

http://mashable.com/2016/04/04/revolv-smart-home-shutdown/

The answer is standards.

In most cases the cloud server back-end exists strictly to solve the
problem that without it, it takes a lot more networking knowledge to get
apps running on ether the user's LAN, or to access your device from the
WAN (Internet). Manufacturers strive to have gear that can be set up
with very few steps, and be accessible from anywhere an Internet
connection can be had. If you require users look up directions on how to
open ports on their router, you'll be loved by security conscious geeks,
and panned by consumer electronics reviewers.

The best hope might be to see commodity IoT cloud services (like AWS
IoT) develop, all using a common protocol. Then your IoT device might
come out-of-the-box configured to hit the IoT cloud service the
manufacturer partnered with, but could be reconfigured to hit a
different one.

Same goes for the manufacturer supplied app. By default it connects to
the commodity cloud server they chose, but it is configurable to connect
to others.

Don't want your private data to leave your LAN? No problem. Spin up an
open source implementation of the IoT back-end, and point both your IoT
devices and apps there. Need WAN access? That's up to you to open a
firewall port, ssh tunnel, or use a VPN.

Now you have happy clueless consumers, who can stick with the defaults,
and you have happy geeks that can configure things they way they want.

So what might this commodity middleware be?

It looks like MQTT could be it. That's Message Queue Telemetry
Transport, an ISO/IEC standard. It specifies a light weight
publish-subscribe messaging protocol layered on TCP/IP.
https://en.wikipedia.org/wiki/MQTT

There are open source implementations of this, including Mosquitto
(http://mosquitto.org/) and RabbitMQ (via MQTT plugin). Others listed
here: https://github.com/mqtt/mqtt.github.io/wiki/servers

Amazon uses MQTT for their AWS IoT service.

MQTT is not the only game in town. XMPP (Jabber IM protocol) and
Constrained Application Protocol (CoAP) are some other possibilities,
but MQTT might have more momentum.

Vendors will still want to create web portals that implement proprietary
UIs to present the data from MQTT, but most will provide mobile apps,
which should continue to work after the vendor has pulled the plug on
their back-end servers or gone out of business.

The MQTT middleware also provides an API where a 3rd party application
(or a custom application you write) can subscribe to monitor data from
your IoT sensors. You'll still have to reverse engineer the data, but at
least you won't have to reverse engineer the protocol.

Now our job as consumers is to demand that IoT vendors use something
like MQTT, adhere to the standard, and provide configuration options on
both the IoT device and the apps, to make using an alternate MQTT broker
possible.

 -Tom