How to win an Internet of Things hackday if you don't know your Arduino from your Beaglebone
I was recently Lyst’s delegate to the Amazon Web Services re:Invent conference in Las Vegas. It’s their annual show where they announce big new features and EC2 instance types, and also a great opportunity to learn how to make best use of new and existing services. This year was no exception, with the launch of AWS Elastic Container Service, bringing an EC2-like API to the running of Docker containers (see Alex’s recent blog post on Docker), and also AWS Lambda, truly a potential game changer where Amazon will run short lived instances of your own functions to process discrete items of data from an event stream.
Kicking off the conference are a number of hackdays, one of which was the Internet of Things hackday, sponsored by Intel and Spark. Despite having a slight Electronics background, I’ve never really got into Arduinos, Raspberry Pis and the like, and haven’t touched a breadboard for 12 years. Knowing that we at Lyst are very interested in the possibilities of iBeacons in bricks-and-mortor fashion retail, I signed up and crossed my fingers that inspiration of what to build would strike on the day.
As with all things at the conference, the day was very well run, despite it being the first iteration of this particular hackday. On arrival I was presented with a brand new Intel Edison development board and useful number of sensors, buttons, lights and displays. The Edison platform is truly excellent, it’s a full dual-core Intel Atom amd64 System-on-a-Chip with 1GB of RAM. It’s around the same size as an SD Card and can either be plugged into the board I received for development purposes, or embedded directly in a final production project. It runs Yocto Linux by default and so provides a very familiar environment to get started with.
I joined a team with one of my former colleagues who now works at Forward3D, and two guys working in Hong Kong for Nixplay, who make digital photo frames. None of us had any hardware or “Internet of Things” experience, but we were all keen to try this new platform out and see what it was capable of. Two members of the team were given a new Spark Core and as-yet-unreleased Internet Button in place of our Edisons.
To get us started, we were invited to make “digital maracas”, essentially we had to connect an accelerometer to our devices and record the number of shakes of the sensor for each team. Since this was an AWS Hackday, our data was published to Amazon DynamoDB through AWS Kinesis. Unfortunately the Python build provided on the Edison was broken and missing the Decimal module, so boto wouldn’t work. I had to dust off the old Node.js skills instead and use that. There’s some good libraries provided for interfacing with the GPIO pins on the development board, plus the awssdk Node.js module is very well maintained by Amazon.
Once we’d accomplished this, it was pretty clear to me what the competition portion of the day would entail: sensors publishing data to the cloud. We tried to come up with ideas that would fit this, but in the end decided to try and stand out from the crowd a bit. Whilst everyone else was pushing data to the cloud from moisture, temperature and sound level sensors, we worked on bringing cloud operations to the physical world.
We came up with “Don’t Panic!”, a more annoying (if that’s possible) version of PagerDuty. The idea was to listen for Alerts generated by AWS CloudWatch, and get the boards to make noise and perform obnoxious lighting displays. We decided to pair an Edison with a Spark core for each member of a fictitious operations team, Alice and Bob. The Edison was hooked up to a piezoelectric buzzer and a 16x2 matrix LCD display. We also made use of the Spark’s button for acknowledgement of alerts and the ring of RGB LEDs for display purposes.
I set up an AWS SNS topic for notifications in the team’s account and pointed a Cloudwatch Metric Alarm for CPU usage at it. One of my teammates began writing a small daemon in Node.js to coordinate the communication between devices running on our provided EC2 instance, which also received HTTP POSTs from the SNS topic. This daemon would post alerts to the Edisons via a couple of SQS queues, one for each device. When an alert was received, the buzzer would be made to sound and the alert text was displayed on the LCD display.
Communication with the Spark Cores was via Spark’s own cloud API. The speed at which this works is incredible - simply POST an event to a Spark API endpoint containing the Device Id, and the device picks it up and sends it to your code in around 200ms. The great benefit to this is that all you need do is ensure your device is configured properly for WiFi and you then don’t need to worry whether any services on the device stay running - it’s all managed. Our event handler for the Sparks invoked a flashing rainbow sequence on the ring of RGB LEDs. Garish, but very effective.
Once alerts had been triggered, we needed a way of silencing them (something easier to use than yanking the buzzer cable as we had been doing during testing). The Spark Cores’ buttons were set up to post back to the HTTP daemon with the name of the agent whose button had been pressed. This sent messages to all devices to silence the alarm, and also update the displays to say who had acknowledged the alert.
We were pretty impressed with the overall effect so far. For testing we’d simply change the threshold on the CloudWatch Alert in order to trigger the notification. Within about a second of the notification being received by our daemon we were annoying the rest of the room with loud buzzing and a light display. Holding one of the buttons for a second silenced everything and updated the displays. But we somehow had about an hour to spare before the deadline.
It was relatively trivial to add a user-initiated alarm system, so we did. Here the idea was that someone who had acknowledged the call in the middle of the night but was dealing with severe operational issues could hit the button on their Spark to call in other Engineers. This was easily implemented by changing the daemon to send an alert to the other device of the pair if the Acknowledge button was pressed without a current Alarm state.
The scenario we ended up with was obviously quite contrived, but it seemed to appeal to the judges, who were representing Amazon and NASA JPL. We accidentally stumbled upon an idea they saw as having commercial potential as opposed to something like pushing the moisture levels of a plant pot to CloudWatch. This point plus the fact we used all 4 devices, and a decent storied scenario behind our demo won us the first prize.
The Internet of Things is real. Big names like Intel are getting into it and producing amazing devices like the Edison, and even smaller simpler devices like the Spark will provide access to more discrete form factors. The device technology is there, as is the cloud to offload compute tasks and storage to. The next hurdle is reliable connectivity. There is yet to appear a truly reliable WiFi or Cellular network, even for wall mounted or otherwise stationary devices. Companies can’t get it right even when its their primary means of taking payments.
But for the most part, all the signs are there for embedded devices to be the next digital frontier, post-Mobile. It’s never been easier to prototype a hardware device, especially with the increasing availability of 3D Printing. Hackspaces are popping up everywhere, with cheap access to all sorts of special tooling. The easy availability of these devices and simple electronics kits will create a new generation of inventor who is able to assemble these building blocks in a new and innovative way, in much the same way as mashups on the social web. Production will obviously be less easily scaled due to the nature of physical products, but hurdles in the way of innovation in small devices are being cleared very quickly indeed.