In this post, I’ll walk you through the several days of the event, explain at a high level how the badge platform worked and also show you the lovely ways in which the attendees interacted with it. In several follow-up posts, coming very shortly, we’ll deep dive into the architecture and the detail of our use of services like Azure IOT Hub and Databricks.
Sunday was setup day for us and registration day for most of the attendees. This meant we had 20 Raspberry Pis which needed final configuration and deployment around the conference centre and hotel.
Raspberry Pis ready to be set up around the conference
Final assembly and flashing of the production firmware to 300 badges brought us right to start of registration. We were both thrilled and a little shocked when all 300 badges started flashing and buzzing simultaneously due to a test alert from the App team. That one message confirmed that everything was working really well!
The reaction from the attendees as they received their badges made all of the work of the past few months worthwhile. Initial hesitancy turned to wide grins as we explained what the badges were and how they could use them.
NodeConf EU 2018. Kilkenny, Ireland.
Everyone adored how beautiful the badge looked with its laser-etched surround. In fact they are so lovely, many of us in NearForm are now using our badges as a desktop clock.
Testing had gone so well in the run-up to the event that we didn’t need too many code changes throughout the event. Monday morning saw some Raspberry Pi and Azure updates but one of our big takeaways was how incredibly reliable everything was for low-cost hardware and lightweight software. This is not your traditional big iron IOT setup.
We had a heatmap web-app displayed on a large TV, powered by another Raspberry Pi, showing how busy each area was in realtime. This was implemented by each badge broadcasting a simple alive signal for a few seconds every minute (to preserve battery life). Those broadcasts were picked up by one or more Pis running our Node.js code with the Noble library. The code received an RSSI value which is basically the power of the signal from each badge. This can function as a crude distance measure from badge to Pi. The Pis sent the data over MQTT to IOT Hub and onwards to CosmosDB for persistence. Note that the Bluetooth Mac addresses were hashed in all messages sent to Azure to add an extra layer of obfuscation.
An important benefit of the heatmap for us was the realisation that the badge counts in specific rooms seemed very low on Monday. We came to the conclusion that some of the Pis were simply too low-down and were being blocked from scanning the badges properly by all the people and chairs in the bigger rooms. On Monday night I moved all of them at least 2 metres off the ground and the counts for Tuesday/Wednesday were much better.
Clap-o-meter and Temperature
Along with the heatmap, we had the realtime clap-o-meter for each room. This was just a bit of fun and was not intended to be taken seriously or seen as incredibly accurate. This worked by using the on-badge accelerometer to detect large changes and the badges then broadcast an estimated clap number. The Pis collected these broadcasts and sent them over MQTT to IOT Hub and onwards to CosmosDB for persistence. .
The badges also sent their current detected temperature in the same JSON as the claps. We didn’t use this data during the event but persisted it for post-processing later (see below).
One of the follow-up posts will explain what happened to all the data once it got to IOT Hub.
Alerts and Schedule Info
All the alert and schedule information came from the NodeConf PWA back-end. An Azure functional app monitored the back-end via its API and sent any alerts or Now/Next schedule info via IOT Hub to the Raspberry Pis. The Node.js code running there then used the Bleno library to broadcast to the badges for several minutes in order to ensure reception. When each badge woke up, it would scan for these broadcasts and update the badge accordingly. Obviously it ignored repeated messages from the same or multiple Pis. A critical point is that the Pis were all completely independent and unaware of each other. This made implementation easier and the overall system more robust to failures. We operated a whitelist of Pi Bluetooth Mac addresses on the badge firmware to avoid any naughty person sending their own “alerts” to the badges.
One nice side-benefit of using the Azure IOT SDKs was that we could tell the status of all registered devices (Pis). So we built a simple Control Panel for our own use during the event. This showed the connectivity status of all the Pis along with the Alert/Info/Now/Next that each Pi was currently broadcasting (if any) by analysing the telemetry data from IOT Hub. We also added the ability to send our own notifications to the badges, separate from the App ones, to facilitate easier testing.
1.24 Million Messages!
The Node.js IOT SDKs of all the major cloud vendors, including Azure, are built on MQTT.js, from the ever-brilliant Matteo Collina of NearForm. So it gave me an enormous thrill to see how much we’d used it over the 3.5 days.
Just think about that for a second. Approx 300 inexpensive Bluetooth LE devices communicated with 20 x $35 Raspberry Pis during conference hours only, causing 1.24 million MQTT messages to be sent to Azure IOT Hub, over conference wifi(!), with no part of the system ever breaking a sweat.
Getting value from the data with Azure Databricks
Once we had all of this anonymized data in CosmosDB, we wanted to do something useful with it. As a first step, one of the team spun up an instance of Azure Databricks. This blew our minds. Single click deployment of an entire Apache Spark instance that auto-shuts-down after an idle period. The time-saving value of services like this can’t be underestimated.
A simple Scala query in Databricks data-crunched for several minutes and output some CSVs. Those files were then consumed by a simple web-app based on PivotTable.js which enabled us to visualise temperature, clap and badge data along various dimensions. I was speechless when I saw how much we could infer from Pivot table output. Even simple facts were surprising. The peak of people/badges on Monday was 9am but was more like 10.30am on the following days. The average temperature in rooms changed a lot throughout the day. The clap-o-meter was too sensitive to movement :-)
Whilst these are fun experiments, there are real practical insights for conference venues and conference organisers in this data. Imagine correlating across multiple events in one venue and feeding that data to those who design event venues. Most importantly for me – what’s the optimal time/location/amount of coffee stations for any given event.
It’s timelapse time
It turned out to be quite easy to take all of the data stored in CosmosDB and generate some very interesting timelapses. The first is effectively a replay of what people saw live in realtime at the event showing badge counts in rooms and claps:
And the second timelapse made use of that previously not shown temperature data from the badges. Note that the sensor is on the back of the badge and hence would have been strongly affected by the temperature of the attendee themselves. But it’s still lovely to watch!
Azure ML Studio
We didn’t have time to start anything on ML before the event but we’ve just kicked off a project with Azure ML Studio focused on the event data. We’ll do a follow-up post on this soon but suffice to say that new users found the getting-started process on ML Studio incredibly easy. Doing basic linear regressions on the raw temperature data in CosmosDB was entirely a point and click exercise.
If you are in the Pacific Northwest on Monday 17th of December, Luca Maraschi is giving a talk in the Microsoft offices in Vancouver around CosmosDB, Azure ML and Node.js.
I gave a full run-down of the badge platform at the Node.js Meetup Dublin recently. People continue to be excited by the badge and the possibilities of using the platform at other events.
Hacking on the badges
The badge is fundamentally an expanded Pixl.js and runs exactly the same firmware as it. The software you run on top of that can be anything you like. I already mentioned the Desktop Clock above.
And just the other day, Kas Perch, who was a huge help to us at NodeConf EU (thanks Kas!!), has started building their own badge software, based on the NodeConf EU one, but with just the features they need. Check out the Twitch video they did of the process:
Today on stream: let's start turning my @NodeConfEU badge, powered by @espruino, into my every-conference badge! I'll be taking apart the firmware and building it back up piece by piece. 1pm CST! https://t.co/3qim61awDZ
We made sure you could easily add Wifi to the badge with an ESP-01 but didn’t include it by default due to battery usage. Gordon has put together a video showing exactly how to do it. It’s very easy and I’ve modded two already.
Change the name on your badge or turn it into a clock
If you’d like to change the name displayed on your badge, just use this simple Name Changer Web Bluetooth App.
We’ll soon have a simple Web Bluetooth app to convert your badge into a desk clock too. In the meantime, more technical users can do it using the Web IDE. See the comments at the top of that link for flashing the code.
We’ve really been overwhelmed by the positive response to the badge by the attendees. Here’s just a sample:
And lots of pictures of the badges from Nico Kaiser here.
The Espruino code for the badge and the hardware design files have already been open sourced. We’ll be announcing the open sourcing of the rest of the platform including both the Raspberry Pi and Azure code very soon.
If you wish to engage commercially regarding the badge platform itself or any aspects of Azure, please get in touch with NearForm.
Gordon Williams can handle any of your hardware queries about custom badges or Espruino.
Here’s a lovely summary video of the event with lots of appearances by the badge: