15 comments

[ 3.6 ms ] story [ 47.2 ms ] thread
This has huge implications - imagine every "thing" having a freely-available API. Combine that with predictive analytics and we can come really close to predicting the future.
An economy with realtime and complete data. Imagine the efficiencies created then.
Imagine the surveillance endemic to the system.
Yes, and frankly the micro-managing boredom. From my perspective, any system like this is starting to serve the needs of the platform in place of the needs of the consumer.

My car already has a light for when the oil needs to be changed. I don't need an oil-changer showing up at my door or the service-station calling me.

We have to fight for every ounce of privacy these days - why should anyone be expected to turn the whole life of their family into, essentially, an EZ-Pass?? No thanks . . .

That's exactly the point.One of the most promising uses of data that might be transmitted with this protocol is Behavior Based Maintenance. Most equipment maintenance these days is time based; the new goal is to be able to analyze data coming from the equipment (vibration, fluid flow, temperatures, etc) and predict that a failure is imminent and send a service person out before the equipment even shows any outward signs of failing.

Most of the businesses that want to do this don't even have the data they need to get started and don't have a clue where to begin. Having an industry standard comms protocol may be just what it needs to really take off. I've been watching the space for a while, looking for an opening that a startup can fit into.

Don't get too excited just yet - actually putting a sensor on everything would cost a huge amount of money and anything besides a passive RFID tag or barcode would need a battery. Consumers would need to pay an extra few dollars for everything and would need to replace batteries on everything they own every year or so. These protocols don't really do anything - the research community has bounced stuff like this around for a while. Someone actually needs to build better hardware before the Internet of Things vision actually comes true.
Check out http://www.ccnx.org/ for another protocol with similar intentions. CCNX supports a whole load more, including unified routing and caching, multi-path, enumeration, isn't designed just for small data (i.e. it's perfectly feasible to publish/retrieve terabyte-sized videos over it), and originated with a team that included Van Jacobsen.

MQTT seems more focused on small devices and ultra-low bandwidth, which could be a good or bad thing. Considering the overheads of CCNX (header size is 64-128 bytes IIRC), I'm not convinced a minimalist protocol for this stuff is such a good idea, given even the tinyest hardware around these days, and currently prevalent wireless communications protocols could already easily handle something that heavy.

(comment deleted)
Well, I guess that explains why Pachube went to a free service earlier this week.
Does anyone know of any existing hardware/gadgets/do-dadds or mainstream software that utilizes this MQTT? I've never heard of it until just now (which doesn't mean much, but it's new to me).
I thought that this sounded neat until I read the part about bridging "SOA, REST, Pub/Sub and other middleware architectures". And realize that IBM is doing nothing more than creating a new buzzword and marketing it with a bunch of (probably out-of-touch) prognostications that the web is going to need ten years in the future.

I hope this turns out well, but I don't plan on holding my breath.

For those following the IPv6 issues - this is one of the real, justifiable, not-fluffy ideas that make sense for IPv6. Even then, this idea is still fluffy. RFID is a cool idea, but too passive for some of the cooler applications.

I think it's neat, but it will be stagnant until we make really tiny wifi chips, extremely flexible mobile broadband plans for multiple devices per person, or create new low-power, low bandwidth, ad-hoc wireless networks for these applications.