Exploring IoT, Part 1: iBeacons, Philips Hue and Node, Twice!

All year long, Eduardo Pelegri-Llopart has roamed the globe exploring the future of technology, especially the Internet of Things (IoT). A former college professor, Eduardo loves learning and teaching, and this summer he was able to do both with Progress student interns. Here's his first report on what happened...

This summer our Redwood City office has been host to 3 interns, David Inglis (Caltech), Reeti Banthia (UTexas, Austin) and Keegan Mendonca (Caltech); the three had finished their Freshman year in Computer Science. It has been a great pleasure to host them, and we all learned a lot. Our focus of this summer has been on IOT, Node.js, leveraging Progress® Modulus®  and Progress® products. All the summer projects are now available at our GitHub organization under MIT license. The interns also documented their progress via blog posts.

Note that these projects do not necessarily represent best practices, but they show some of the possibilities that our software stack can enable.  The next few posts will provide a rough overview of these projects.

The first set of samples we explored used iBeacons and Philips Hues.  These samples were written by David Inglis.

iBeacons™

An iBeacon powered by a coin cell.

iBeacons are a proximity system created by Apple that uses Bluetooth Low Energy (BLE) to provide an indication of proximity to a physical beacon. Proximity is based on the intensity of the signal and it is delivered up to the applications as Immediate, Near, or Far.  Beacons are identified via a UUID that includes a UUID and a major and a minor id.  The rate at which iBeacons emit its signal varies, for example a Gimbal Series 10 beeps twice a second while a Series 20 beeps ten times a second.  The range of a beacon is usually around 50 meters.

A battery-powered iBeacon

iBeacons come in many form factors, including small devices that use coin cells (like CR2032), larger ones that use AA batteries, USB sticks, etc.  The underlying BLE standard has been supported in iOS devices for the last few years, starting with iPhone 4s, as well as in devices of other manufacturers. The iBeacon protocol is supported natively in iOS 7.1 and iOS 8 and in Android versions starting with 4.3.

iOS8 supports Homekit which is a framework intended for home automation.  It came fairly late in the summer and we could not play with it but it is very relevant to this space.

Philips Hue

The Philips Hue lighting system

A Philips Hue is a lighting system that includes LED light bulbs and a bridge. The bulbs connect to each other using Zigbee, a low-power radio protocol that supports a mesh topology.  The bridge provides connectivity, via an Ethernet port, to other IP-based systems, including the Internet. The range of each “hop” is around 50 feet but the mesh topology means a much larger area can be covered easily.

The bridge accepts HTTP requests and will convert those into Zigbee operations that will be sent to the light bulbs. Each bridge can control up to 50 bulbs.

An iBeacon Scanner

Sample code for iBeacon scanner app

The first sample that David wrote was a very simple iBeacon scanner for an iOS device. For simplicity, the sample was written in Objective C using the Foundation Classes directly. The sample was tested against iOS 7.1.  We considered but rejected using iOS 8 and Swift as both were still in beta and David was learning all these technologies while writing the samples.

The sample code is at http://github.com/ios-beacon-scanner. David’s writeup is My First Beacon App.

The scanner sample is conceptually pretty straight-forward, but it was the foundation for the next apps built.  

Basic Roll Call

The power of iBeacons comes from combining the identity of the beacon – which can be mapped into a location or something else – with the identity of the receiving device.  The next sample that David wrote is a basic roll call: each mobile phone identifies its owner, and that, and the iBeacon information is used to track who enters and leaves a given space.  The information from the beacon is sent through the internet (cellular or WiFi) to a Node.js endpoint who stores the information into a MongoDB database. These services are running on Progress Modulus.

Modulus also provides a simple HTML interface to the roll call, using the Express framework.

The basic architecture is shown in the image below.

Modulus HTML interface to mobile roll call using Express framework.

The sample code is at http://github.com/ and David’s writeup is The Roll Call App: Integration Beacons with Node.js and MongoDB.  David also documented Provisioning an iOS App for Ad-Hoc Testing.

Roll Call with Lights

Progress Project: Mobile Roll Call with Lights

Having tackled this, our next experiment was to use the Philips Hue to visually display the roll call. Since the Philips Hue systems are controlled using HTTP requests, and Node.js is such a great match for that - and just because it was fun - we used Node to control the lights.  The bridge only has a wired Ethernet port so we had to add a WiFi base station (an Apple Airport Express) and a small router (Netgear).  The image to the right shows you our set up.

So you ask, what’s that black box between the Airport Express and the router?

A BeagleBoneBlack, shown next to a pencil to present a scaled view.

That’s a BeagleBone Black, which is running the Node.js local stack. A BeagleBone Black is a small system-in-a-card computer that runs Linux (Amstrong) and supports Node.js out of the box. It’s fairly powerful (1 GHz ARM® Cortex A8) and includes (micro) HDMI, USB, and Ethernet ports.

Controlling the Philips Hue was pretty easy. What was a bit trickier was getting the commands to it from the Modulus layer. Since the bridge is in our office, behind our firewall, it does not have a public IP address, so it cannot be addressed directly from Modulus.

The solution David designed was to ping periodically between the local (behind the firewall) node to the remote (on Modulus) node, to find out if there was a need to adjust the lights.

An alternative would have been to keep an open connection of some sort but this didn’t seem necessary (and I’m not sure if our firewall would have allowed).

Here is the architecture diagram:

David Inglis' solution to access Modulus layer outside the firewall.

Mobile Roll Call with Lights

This sample is built on the previous one, so the code is at the same location under a different write-up: Roll Call v2: Adding Philips Hue Lights.  David also documented the BBB part: Running a Startup Script on a BeagleBone Black.  And I've included an animated GIF of the project in action.

Having Fun: Controlling your Hue from outside the local network

Just for fun, David then used the infrastructure he had created to write an iOS app that would use the node-to-node bridge to control a Philips Hue while being outside its local network.

An iOS app built to control the Mobile Roll Call with Philips Hue system

As before Modulus is used to host the server-side Node.js code. This code is also at http://github.com/ but there is a new write-up: Full Hue Control Outside of the Local Network.

What’s Next

In my next posts, I’ll cover other samples that will show how to use Node.js on Modulus to interact with Progress® OpenEdge®, Progress® Corticon® and Progress® Rollbase®,  and we will wrap up with another IoT sample that ties everything together.

Until then, follow my blog and Twitter pages for more updates.