April 2014 |
[an error occurred while processing this directive] |
IoT Opens to Mobile Messaging Standards the Direction is toward Open Standards
|
Therese Sullivan, Principal, www.buildingcontext.me Contributing Editor |
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
The
automated buildings industry is fortunate to have seasoned leaders that
understand Open Source ecosystems. The history and future of
OBIX, the generic web service interface for control systems, is a good
example. I’m grateful for Toby Considine’s consistent and thorough
reporting on OBIX (open Building Information Exchange) as well as
Ken Sinclair’s OBIX call to action. Ken emphasizes that, to make open
source work, the community needs to constantly contribute energy and
remain vigilant to counter any forces working against openness.
Coexisting with OBIX web standard, there is another open standard
effort underway for the mobile messaging layer that the buildings
industry should know about: MQTT (Message Queueing
Telemetry Transport). When you consider the use of such messaging
protocols in today’s news-making connected car, connected health,
connected home solutions, it’s clear that the ‘Internet of Things’ is a
contradiction in terms. Things are not actually communicating on the
TCP/IP-defined Internet; they are messaging each other on mobile M2M
networks.
While a web-centric standard like OBIX defines how to send requests to
a known source identified by an IP address via TCP/IP communications
over Ethernet, an M2M messaging protocol like MQTT needs to accommodate
broadcasting one-to-many, listening for responses back from unknown
sources, and relying on the sometimes intermittent service of wireless
networks. Mobile messaging works for small-device communications,
like sensor events, where the data packet size is small, but potential
volume of sends and receives high. It is a lightweight protocol that
can function on top of the TCP/IP protocol. To quantify the
meaning of lightweight, MQTT is said to be 93X faster, 8X less
overhead, 170X less battery to receive on mobile networks versus
HTTPS. MQTT was originally developed by IBM, but in November 2011
IBM contributed all the code to the open Eclipse Paho (C, Java,
JavaScript, et al.) Project. The Eclipse Foundation is an open source
community providing the building blocks that will lead to an open and
interoperable Internet of Things. In this landscape of The Internet of
Things prepared by IoT market investor and reporter, Matt Turck, MQTT
is listed as a Protocol Building Block along with Wi-Fi, Zigbee, RFID,
Bluetooth and other familiar names. While there are other M2M messaging
protocols supported by the Eclipse Foundation, MQTT has the greatest
traction for sensor networks and the Internet of Things.
MQTT is designed for publisher/subscriber or Pub/Sub communications. To
cite a big-name example, Facebook Messenger is based on MQTT. So
when your teen uses her smart phone to Facebook-message out “My
soccer team just won!,” she’s the publisher. All friends that get that
message on their Facebook Mobile App-equipped phones - or even those at
home on their PCs with their Facebook application open - are the
‘subscribers.’ Any one or number of those parties may then message
back, “Great! Meet you for ice cream.” And the messages fly back
and forth among tens or hundreds of connections playing the roles of
publisher/subscriber, ad infinitum. Rick Huijbregts wrote a prophetic
post in July of 2012: My Building Tweets and has Friends on
Facebook. While the coming social-media-ization of buildings that
he predicts is certainly coming to pass, the Pub/Sub-MQTT style of
communication that supports it may have an even more profound impact on
building automation.
The collective energy of its open source community has advanced MQTT in
other ways too. To help manage wireless network risks, MQTT supports
QoS (quality of service) levels like ‘fire and forget” “delivered at
least once,” “delivered exactly once.” For security, MQTT brokers
can enforce username and password authentication from clients to
connect. To ensure privacy, the TCP connection may be encrypted with
SSL/TLS. The big names in big data want a stable and widely supported
MQTT standard so they can build their own IoT platform on top.
IBM is working with big chip and module manufacturers on built-in
support for IoT MQTT protocol and IBM IoT Cloud which is rolling out on
IBM Softlayer cloud. SAP, Oracle and Microsoft Windows Azure are also
Eclipse Foundation members with their own MQTT initiatives.
[an error occurred while processing this directive]The Eclipse IoT community came together
at EclipseCon2014 in mid-March, including a full day of M2M IoT
sessions and a demo of the Eclipse SmartHome project. This project
focuses on the the current lack of interoperability among
connected-home products. To date, you haven’t been able to
program an action on one device — be it a digital thermostat, alarm
system, advanced lighting control systems or smart phone — to be
triggered by the status change of another. The Eclipse SmartHome
project is all about standardizing the overarching automation logic. It
is built on the open standards OSGi Alliance platform for Java-based
software development - another open-source effort, like OBIX and MQTT,
which has survived the test of time and benefitted from an open
community ecosystem.
An MQTT extension is planned as the M2M communication channel for the
Eclipse SmartHome project. You can imagine the Pub/Sub communications
this will enable: a homeowner’s fitness wrist band publishes out the
encrypted message “Gone to sleep.” The subscribing alarm,
lighting and HVAC systems get the message and adjust accordingly. When
he wakes in the middle of the night for a trip to the kitchen or water
closet, a presence sensor publishes “Up and moving” and the subscribing
lighting system brightens all the right lights instantaneously. Then
the mobile calendar App publishes a calculated wake-up time based on
appointments and travel time factoring in traffic and weather. The
subscribing HVAC system uses this to determine the right moment to
initiate its warm-up cycle. Progress in this direction is happening
fast, and, to paraphrase a quote from Toby Considine’s February OBIX
column, “When App culture and App technology come to smart homes, Smart
Energy Apps for commercial buildings won’t be far behind.”
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]