The Internet of Meeting Rooms, or “Is this room free or what”?
Most people have heard the term “Internet of Things” now, but for those who haven’t it’s basically the concept that any device (or thing) can be connected to the internet, from the lights in your home to your car. Amazon’s first foray into physical IoT devices was released towards the end of 2016. Called the Dash button, they are WiFi enabled buttons that will instantly order a specified brand name product from Amazon.co.uk. The Dash button has a programmable sister, the IoT button (which lets you define what happens when it’s pressed) that has been out in the US for sometime now, but it has only recently been made available in the UK.
As we know the best way to learn about tech is to try to build something with it, so we ordered a couple and started thinking about the possibilities.
As a team we got together to brainstorm a few ideas for how we could use these buttons. They support 3 types of clicks (Single, Double and Long) and are easy to set up to trigger AWS Lambda functions to execute any logic of your choice. One big limitation is that you only get about 1000 clicks out of them before the battery dies. We wanted to concentrate on a proof of concept style use case without worrying too much about the number of clicks we would need. As an aside it is worth noting that the v2 version of the IoT button now gives around 2000 clicks and there are many other IoT style devices that provide a longer lifespan, so for the purpose of our experiment we didn’t want to worry too much about the number of clicks.
After discarding a few ideas such as a Daley Thompson’s Decathlon style game (clearly this would need more than 1000 clicks and the buttons would probably not be responsive enough), we settled on trying to improve our Meeting Room availability. Here at The Telegraph we have several meeting rooms but it is often difficult to find one that is free, and when you find an empty room that appears to be booked in the Google Calendar, you can never really be sure that you won’t be interrupted by the person who booked it.
We decided we needed a way to let people indicate that a room was in use and also to keep people up to date if meetings finished early. Additionally we would start to be a bit stricter about people starting their meetings on time, people would have 5 minutes to indicate the meeting had started, after that the room would be made available to others.
The plan was to put one button in each room; a single click would be used to indicate the meeting was started and a double click would indicate the meeting had finished early. Notification of rooms becoming free would be sent to a Slack channel and Meeting creators would be emailed when their meeting was ended.
The key components of Google Calendar, Gmail, AWS and Slack are already in use across the company so hooking into them made a lot of sense.
And so we set to work.
Single Click
We started with the Lambda function to handle the single click event from the button. The first task was to get access to the Google Calendar API from a node.js app that we could deploy as the Lambda. A bit of configuration was required to set up a Service Account in Google (you’ll need to have admin rights on the Google account) and then grant it access to be able to see and edit the Meeting Room Calendars already in existence. We used the node-google-calendar module which when passed the OAuth2 credentials gave us the access to Google’s Calendar API.
In the Calendar API there is no call to get the currently running event from a calendar. So, given that meetings could run all day, we needed to get all the events in the calendar for the whole day and loop through them to find the one that had a start time before, and an end time after, the current time. We will need to use this same logic in the other 2 Lambdas.
The next step was to be able to mark this meeting in some way so that we would know that the meeting had been started. Originally we thought about storing a record in a lightweight nosql database but we discovered that Google Calendar events support custom properties in their “extendedProperties” object, so we added a property clicked=true here. For good measure we also decided to change the colour of the event in the Calendar to give a visual cue that the single click had worked.
Double Click
This Lambda needed to find the current meeting (using the same logic defined above), end the meeting in the Google Calendar, send a message to a Meeting Room Slack channel saying “Room X is free until Y” (where Y is the time of the next meeting — or “End of the Day”) and finally email the creator of the meeting to say the event was ended manually.
To end the current meeting in the corresponding calendar we used the same update calendar event method in Google’s API we that used for the single click Lambda, but this time we set the end time to the current time of execution.
Sending the message to Slack involved creating a new Slack Channel and registering a new Webhook endpoint for it, you will have to have admin rights on your Slack account to do this. Once you have the Webhook URL you simply post a basic JSON file to the endpoint and your message is sent to the Channel.
Emailing the person who created the meeting event required a bit more set up. We decided to use AWS SES and a node module called nodemailer to do this.
In the SES Console we needed to verify the email address we wanted to send from and the domain we wanted to send to. This done, it was simply a matter of downloading the SMTP credentials to plugin into the nodemailer config. Once all configured it just became a matter of forming the message to send and retrieving the email address of the event creator from the calendar.
Scheduled process
Now we needed to implement the process that would periodically check all the calendars and end any meetings that were more than 5 minutes in, but only if they hadn’t received a single click to set the clicked=true property.
It was reasonably simple to write the logic for this: retrieving the current event as previously described, checking for the clicked=true property and whether 5 minutes had passed from the beginning of the meeting then ending the meeting in the same way as for the double click.
The same process was used for sending a message to Slack and the email to the creator, this time with a slightly changed message to say the meeting was ended due to non-attendance.
Now we had the Lamdba function we just needed to schedule it to run. AWS provides an easy way to config a Lambda to be triggered on a schedule using CloudWatch Events. This gives the ability to define a cron pattern or a more basic rate pattern for the frequency to fire the Lambda, in our case we used the simple: rate(5 minutes).
IoT Setup
So, Lambdas all written, all that was left was to setup the buttons and configure some rules. Amazon provides a handy mobile app to help set up the buttons in your AWS account, be aware though that the buttons can only work on a single WiFi Network at any one time without needing to be reconfigured. With the buttons registered in our account all that remained was to link them to the Lambda functions for single and double clicks so they would fire. Here we used the IoT Rules definitions to intercept any clicks from buttons in our account and send them to either the single click or double click Lambdas depending on their clickType property.
Up until now we had been testing the Lambdas using the Test event config that AWS provides, but now we had arrived at the moment of truth, actually clicking the button and watching the Calendar update. This is where we learnt a valuable lesson. The button is only as good as your WiFi. When clicking the button the little LED on it will flash white until it either succeeds and goes green or fails and goes red. Unfortunately if the WiFi is not quite strong enough you may start to see red, in more ways than one. This was the case for while for us but after moving around the room a bit it worked!
General lessons learnt
- Although it is possible to create a single Lambda to handle all the clickTypes of an IoT button it’s probably not a good idea. A Lambda function should have a single responsibility, this helps with debugging and maintenance.
- Default timeout for Lambda is 3 seconds, you are charged by execution time so it’s worth making them small and fast
- Debugging can be a fairly cumbersome process as code has to be zipped and uploaded to AWS — there are some frameworks to emulate Lambda to make this a bit easier (Emulambda for Python for instance)
- For most APIs there are Node Modules out there that take away a lot of the integration pain.
- Make sure you have strong WiFi where you want to place your button!
