IoT Course Week 3: Publish/Subscribe and Message Queues for Integration

Screen Shot 2015-10-15 at 3.07.21 PM

Demoing Previous Week’s Work

Students began the week by demoing their assignment from the previous week – building a  Kivy/Python touchscreen application (see previous post Week 2) to control the Hue, Saturation, On/Off, and Brightness of LAMPI.  The Kivy/Python application changes the PWM hardware signals, based on user interactions.

Screen_Shot_2015-08-28_at_1.41.45_PM (1)

That was a good first step, but, unfortunately, is exactly how we might have built an embedded product like that ten or fifteen years ago – a User Interface (UI) directly manipulating hardware.  That architecture starts to fall apart as soon as an additional UI (say, a web or mobile client) or a service (say, an analytics system) needs to be integrated.

Publish/Subscribe Architectures

When we want to add another “client” of the system, like a web page, we have to rethink our architecture – the UI directly manipulating the hardware is too limiting, and drives us to a client/server model.

There are a few common and obvious client/server models:

We decided to pursue a Pub/Sub model to give the students hands-on experience with this increasingly popular model for IoT.  Pub/Sub architectures tend to be loosely-coupled and are inherently asynchronous, making recovery from offline modes arguably more natural than with RPC or RESTful architectures.

There are a number of PUB/SUB protocols available – we chose to use MQTT, a machine-to-machine (M2M) Pub/Sub standard designed specifically for IoT.  MQTT relies on a “broker”, like most PUB/SUB protocols – a service to which all clients connect.  We chose to use the Open Source Mosquitto MQTT Broker, which is well-supported on the Raspberry Pi, and is being actively developed.  Other brokers are also available, including from IBM, and HiveMQ.  Recently, Amazon Web Services announced Amazon IoT, which also includes an MQTT broker service.

In MQTT, Clients Publish Messages on Topics by sending them to the Broker.  Messages are any string of bytes – you could use XML snippets, JSON, or your own custom binary or text solution.  For this course, we used JSON, a data serialization format that uses human-readable text to transmit data objects consisting of attribute-value pairs, to represent the lamp state (Hue, Saturation, Brightness, etc.).  Messages are Published on a particular Topic – which is just a text string (UTF-8).  Clients Subscribe to Topics. The Broker will then deliver an incoming Message to all Subscribed Clients.

Screen Shot 2015-12-14 at 9.29.49 AM

For example, when a user changes the Hue of the desk lamp with the Kivy/Python touchscreen application, a JSON Message like:

{‘color’: {‘h’: 0.5, ‘s’: 0.5}, ‘brightness’: 0.1, ‘on’: True}

(“h” for Hue, “s” for Saturation) is published on the Topic:lamp/set_config

The students were tasked with creating a lamp service to serve as an abstraction layer between the hardware and the user facing software (command line, Kivy). This service will act as the single point of truth for the lamp. The lamp service is responsible for translating the MQTT messages into hardware actions, such as receiving a color change message and sending the hardware PWM commands to control the led. They constructed a simple python implementation of this service using Paho, the MQTT client library for Python. In addition to submitting their code, they had to upload a video to demonstrate the tool’s behavior.

Some commercial systems that leverage MQTT include Facebook Messenger, Amazon (mentioned above), and the EVRYTHNG IoT platform.

What is up next?

To the cloud! Next week, the students will be introduced to general cloud concepts and providers. Next, they will dive into Amazon Web Services by building an EC2 instance that will host a second MQTT broker. From there, the students will be dealing with more advanced MQTT configurations by bridging the MQTT broker on LAMPI and the MQTT broker on EC2. Along the way, Unix daemons will be created and managed.