mbed Smart Lighting Demo with code examples

I recently attended The Cable Show 2014 in Los Angeles where I presented a demo that integrated several "smart light" devices with an interactive television application.  In this post I'll give an overview of the demo system, as well as code examples to show how it works.

You can see the demo in action at the 7:00 minute mark (configuration #2, see note below in System Components)

The Goal

I work in Cable Television, so I set out to create a demo system that would automate lighting controls based upon STB (set top box) remote control interactions.  The demo system was based around a VOD (video on demand) movie, and I wanted the following functionality:

• Starting the movie should cause the lights to go dim for 5 seconds and then turn off completely
• Pausing the movie should cause the lights to come back on dim
• Resuming the movie (from pause) should cause the lights to turn off
• Stopping the movie should cause the lights to turn on at full brightness

There are certainly additional features that could be useful and cool, but as a proof-of-concept the above functionality would suffice.

System Components

The demo system consisted of the following pieces:

• EBIF (Enhanced Television Binary Interchange Format) application running on the STB that would control the VOD session, and notify a server of the remote control actions
• Java server process that would listen for messages from the EBIF app, and then forward the appropriate commands to the various smart lights
• Smart Light devices (LED(s) on the ARM mbed board for example) that would respond appropriately to the commands from the Java server

One additional note is that the demo had two basic configurations for the mbed board:

1. RGB LED control via direct RPC
2. LED / pin control via the ARM Sensinode/NanoService cloud platform

For the second configuration, I used a Sensinode server and mbed binary provided by ARM.  Since I can't provide as much information and code on that configuration, I'll focus on the first mode of operation (RPC control of the RGB LED).

Workflow

When the user pressed the remote control button to start the VOD movie, the EBIF application would intercept the remote key, start the movie, send a "dim" notification to the Java server, and start a 5 second timer.  The Java server would receive the EBIF message and make the appropriate RPC call (via HTTP) to the mbed NXP LPC1768 board to dim the LED.  When the 5 second timer expired in the EBIF application, the EBIF app would send an "off" notification to the Java server which would then send the RPC call to turn the LED off.  (I could have integrated both of these EBIF messages into a single "play" command and had the server manage the timer, but that was just an implementation decision).  When the user pressed the pause button on the remote, the EBIF application would send another "dim" notification to the Java server.  When the user pressed the stop button, the EBIF app would send an "bright" message.

Code

The source code for this demo is published on the mbed site.

Some additional notes:

• HTTPServer - I had initially planned to use an HTTP server running on the mbed board.  I experimented with several HTTPServer components, and found Henry Leinen's fork to work the best.  However, I noticed some instabilities where after I made a few HTTP requests, my mbed application would lock up and I had to reset the board.  I played with the HTTPServer code for a while and realized that if I forced the TCPSocketServer into blocking mode and removed the polling mechanism, the server would stay up reliably.  My fork of the HTTPServer forces blocking mode (resulting in improved reliability), but requires that the HTTPServer be started from a separate thread (not the main app thread).  You can see how I did that in the SmartLight main.cpp.   I ended up not using the HTTP server for anything, but I thought it was cool so I left it intact.
• EthernetInterface - I ended up using Jonathon Fletcher's fork.  I'm not quite sure what the issue is, but the HTTPServer and RPC communication is really slow when I use the official mbed library. Jonathon's fork seems to be a lot faster.
• The first smart light device that I coded (not an ARM mbed) did not accept RGB color values, so my server was already passing around HSV colors.  It was fairly easy to convert HSV to RGB (using a formula from Wikipedia)
• My demo took place in a tradeshow booth and I wanted to avoid people's hands all over my mbed board. I found a raspberry pi enclosure that fit the mbed board almost perfectly (with about 15 minutes of Dremel work).  I was curious if the mbed board would get too hot after running for 6+ hours in an enclosure, so I added the temperature reporting to the LCD screen.  Spoiler: The board runs a few degrees warmer in the enclosure, but nothing to be concerned about (it seems to stay around 93 or 94 degrees F).  After adding the temperature polling, I ran into some synchronization issues with printing to the LCD screen (I was also printing the DHCP IP address to the LCD screen, but that was happening asynchronously on another thread due to the HTTPServer issue above).  I decided to put the temperature polling/writing on it's own thread, and fixed the synchronization issue by adding Richard Thompson's MutexLocker library.

Running

After importing my application into the web compiler, building the binary, and dropping it onto an mbed board, make sure that you have the ethernet port connect and hit the reset button.  As soon as the program starts, the temperature should begin printing to the LCD screen, and the RGB LED will be initialized to a green color.  After a few seconds, the DHCP IP address should show up on the LCD screen above the temperature.  If the ethernet port is not connected, you should see a message to that effect below the temperature (but this takes a few more seconds since it's waiting for a timeout).  If you don't have a DHCP server, you can set a static IP address by uncommenting the "#define STATIC_IP" line towards the top of the main.cpp, and adjusting the "STATIC_IP_ADDRESS", "STATIC_IP_NETMASK", and "STATIC_IP_GATEWAY" #defines.

Assuming that the RGB LED came on and the board got an IP address, you can test the functionality from a web browser by using the URL format:

http://<IP_ADDRESS>/RPC/setLightColor/run <H> <S> <V> <brightness> <powerOn>

where:

0 <= H <= 360

0 <= S <= 1

0 <= V <= 1

0 <= brightness < 100

powerOn == 1 ? on : off

(You can also use a brightness value of 0 for off)

Examples:

http://<IP_ADDRESS>/RPC/setLight/run 0 1 1 100 1

Results in color = red, brightness = 100%, power = on

http://<IP_ADDRESS>/RPC/setLight/run 120 1 1 30 1

Results in color = green, brightness = 30%, power = on

http://<IP_ADDRESS>/RPC/setLight/run 120 1 1 30 0

Results in power = off

Unless you're an artist, you'll probably have some difficulty setting the color (H, S, V) correctly (I certainly have trouble with it).  I typically only mess with the "H" value, and leave "S" and "V" at 1.  (Please don't blast me for being ignorant; I openly admit that RGB is the only color scheme that I understand)

TODO

One of these days, I'll get around to writing a really good RGB LED library. It took a while to get my code to properly set the color, brightness, and power on/off.