Category Archives: Internet of Things

IoT Course Week 6: Setting Up User Accounts


Welcome to Week 6 of the Case Western Reserve University IoT course. Over the next two weeks, we will be tackling a new kind of challenge: security. This week kicks off by setting up the web framework Django.

Last Week

Last week, students spent time setting up a static webpage on EC2 that communicates via MQTT to their hardware LAMPi’s. We kicked this week of with a demo and discussion about what everyone was able to accomplish.  See the previous week’s post here: WEEK 5 POST

Why Django?

Despite the multitude of web frameworks available, using Django was an easy choice for this project. It is a mature, modern, web framework with a highly active community. It is easy to configure to work with many different databases, and is shipped with a robust ORM at its core. It supports user account configuration out-of-the-box, as well as a powerful admin interface. The fact that Django is Python-based is just an added bonus, allowing the student’s Python experience on LAMPi to be transferred to the Web.

Linking user accounts

Step one was to get Django set up and configured to have user accounts through its default interface.  Details of how to do that can be found in the Django Documentation.  Students were provided with a sample login template which, when loaded through Django, looks just like this.

Screen Shot 2016-02-11 at 10.10.59 AM

Students changed their static hosted pages to be hosted through Django, and added the provided login template to web/lamp/templates/login.html. With a configuration of the routes, navigating unauthenticated to the root page will now redirect the user to this login screen. 
urlpatterns = patterns('lamp.url',
    url(r'^$', login_required(views.index), name='index'),
    url(r'^logout/$', views.logout_user, name='logout_user')

From here, the static LAMPi control page is moved to the index template at  web/lamp/templates/index.html and the request is handled in the Django view logic through the addition of an index function in web/lamp/

def index(request):
   user = request.user
   lamps = user.lamp_set.all()
   context['lamps'] = lamps
   return render(request, 'index.html', context)

Whats next

At this point, students have taken the first step into providing user access control to the LAMPi system. Our more security conscious readers will note, however, that virtually every point of integration within the LAMPi system at this point still remains completely insecure. Moving into Week 7, students will receive a crash course in common attack vectors and practical implementation of modern communications cryptography.

IoT Course Week 5 : Lampi Control From The Web


Welcome to week 5 of the Case Western Reserve University IoT course. Last week’s lesson, though backed by a massive amount of behind the scenes work, left something to be desired from a usability standpoint. By the end of this week’s lesson, the pieces will all begin to fit into place.

Demoing Previous Week’s Work

Class kicked off with a discussion around the previous week’s work. By following the MQTT protocol, students had bridged their Python controlled LAMPi’s to an Ubuntu server running on Amazon EC2. See the previous week’s post here: Week 4.

Building a Web Interface

To continue our effort of doing the simplest thing possible, students began building their web interfaces directly on NGINX. Though other popular web frameworks (e.g. Rails, Django) have web servers built in, in many ways they are rarely designed for high transaction throughput. In the future, it will also be important for students to be able to configure the web server to handle static and dynamic content, HTTP redirects, URL writing and redirects, HTTP/HTTPs, etc. Keeping things simple with NGINX ensures that the projects will begin on a scalable, configurable system.

Students were provided with a directory of sample HTML, CSS, and Javascript files to base their static websites from. The page resembled very much the display of the LAMPi’s control screen, just in a web form.  It is up to the students to build the functionality for the page.  


MQTT and Websockets

Last week, we were left with an EC2 instance that had been configured to listen to MQTT topics via bridging. We require a method for Mosquitto, our MQTT broker, to communicate with the controls on our static web page. TCP, the Transmission Control Protocol, via WebSockets, will provide the channel we need for this communication to take place. WebSockets provide a fast and scalable two-way communication that our web client can harness via Javascript. There is an added bonus that Mosquitto supports WebSockets out of the box, making setup as simple as specifying a TCP port to accept connections from.

Paho and Javascript

Paho was briefly covered in the Week 3 post. Following that pattern of use, we utilized the Paho Javascript client to communicate with Mosquitto. Paho supports websockets, so connecting to Mosquitto is as simple as connecting to the same TCP port that Mosquitto is active on.  Below, we have included an example of coding that demonstrates connecting paho.js to tcp.

var client = new Paho.MQTT.Client(hostAddress, Number(hostPort), clientId);
onConnect : function(response) {
onMessageArrived : function(message) {
configurationState = JSON.parse(message.payloadString);


Once this connection is made, we add the following code to sync the LAMPi state from MQTT to a javascript object that looks like this:

var lampState = {
color : {
h : .5,
s : 1,
brightness : 1

And finally, a little bit of Javascript which uses Jquery to manipulate the sliders to match this lamp state:

function setSliderValues(hue, saturation, brightness) {
$( ".hue" ).each(function(index, hueSlider) {
hueSlider.value = hue;
$( ".saturation" ).each(function(index, saturationSlider) {
saturationSlider.value = saturation;
$( ".brightness" ).each(function(index, brightnessSlider) {
brightnessSlider.value = brightness;

updateSliderStyles(hue, saturation, brightness);

Witness the Big Picture

We now have a full path messaging system, from the Lampi to the cloud, and back again! When the LAMPi interface is changed on the device or the static webpage just built, the change is mirrored on the other interface instantly.

Next Week!

Next week, we’ll tackle a glaring problem in this system: security. Security in the IoT space has been a huge point of conversation as devices continue the path of hyperconnectivity and intelligence. At this point, there is no access control or security of the LAMPi system. We will take a big step forward, and add a web framework to give us greater control over users and access.


IoT Course Week 4 : Introduction to the Cloud


It is week four of the IoT course and students of Case Western Reserve University have successfully built their very own touch-screen controlled LAMPi’s. This week students will take a major step towards greater functionality and control.

Demoing Previous Week’s Work

Students began the week by demoing their assignment from the previous week – building a  Python service to act as an abstraction layer between the LAMPi hardware and the various user interfaces. You can check out the post for the week here: Week 3

Learning IoT the hard way – Why we are not using an IoT platform

This week’s lecture started with a brief introduction to available commercial IoT platforms. For this course, students will forego working with a commercial IoT platform, and delve directly into Amazon Web Services. By having the students build their own platform on top of AWS, they will gain a greater understanding of the various components involved, which will allow them to make informed decisions when dealing with commercial IoT platforms in a professional capacity.

To the cloud – Amazon EC2

The cloud! Yes, that cloud. Those nebulous servers in the sky. Students will be maintaining their cloud connectivity using AWS Elastic Compute Clusters, or EC2.  At the beginning of week 4, the services running on LAMPi were locally controlled through a MQTT broker called Mosquitto. The goal for this week is to bridge the MQTT broker running on the Raspberry Pi, to another MQTT broker running on EC2. Luckily for our students, with a little configuration, Mosquitto offers this functionality.

Students began by setting up free tier EC2 instances running Ubuntu. After configuring AWS security groups for their instances, they installed the Mosquitto command line utilities mosquitto_pub and mosquitto_sub.

Bridging between Mosquitto brokers is done through editing configuration files on both the host and the remote. When bridging, the user can configure what topics are transmitted in which direction — for instance, we can specify that only lamp state updates go out to the cloud, and only configuration changes are received from the cloud. Any topics not configured do not get to cross the bridge and will remain on the system they originated. The configuration to the remote follows the structure here:

connection <bridge_name>
address <IP>:<port>
topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
remote_clientid <remote_clientid>
cleansession <true or false> (defaults to false)

Following this pattern will open the bridge between the MQTT brokers. From that point, depending on the configuration of “In” and “Out” directions, messages will be passed from the appropriate publisher to its subscribers.  It is worthwhile to note that, although the broker is now up and running on EC2, there is not yet any functionality beyond simply passing messages. This will be the topic of the next lesson. Part of the reason for this is that configuration of Mosquitto can be complex and that complexity is compounded by the configuration of the whole system — security, supervisord, pigpiod, etc. By doing this in steps, we can test our system at each step of the way. For now, a few more steps are required to ensure our path from the Raspberry Pi and EC2 instance remain unbroken.

Unexpected Events – Last Will and Testament

The MQTT specification defines a mechanism called a Will. In the event that a client disconnects unexpectedly the MQTT server will publish the Will message. The students will use this mechanism to announce the connection state of the lamp. In Python, the code looks like this:

       client = mqtt.Client(client_id=CLIENT_ID, protocol=MQTT_VERSION)
                       “0”, qos=1, retain=True)

Service management – Supervisor

The students were introduced to a Linux service called Supervisor which is responsible for ensuring that all of the processes that we care about stay running. If the LAMPi is unplugged, or the cloud service restarts for some reason, a proper Supervisor setup will ensure that all systems are restarted and running. These concepts were applied to the LAMPi’s by creating a Supervisor D configuration file that will keep the lamp service and the UI running.

What is up next?

Next week, the students will be introduced to web interfaces and the servers that host them. They will be utilizing HTML, CSS, Javascript, Websockets, and NGINX to create a web interface to LAMPi. This will build upon the the work they accomplished this week by hosting the web server on their EC2 instance.

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.

IoT Course Week 2: User Experience and User Interfaces

Screen Shot 2015-10-15 at 3.07.21 PM

The focus of Week Two centered around applying User Experience Design concepts to the development of connected systems.

Demoing Previous Week’s Work

Students began their second class by performing a demonstration of their first assignment. Each LAMPI had to to able to turn off and change color from red, to green, to blue, to white. Prior to the start of each class, students are required to submit their source code and upload a short video demonstrating the required functionality, as well as answers to any assignment-specific questions. This is done to ensure a universal understanding of the material, and to provide an opportunity for any clarification that might be needed.

User Experience Design

Students were given a rapid introduction to User Experience Design (UX) by Nicole Capuana, one of LeanDog’s resident experts on the subject. Her lecture explored the many challenges and opportunities that can arise when designing systems, especially when it comes to UX for IoT. Students learned that UX is about crafting an overall experience from multiple moving parts which, when done right, work together behind-the-scenes to enable users to interact seamlessly with a given system. Her lecture challenged students to “get out of the building” and actually interact with users rather than just assume people will behave according to predictions or like them. She also encouraged the students to test their hypotheses frequently, measure the results, and analyze their data, to ensure that they are creating a product that people love.

UX for IoT

When building a user experience for connected systems, particular attention should be paid to crafting a seamless experience. Working with something as commonplace as a lamp, the end user already possesses deep seated expectations about how it will work and behave. It is the job of UX to ensure that the connected functionality of the lamp will augment existing expectations, not upset them. A connected device often promises to be smart and learn over time, so it’s imperative to carefully craft the design of the device working with minimal errors or the need for the users to intervene. Method of control, physical and digital interaction, contextual awareness, and first-time setup are just a few of the many things to consider when approaching UX for connected devices. Themes introduced during this lecture were revisited throughout the remainder of the course.


To provide a manual method for controlling the lamps, students attached PiTFT touch displays to the lamp base (pictured below), and configured the screens to work with their corresponding Pi’s. They then used Kivy, an open-source Python framework for the rapid development of applications that rely on UI’s, to begin constructing the interactive interface of the touch screen display.

Kivy was chosen for many reasons. It is a modern UI framework that supports hardware acceleration, is touch optimized, and supports animations. In addition, it is cross-platform, open source, built for Python, and is MIT licensed. Kivy’s separation of UI and program logic, as well as its concise markup, has enabled us at LeanDog to employ it in prototyping client work. These traits form a system that allows a cross functional pair of a designer and a developer to rapidly build and test experiences around an implementation.

In preparation for this lecture, Nicole Capuana and Gary Johnson, a developer at LeanDog, paired to iterate through the design of the Kivy UI for LAMPI. They used a collaborative, low-fidelity exercise to build out the iterations using pen and paper mockups; demonstrating that with simple tools and teamwork, you can work through designs quickly. Students were shown the versions Nicole and Gary worked through and then were given a mockup of an initial UI to implement and begin experimenting with.

Screen Shot 2015-12-08 at 9.56.24 AM Screen Shot 2015-12-08 at 9.56.41 AM

After building their own UI’s in Kivy, the students learned how to enable their software to control the hardware of the lamp. The end result was a working lamp controlled by a touch display which allows the user to change the hue and saturation of the lamp color, adjust the brightness of the lamp via Pulse Width Modulation (PWM) (see the previous post), toggle the lamp On and Off, and have the display show the current color of the lamp.  

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

What is up Next?

Next week, students will forge onward in implementing some of the more technically advanced communication patterns to be used throughout the development on LAMPI. With the UX process fresh in their minds, students will be required to adopt a critical and iterative process aimed at improving interactions between humans and LAMPI. Utilizing the UI framework Kivy, students will build an initial user interface, paving the road for early hands on user testing. Throughout the remainder of the course, students will continue to receive practice in toolchains commonly used across professional software development teams.  

Building a Raspberry Pi Controlled Desk Lamp with LeanDog and CWRU

As mentioned in a previous post, Nick Barendt and the LeanDog Studio have teamed up to offer a Connected Devices Workshop for Case Western Reserve University (CWRU) students in response to a trend of increasing interconnectivity in product design known as the Internet of Things (IoT). In this course, students are gaining practical experience building a proof of concept system: a physical device, web integration, and mobile development.

The goal of the course is to familiarize students with each component in a complicated system, providing them with a systems level understanding of all the technologies and disciplines that go into creating a connected device

Follow along with us as our students create their very own web-controlled desk lamps, which we’ve dubbed “LAMPI” [lamp-ee]. By the final week of the course, students will possess enough experience to build their own prototype for a new product or service, or confidently dive deeper into any of the software components for further study.

The class is comprised of mostly Juniors and Seniors in Electrical Engineering, Computer Engineering, and Computer Science.  That means that there is a broad range of electronics and software development experience in the class, at skill levels ranging from beginner to advanced.  To address the variety in skill sets and levels, students are working in pairs on the lab assignments, switching up pairs each week. This method of “pairing” is widely used in the world of professional software design and a is a key practice in the LeanDog Studio. We will dive a bit deeper into the benefits of pairing in a later post.

Now, without further ado…

Screen Shot 2015-10-15 at 3.08.16 PM

Building a Raspberry Pi Controlled Desk Lamp

CWRU’s IOT course kicked off by getting students familiarized with:

  • Burning an SD card image with Raspbian (a variant of Debian Linux)
  • Booting up a Rasberry Pi (a tiny and affordable computer, with a rich community of hardware and software support)
  • Connecting to a serial console (UART)
  • The basics of Pulse-Width Modulation (PWM)

On the first day of the course, students cracked open their shiny new Raspberry Pi’s, added WiFi adaptors, SD cards, a custom interface circuit board, and serial cables; attached them to the lamp base, added power cords and an LED ribbon cable, and connected the devices to their computer with a serial (UART) USB cable.  While UARTs are “old school” (RS-232 anyone :-), they are still common on embedded devices, and are often your last ditch, never fail, connection option.

Screen Shot 2015-10-15 at 3.10.43 PM

Students connected their LAMPIs to the CWRU Campus Network, and learned how to remotely connect to a Linux shell on the Raspberry Pi with SSH, a basic tool for modern, distributed software development.  

The class was then tasked with installing the pigpio library, for interacting with the General Purpose Input/Output (GPIO) digital pins on the Raspberry Pi.  Three of the GPIO lines are connected to a custom interface board that has three high-power drivers to control a 3W Red Green Blue (RGB) LED.

Screen Shot 2015-10-15 at 3.13.21 PM

Turning a GPIO line on enables the driver circuit for that LED color channel, lighting up that LED color.  By using Pulse-Width Modulation (PWM) support within the pigpio library, the intensity of the LED can be varied from completely off to full brightness by changing the duty cycle of the PWM command.  By varying the intensity of three LEDs, the RGB color (or, equivalently, the Hue and Saturation) can be varied.

By the end of the first week, students were able to write a simple Python program to generate light by cycling through the primary colors (Red, Green, and Blue) and White.

FINAL THOUGHTSScreen Shot 2015-10-15 at 3.21.33 PM

Why a Raspberry Pi?  Honestly, it is overkill for a desk lamp.  We’re actually using a Raspberry Pi 2B, which is 900MHz Quad-core ARM Cortex-A7 processor with 1GB of RAM.  That’s a crazy amount of computing power for a desk lamp.  But, it does allow us a few simplifications for the course.  Typically, embedded devices, like a “smart” desk lamp, are develo   ped using the C programming language.  Teaching the students C would take a few weeks, plus the additional complexity of working in a cross-compiled environment (i.e., writing the software on their Intel based computer to run on an embedded ARM processor).  We decided to trade that time off to expose the students to other important topics in the Connected Device space and use a high-level language, Python.

Why Python?  Python is fast to learn, runs in lots of different environments (embedded, cloud, etc.), and has a huge community of open source development projects.  While interpreted, Python is relatively efficient, and has solid support for integrating with low-level libraries (i.e., those written in C) for hardware interaction.  An additional bonus is that later in the course, when we move to the “cloud” and web development, some of the Python experience can be transferrable.

Why a desk lamp?  It is unclear if the world really needs a web and smartphone controlled desk lamp.  What we need for the course is a device to motivate the exploration of the IoT / Connected Device ecosystem (embedded, UI/UX, Cloud, Bluetooth Low Energy, mobile, etc.), and even a simple desk lamp provides enough complexity to make that exploration interesting.  Light is also a primal and fundamental aspect of our lives. After all, it was our mastery of light and tools that arguably began man’s journey towards technological advancement. Therefore it is fitting that as we begin to explore this new evolution of product design that we bring our modern light and tools together again to help “light the way,” even if our guiding example takes the form of a humble desk lamp.

Stay tuned for more as the course progresses and we drill down into the many interesting and challenging concepts that make up the Internet of Things.

Coming soon: The creative design process behind the LAMPI’s unique shape.

LeanDog and CWRU Team Up For Connected Devices Workshop

Screen Shot 2015-10-15 at 3.07.21 PM

Over the next few years, it is predicted that billions of devices will become increasingly interconnected and posses the ability to transfer data across networks without the need for human interaction. This environment of interconnectivity is known as the Internet of Things (IoT). In response to the emergence of this approach to product design, an unusual partnership between academia and industry has formed to prepare students to thrive in this new environment.  Nick Barendt and the LeanDog Studio have teamed up to offer a Connected Devices Workshop for Case Western Reserve University (CWRU) students during the Fall semester.  Students will get practical experience building a proof of concept system:  physical device, web integration, and mobile development.

Nick is a partner at LeanDog and an adjunct faculty member in the Department of Electrical Engineering and Computer Science at CWRU.  He helps lead the Design and Delivery Studio at LeanDog, building custom software products for clients.

Students will tackle hands-on assignments, learning to use the Unix command line shell, network communication, including Bluetooth Low Energy, embedded systems, cloud/web services, essential User Experience design, and native mobile development.

The course is unique in the breadth of material being covered – the goal being to provide students with a systems-level view of Connected Devices, gaining experience with each component in a complicated system.  Students are expected to leave the class with the ability to build their own proof-of-concept for a new product or service.  Additionally, students will develop enough experience and confidence to dive deeper into any of the technologies involved (e.g., web services, mobile development, etc.)

Given the ambitious syllabus, students will work in two-person teams, a practice known in the engineering and software development world as “pairing.”

“As Agile and Lean practitioners, we believe strongly in the value of pairing. Pairing with another student gives them the ability to share that journey with someone else who may have more experience in a technology area than they do. This allows the student to learn faster. Two heads are better than one when you are trying to solve a complicated problem,” said Nick Barendt, head of the Studio at Leandog.  

The broad spectrum of technologies covered in the class will be matched by the backgrounds of the students in attendance, whose areas of study range from computer science, to electrical engineering, to computer engineering. By working together in rotating pairs, students will learn to successfully collaborate with peers of different backgrounds and experience levels. This practice echos the same cross-functional team environments they will likely encounter in their professional careers.

Though Nick is the instructor of record for the course, he is pulling heavily on the depth and breadth of experience of the LeanDog Software Delivery and Design Studio to help provide this opportunity to students.  The LeanDog Studio has exceptional expertise in Agile/Lean design and development across Web, Mobile, Cloud, DevOps, and comprehensive User Experience.  Each lecture and assignment is being designed collaboratively with this cross-functional team.

About LeanDog

LeanDog is an Agile consulting, training and software design company that is redefining smart design and delivery, while helping to transform our clients’ organizations.