This year at Red Hat Summit, I was part of a team whose objective was to create a running, IoT-focused system, at some scale (hundreds of beacons, millions of events), based on a real-world use case to demo live, on stage during the middleware keynote at Red Hat Summit.
Our team chose the area of asset tracking, where important machines, tools or equipment (think mobile ultra-sound machines in hospitals) need to be located on demand and tracked for their usage each day, week, month, year. But, for our demo, instead of machines, we asked Red Hat Summit attendees to participate as our “assets” by wearing Bluetooth Low Energy (BLE) beacons to track their movement throughout the conference.
In 2014, we saw a number of independent companies produce Bluetooth low energy (BLE) beacons. Members of our Red Hat team as well as external contributors evaluated a number of these beacons and found the Gimbal met our size, weight and cost requirements. That took care of the "tag" or "token" that was attached to our attendees badge, then we had to determine how to "read" it.
We built our sensor network out via Raspberry Pis, where a process on this awesome miniature Linux box was constantly scanning for Bluetooth signals, looking specifically for just our beacons' UUID, Major and Minor, calculating the RSSI (approximation of distance), performing some averaging over the readings and then pushing the message up into JBoss Fuse A-MQ (our message broker) via AMQP.
The overall "flow" of data was:
BLE beacon -> Raspberry Pi scanner -> JBoss Fuse A-MQ message broker -> Apache Spark -> A-MQ -> Node.js -> real-time Dashboard
My original prototype back in the Fall of 2014, was in Python, leveraging the BlueZ library when Scott Stark took the lead on the Raspberry Pi codebase, our "scanner" which essentially served as our gateway. Our Raspberry Pis included both WiFi and Bluetooth 4.0 USB dongles that allowed them to consume BLE data in and then produce AMQP messages out. Scott's first attempt was to use Java, but without a JIT on the Raspberry Pi, Java was slow enough to be a concern. Scott then moved to a C++ codebase that was solid for the 50 million plus events processed while in testing, and the over 7 million events processed "in production" leading up to the keynote demo itself.
In addition, one of our requirements was to build out our solution to gather, analyze and display the Bluetooth event data in as close to "real-time" as possible on a dashboard map of the convention center. (We actually tested the system by walking around the Hynes Convention Center while carrying a laptop with the map dashboard!) Our dashboard code included a replay feature that walks back in time to see what occurred throughout the last N hours.
I made this video somewhat late on June 23rd but you can see that our assets/beacons arrived for breakfast in the morning (3rd floor was the breakfast room), then hit various breakout rooms and around 4pm (16:00), most folks moved to the keynote room where our session was about to begin. After that, most folks returned for the Jim Whitehurst keynote and then eventually left the building late that night.
You can catch a replay of the live demo on stage during the middleware keynote at Red Hat Summit here, starting around 40:18.
The codebase for the Raspberry Pi-based C++ scanner can be found here:
https://github.com/starksm64/NativeRaspberryPiBeaconParser
Apache Spark Python can be found here:
https://github.com/mattf/taiol/blob/master/docker-demo2015/stage0.py
And, the dashboard projects here:
https://github.com/bleathem/keynote2015-beacon
https://github.com/bleathem/keynote2015-hexboard
I hope this demo gets you thinking about ways to use Red Hat technology for your Internet of Things. I know I’m already thinking about ways to top this demo for Summit 2016!
Last updated: February 7, 2024