Mobile messaging protocols like MQTT use the Pub/Sub broadcast communications model

Notifications are becoming a core buildings automation technology, as explored in my last post about the MQTT messaging protocol, as well as earlier when discussing contextual mobile operating systems.  Pub/sub is a routing style designed for broadcasting out notifications one-to-many, listening for responses back from unknown sources, and compensating for the sometimes intermittent service of wireless networks. The same underlying publisher/subscriber technology is ideal for sensor communications in buildings.  In fact, the MQTT open source community is working on a specification with ultra-light capabilities just for sensors — MQTT-SN,  ideal for routing on familiar building wireless protocols like Zigbee.

Rick Huijbregts of Cisco wrote a prophetic post in July of 2012: My Building Tweets and has Friends on Facebook.  His predictions about the social-media-ization of buildings are certainly starting to come true. Moreover, facility managers, building system integrators, and other stakeholders in automated building operations should take a closer look at the Pub/Sub-MQTT style of notification communication that supports Apps like Facebook Messenger.

Consider the mobile App category of Friend Finders.  One use-case is the scenario whereby you are walking past a pub wondering if you have any friends already inside or nearby.  You click on your Friend Finder app to get an answer. You send out a notification to call a quorum. You are the publisher when you message out  “I’m here.” All friends that get that message on their App-equipped phones – or PC computers (it doesn’t matter; notifications are hardware-agnostic) – are the ‘subscribers.’  Any one or number of those parties may then message back.

Then consider how home automation developers like those involved in the Eclipse SmartHome project are using Pub/Sub communications to overcome the current lack of interoperability among connected-home products:  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.  All they need is the notification, the settings are preprogrammed. When the homeowner 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, etc.

Francis daCosta in his book Rethinking the Internet of Things: A Scalable Approach to Connecting Everything  also foresees Pub/Sub as the communications model for the Internet of Things. He says,  “Fundamentally, traditional IP-based peer-to-peer relationships lock out much of the potential richness of the Internet of Things. There will be vast streams of data flowing, many of which are unknown or unplanned. Only a publish/subscribe architecture allows us to tap into this knowledge by discovering interesting data flows and relationships. And only a publish/subscribe network can scale to the tremendous size of the coming Internet of Things. So appliances, sensors, and actuators must use self-classified traffic schemes to allow for discovery and creation of information “neighborhoods”.”

To reiterate the point from my earlier ‘Part 1’ post on MQTT: the “Internet of Things” is a misnomer. Much of the IoT is not happening on the Internet , rather the momentum is building on M2M networks carrying mobile notifications. Moreover, lots of Pub/Sub messages flying around doesn’t mean insecure and unreliable. Quite the contrary. There is a lot of open source developer energy focused on constant improvement of the security and robustness of mobile messaging.

In the pub/sub model, publishers control their subscriber feeds; and subscribers have the power to weed out feeds they don’t want.  You step on your connected bathroom scale: who do you want to see the resulting number?  Your doctor?, your weight-loss club members?, your insurance company? your entire facebook friend list?  You decide your subscribers, and access is limited in time/amount. Paul Fremantle gave this example in his talk on IoT security at EclipseCon 2014, and he offers more detail about the coming Federated Identity Management system in this Slideshare. Is Federated Identity the answer to how the data flows coming  from building equipment subsystems will be owned and managed in the future?