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.