Sending 1.24 million MQTT messages from NodeConf EU to Azure (and lots more digital badge details)

The NodeConf EU 2018 digital badge was a stunning success that far exceeded every expectation we had and eclipsed our beloved 2017 badge .

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.

[caption id="attachment_300002415" align="aligncenter" width="640"]

Raspberry Pis ready to be set up around the conference[/caption]

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.

[caption id="attachment_300002424" align="aligncenter" width="640"]

NodeConf EU 2018. Kilkenny, Ireland.[/caption]

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.

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.

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.

https://twitter.com/amel_true/status/1059442275078545408

Monday's workshop showed everyone how to connect to their badge over Bluetooth using the Chrome-based Web IDE. Soon everyone was running their own JavaScript directly on the badge and having fun with the REPL and on-badge hardware.

https://twitter.com/nicokaiser/status/1059517796621664256

https://twitter.com/RBFrontEnd/status/1059476745525620738

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.

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.

I am convinced that we are at an inflection point in IOT. Many use cases will move to a multitude of small cheap low-power redundant devices, communicating via other cheap less-low-power redundant devices to an "infinitely" scalable pay-as-you-go back-end. The value will be in the actionable insights that are possible via AI/ML+IOT in that cloud. And much of the implementation end-to-end, outside of hard-real-time, will be in JavaScript.

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 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:

[video width="2880" height="1808" m4v="https://www.nearform.com/wp-content/uploads/2018/12/timelapse_badgeclaps_02.m4v"][/video]

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!

[video width="2880" height="1808" m4v="https://www.nearform.com/wp-content/uploads/2018/12/timelapse_temperature_03.m4v"][/video]

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.

https://www.youtube.com/watch?v=jSirIWSbF7g&feature=youtu.be

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.

Emma got it just the way she wanted:

https://twitter.com/triagegirl/status/1059462269506125825

Chris jumped the shark. It is a shark, isn't it :-)

https://twitter.com/chriswilcox47/status/1059752320223854592

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:

https://twitter.com/nodebotanist/status/1071815784043872259

Watch Live from the lab -- Espruino Badge! from Nodebotanist on www.twitch.tv

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.

https://www.youtube.com/watch?v=txZr2GhuoaI&feature=youtu.be

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:

https://twitter.com/maya_papayaa__/status/1059500169094483969

https://twitter.com/jellekralt/status/1059153021580525569

https://twitter.com/simona_cotin/status/1059159840126320641

https://twitter.com/sienaluke/status/1059175076514447360

https://twitter.com/tretton37/status/1059368802025119744

https://twitter.com/justshiv_/status/1059375681178611712

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:

https://www.youtube.com/watch?v=UMgMSb7d-Os