This blog post contributed by Markus Van Kempen, a Canadian SAP Mobile leader.

How does sensor integration with the Message Queue Telemetry Transport (MQTT) protocol and the Internet of Things cloud work, and what makes it so special?

My colleagues keep telling me how cool MQTT is—it’s the protocol of the Internet of Things (IoT). So I went on a quest to understand what’s so great about MQTT and investigate how it works with devices, sensors and the Internet of Things cloud. To do this, I built a scenario to see if I could get some of my devices to communicate with the IBM Internet of Things Foundation. I also visualized the sensor data in a graph using a local application on my notebook.

First, let’s talk about a couple of basics.

What is MQTT?

MQTT is a lightweight messaging protocol that supports publish/subscribe messaging. With MQTT, an application publishes messages to a topic. These messages may then be received by another application that is subscribed to that topic. This allows for a detached messaging network in which the subscribers and publishers do not need to be aware of each other. It’s like the electronic newspaper publishing model: there are publishers of newspapers or topics and many possible subscribers or clients.

Getting started with my MQTT project

I needed the following components for my project:

An MQTT broker or an IoT cloud (like IBM IoT Foundation)

MQTT clients or applications

Devices

There are several brokers (for example, mosquitto.org and other IoT clouds available on the Internet that you could also use. The task for the broker is the registration of publishers or devices and the distribution of messages to applications that subscribe to the specific message topic. I used our IBM IoT cloud, also known as the IBM Internet of Things Foundation, for my prototype as the MQTT broker.

As an MQTT test client, I used Paho, which is a commonly used Eclipse-based MQTT client.

The general information flow

A device that is registered with IBM IoT Foundation may publish event data or consume command data using the MQTT protocol. The Eclipse Paho MQTT client is used to publish and subscribe to the IoT cloud.

Now I needed a device or sensor that I could pull or publish data from. I looked around my desk and found my Pebble smartwatch, the Moto 360, Google Glass, Tile, Electric Imp, Leap Motion and my smartphone, but all these would require more coding to get some results. (By the way, there is also an Android sensor app from IBM you could use to get data like an accelerometer.) I decided to use one of our Nest thermostats as a sensor, hoping for the easiest route, with less coding.

After browsing GitHub, I found a simple Node.js project that allowed me to pull data from Nest (note that there is an official application programming interface, API, from Nest that offers a lot more functionality). I also found an MQTT Node.js implementation that allowed me to publish or subscribe using the MQTT protocol to a broker. After I mashed the two JavaScript files together (the MQTT client and the Nest project), I was able to pull the data from my Nest devices and publish to the IoT cloud. In order to use the IBM IoT cloud I had to sign up and register my notebook (MAC address) as a device. After that, I was able to see the message from my Nest thermostat in the IoT cloud.

Now I had a virtual device using my notebook that would publish Nest temperatures every five seconds or so to the IoT cloud, with the following JSON messages format:

The hardest part so far was registering the device (my notebook) on the IoT cloud and dealing with the authentication tokens, which took a couple of tries. My example code in GitHub should be very self-explanatory.

Since I now had the data in the IoT cloud, I wanted another client to subscribe to the message/topic and visualize the Nest temperature data. I found a visualization tool that was part of the IBM IoT Starter that allows you to run locally and pulls the IoT cloud device’s data to visualize the message from a specific registered device.

If I change the temperature using the Nest app, my MQTT client would be notified of the change and display the change in the target temperature.

There was one more thing I wanted to accomplish: sending a command from one of my MQTT clients to the device, which would essentially be doing the same as the Nest app could do.

I added some JavaScript code to my MQTT proxy run on my notebook, which subscribed to a command topic like the following code snippet:

client.subscribe('iot-2/cmd/settemp/fmt/json');

When I received a message event like client.on('message', …)I would check to see if the JSON message had a target temperature and device ID that I could use to set the new temperature in Nest with the following function:

nest.setTemperature(deviceId, myNewTargetTemp);

Now I had basically the mechanics in place to do what the Nest app already does using MQTT and IBM IoT Foundation.

My conclusions about MQTT

It was fun to tinker with the MQTT protocol and to try to find a new way of pulling information and making devices talk to each other. One of the coolest features was the subscription that would automatically notify me of events. In the past I would have to constantly ask the server for an update. MQTT also shines in its concept simplicity and in various implementations. I think MQTT will be the protocol of the Internet, but it may also be the future of messaging in mobile and web apps and has the potential of being the next Ajax!

This blog post is contributed by David Marshak, who focuses on IBM's MobileFirst Platform, Bluemix Mobile Services, and strategic partnerships in the mobile space.

I am confident that 2015 will be dubbed the year of the wearable. The introduction of the Apple Watch will validate the ever-growing number of devices and use cases that we currently see on the wrists, lapels and even faces of early adopters. Wearables are the first real wave of the Internet of Things (IoT), where virtually everything will have a connection to everything else. The reason wearables lead the IoT is that they have a killer application: personal health. Tracking steps, miles, heartbeats and sleep has both perceived and real benefits to a wide variety of individuals.

Classes of wearables

Wearables come in two classes: dedicated wearables and wearable accessories.

Dedicated wearables are stand-alone (generally single-purpose) devices, meaning they can operate by themselves without continuous connection to a smarter device such as a mobile phone.

Dedicated wearables are not limited to the many step-tracking wristbands that have become the emblem of the health-conscious, tech-savvy set. One interesting example that I have seen is SunSprite, a small lapel-clipped device that measures and tracks how much light you are getting and lets you know if you need to get outside more or use some sunscreen. Another lapel device is Lumo Lift, which warns you when your posture is bad.

These devices clearly fall into the health category. But there are two other types of wearable applications that hold great promise. I call these access and payments wearables. Access wearables allow people to enter or leave areas without having to use a key, badge or other pocketable artifact. This could be an employee badging into a corporate building or a doctor entering an operating room; or it could be a child leaving a playground or yard. We already have a good parallel for wearable payments with transponders for cars going through tollbooths. This can easily be extended to people using mass transit, entering a theater or riding a taxi. Interestingly, the best example of both is the same device: the Disney MagicBand. This wristband is both the key to your room at a Disney hotel and a way to instantly pay for items at the Disney theme park.

Wearable accessories are devices that require connection to a smart device (such as your phone) for communication and data storage. They are generally multipurpose devices, the smart watch or smart glasses being the best examples. Wearable accessories are poised to replace some of the dedicated wearables, particularly in the area of health.

What this means for mobile applications

From a mobile app development point of view, dedicated wearables tend to be closed systems. The company that owns the device tends to own the application or applications that are enabled. However, some companies might be able to provide unpublished application programming interfaces (APIs).

Let's say you want to build an app that warns you if you are starting to fall asleep when driving. It would be very cool to use something like the Lumo Lift to trigger the warning, and the company’s website does mention private APIs, so you might be in luck. But in most cases, a device would need to be modified and APIs would have to be opened up. So unless you are heavily investing in the devices themselves, you should probably focus more on wearable accessories.

Wearable accessories tend to be open systems, with APIs available to add capabilities to and/or pull data from the device, as well as developer support. There are now growing ecosystems around iOS and Android wearables, and soon we’ll likely see mobile application platforms, such as IBM MobileFirst Platform, to support wearables.

Key considerations for wearables

If you are planning to incorporate wearable accessories into your mobile application strategy, first consider whether your target users will actually wear the device when you need them to. In other words, is the wearable accessory always with the user? The answer isn't just a simple yes or no. It needs to be compared to the current "always-with-you” device: your mobile phone.

Let's look at the smartwatch. Do you wear a watch? I do, and I almost always have it on (when I also have my phone). However, my kids do not wear watches. Their phone is their watch, and it’s farfetched to think that they’ll start wearing one (however cool) to get information that they already have on their phones. That said, we who do wear watches will likely want more features before we consider that our primary device. The phone will still be the default, go-to experience.

A second consideration is what should be written to phone experience versus device experience. Aside from the inelegance of having duplication on both devices, we do not yet have any best practices on what we should run where. Low-level considerations such as battery life, storage and communications are important factors. More significant will be when the user experience is actually different—for example, how much of a benefit is it to swipe your watch (versus taking out your phone) to pay for your coffee?

Until we better understand the benefits and desired user behavior and outcomes for wearables, I would recommend that the main focus remain on the phone.

Ultimately, we may find one or more perfect wearables, but today the phone is always primary (and even required), and the wearable remains a nice to have—or in the case of the Apple Watch, a very nice to have!

To share your thoughts on wearables, please connect with me on Twitter @DavidMarshak.

This blog post is contributed by Bryan Boyd, a solutions software engineer for IBM MessageSight.

"How am I going to find you in the crowd?"

Running a marathon requires support—lots of it. You need energy gels, sports drink and, most important, encouragement. Two days before my first marathon last February, I was trying to explain to my wife exactly when and where to meet me on the marathon course to provide support. As she asked the question above, I realized that "I'll be passing mile 17 sometime between 9:30 and 10:00 a.m." is a pretty imprecise answer!

Being your typical software guy, I like to hack together useful applications in my free time. In my role with IBM I get to do the same thing: hack together demo applications that showcase the "art of the possible" in the Internet of Things (IoT) space, using the IBM MessageSight appliance and lightweight MQ Telemetry Transport (MQTT) publish/subscribe protocol. So the next day, while resting for the race, I combined work and play and built a real-time marathon tracking solution: IBM RaceTracker.

How does it work? In a nutshell: a GPS capture device publishes location data to a message broker, which is consumed by an analytics application (capturing mile splits, average pace and so on), which publishes stats and events to the message broker that are consumed by a mobile web application and a "tweeting" application.

That’s a lot of components! Here's some more info:

1. The GPS capture device I selected is the iOS/Android app OwnTracks, an open-source "location diary" that continually publishes a message with location information at a periodic interval (for example, every 5 seconds or 10 meters moved). OwnTracks is perfect for this solution because of the simplicity and ease of configuration: just configure the publish topic, point to a messaging broker and your location information starts getting published. Here's an example:

2. The publish/subscribe protocol used here is MQTT, a lightweight messaging protocol perfectly suited for the Internet of Things. MQTT conserves battery life on the mobile, has clients for nearly all major platforms and languages, and uses a simple programming interface that is easy to integrate into any application. The messaging quality of service (QoS) is configurable: because of the large number of cell signals (runners and spectators) clustered near the starting line, the "exactly once" QoS was perfect for times during the race when my cell signal was lost momentarily.

3. The messaging broker is IBM MessageSight, a messaging appliance optimized for the IoT. It is tuned for massive throughput and scalability, with the ability to handle up to a million connected clients and up to 12 million messages per second. In other words, we could use one appliance to track runners at the largest marathons (NYC, Boston, Chicago) at the same time!

4. I built theanalytics application in Node.js and deployed to Codename: BlueMix, IBM's platform as a service (PaaS) solution based on Cloud Foundry. Node.js has several MQTT client modules available; I chose the MQTT module. The analytics application is very simple: it subscribes to an MQTT wildcard topic for all runners in a particular race (RaceTracker/AustinMarathon2014/Person/+). When the application receives a message on this subscription, a few things happen:

Add the data point (timestamp and location) to a data structure tracking the most recent N updates for this runner.

Calculate the pace for the runner, as a weighted average over the last N updates.

Publish a text label MQTT message containing a pace description (for example: {"text":"Pace: (about) 8:15 min/mile"}) on a topic that will be consumed by the RaceTracker UI.

Calculate the distance from the current position to all landmarks (mile markers, start line, finish line). If the current distance is less than 20 meters, the runner has reached the landmark and an MQTT message is published onto an event topic, which will be consumed by the RaceTracker web application and “tweeting” application.

The analytics application also keeps a static definition of the race in the form of a course map (a set of longitude and latitude coordinates making up the route) and landmark positions. When the application is first started, the MQTT client publishes this information as MQTT "retained" messages (the MQTT broker will retain these messages for new subscribers).

5. The RaceTracker application is a mobile web app built with the OpenLayers JavaScript mapping framework. The app connects an MQTT WebSocket client to MessageSight and subscribes to the "label," "event" and "runner" topics: when a message is received, the UI is updated dynamically. One benefit to using MQTT to deliver data to the app (rather than using a REST API) is that no polling is required: the MQTT WebSocket connection is kept open while the app is in use, so new data is pushed to the map as soon it is available. As a result, the application is the best of both worlds: real-time with low battery usage!

6. Since my analytics application is already publishing events through IBM MessageSight at key moments of the race, I can easily consume this information from multiple subscribers. Along with consuming the data in the web app, I created a simple Node-RED flow to convert the "events" to "tweets," published on the account @bryanboydruns.

This solution worked perfectly! My wife and friends were able to view my progress in real time and easily find me on the course to hand out sports drinks and high fives. About twenty-five others used the app and Twitter feed to follow my progress remotely. My father even watched my progress from a restaurant in Germany, with the wait staff cheering me on!

The demo is accessible here, with my race data running in a playback loop: http://m2m.demos.ibm.com/RaceTracker. When participating in a race, I will switch the demo over to a live feed from OwnTracks running on my iPhone.

It's amazing how simple it is to build applications in a publish/subscribe "IoT environment," where many "things" (iOS app, analytics app, web app, tweeting app) communicate with each other through a central messaging broker in real time. The fact that I crafted this in less than a day is evidence of that.

I want to hear from you! What is a mobile or IoT solution you have built to solve a personal, real-world problem? Leave a comment below, or reach out to me on Twitter at @bryanboyd.

I'll be demoing this and other applications at IBM Impact, April 27 to May 1 in Las Vegas. Stop by the IBM MessageSight Gaming Zone or attend my Thursday afternoon session (IOT-1912) to learn more.

This blog post is contributed by John Samuel who focuses on the Internet of Things and M2M with IBM.

You might have seen my previous articles about how technology like IBM MessageSight can connect cars or help insurance firms reduce installation costs. I use these two scenarios when I talk to audiences about IBM MessageSight, and because most people drive cars, they always listen and become engaged in the discussion. But nothing gets an audience talking more than a demo, and it is even better if they can take part in that demo.

Well thankfully there is an awesome demo available that I use during these presentations. It is called StarFighter, and it is based on 1980s arcade games like Asteroids. You too can access it here.

Up to twenty players can play at once, so you can ask your audience to just access the link if they’d like to have a go at it. While the willing volunteers are busy playing the game, you can explain what is happening by showing the viewer panel. A quick warning here: you might have to re-explain what was happening as this game is so addictive and competitive that the audience can become fixated on it and might be unable to hear your explanation.

So let me explain what it is showing and why it is so awesome. Each time you hit a control button like the space bar (fire button), cursor button (left or right arrow) or thrust button (up arrow), an MQTT (MQ Telemetry Transport) message is sent or published to the IBM MessageSight appliance, which then sends an MQTT message with that action to all the subscribing players. This way the other players see your bullets or maneuvers in their browsers or on their mobile devices. The really cool bit I like about this is the shear speed—all this happens in near real time!

Because these actions happen in almost real time you can avoid being blasted by the others playing the game or you can do your best to blast them out of the game. Each time your spaceship hits a space rock you get points, and if you destroy another spaceship you get more points. For those of you who might get addicted, there are multiple levels to play. The harder the level, the more points you will get for blasting stuff, but beware because your shields won’t protect your ship for as long and aren’t repaired as quickly.

I like presenting this action demo because I’m rubbish at playing it: my name, JS, doesn’t appear on the leaderboard often.

What it does show to mobile app developers and designers is how MQTT can be used to send data from mobile devices either to another mobile device or into the enterprise by leveraging the power of IBM MessageSight. Because IBM MessageSight is also a secured appliance, it can safely be put at the edge of a data center in the DMZ so the company doesn’t have to open scores of firewall ports to potentially hundreds of thousands of mobile devices. Keeping a firewall strong is a recommended way of keeping yourself safer from hackers, so this is an important point if you are deploying mobile apps.

I’ve heard it said that we learn quickly and easily through games, and this StarFighter game certainly helps to show that. It is a great assistant when I’m explaining how IBM MessageSight can help get data from multiple mobile devices back to the companies that need that data.

So why not have a go and have some fun while you learn? Be careful though, playing this game to excess can lead to extreme extremeness.

If you are interested in trying out IBM MessageSight for yourself, you can download the virtual appliance at no cost here.

Have fun and please feel free to comment here if you like, or follow me on Twitter @JSamuelatWork as I often post about the Internet of Things.