Inspired by a recent visit to an Internet of Things conference in Madrid, we decided to give the technology a try and create a small demo to share with our customers and partners. After a short brainstorming session we came up with a simple idea that has been a recurrent theme whilst doing on-site visits: meeting room bookings.

Walking by: the scenario

The scenario is the following: you are talking to a colleague and the conversation gets a little longer than expected so you decide to move to a conference room. Walking past by the rooms, you see an empty one, get in, hook your laptop to the projector and resume the conversation only to be interrupted 5 minutes later by a team that tells you they have booked the room for the following 3 hours. Sounds familiar?

So our thoughts to improve the scenario: walk with a phone in your hand and an app tells you which is the closest room and its availability. Furthermore, it tells you if it can be booked, for how long and if there are any rooms nearby that might be free.

From this, we identified the following components: 

1. Low-emission bluetooth beacons to allow us to identify when we are near a meeting room
2. A mobile application to would display info and allow booking
3. A back-end API to retrieve a meeting room status (with beacon – room association)

A step further

Since we wanted the scenario to be a bit more realistic we added a maintenance use-case: monitor the beacons emissions to detect when one of them goes offline. In this way we can we send an operator to fix the problem, most likely change the battery or replace the device altogether. For this, we need to be able to register a new beacon (and associate it with a meeting room). We could even have scheduled maintenance visits (we know the battery will last approximately X years). Consequently, we added the following items to our list:

1. A Raspberry PI device with Bluetooth and WiFi support
2. An application running on the PI to relay beacon status to the main back-end (item #3 in the list above)

Development

Choosing the hardware

We decided to use Estimote (www.estimote.com) stickers for the first try but we soon discovered that beacons were much more suited for what we wanted to achieve. Stickers emit signal when moved while Beacons emit periodically and can send signals up to 70 meters, plus the battery can be replaced.

The first tests were quite promising - Estimote has a useful app for testing and configuration and even boilerplate projects to build your own applications, plus a cloud service to connect and configure your beacons, pretty cool). However we soon discovered that calculating distance from a beacon is not quite as straightforward as we thought it would be (the “accuracy” value is not enough, unfortunately, due to the signal interference by the different elements such as walls, furniture, etc.). More on this one later.

For the monitoring part we got a Raspberry PI 3 that already has bluetooth and wi-fi. The initial testing was successful and straight-forward with the use of open-source libraries. We had to update the Node version that comes with it to be able to run the apps and the bluetooth code to detect Beacons.

Implementing the back-end API

The first development step was to create a back-end application that would store data. We decided to go with the “quick-and-dirty” approach and created a Node application using FeatherJS. We used a simple library named NeDB that provides file storage based in JSON format. The result was quite straight-forward and very performant. For the first attempt we ended up deploying locally but the idea was to use a cloud service.

The API ended up as follows, simple enough for our use-case. We used Apiary to document everything and we were quite happy with the result. You can find the API in docs.demoroom.apiary.io

  GET /rooms // list all rooms
  GET /rooms/{roomId} // info for the given room
  GET /beacons // list of beacons
  GET /beacons/data // all beacon data

GET /beacon/{beaconId}/room // room info for the given beacon GET /events // list all events POST /rooms // create a new room POST /rooms/{roomId}/book // book a room

As for the UI, we used Facebook's React that allows us to create re-usable components and is the standard at our company. The UI allows to add and edit room information plus making new reservations. We even integrated a small calendar widget that allows us to visualise room utilisation. Of course, there is a list with all the events and a small form to add new ones.

The final UI used in the demo looks like:

Monitoring Beacons

As previously mentioned, part of the idea was to add a component for monitoring. We decided to go with a Raspberry PI for that (we could have chosen an Arduino as well which would be more cost-effective but probably require more development effort) and a small Node.js application to scan for beacons and report their status to the main server.

For this part of the project we used a couple of open-source libraries:

• bleacon - a Node.js library for creating, discovering, and configuring iBeacons
• express - a fast, unopinionated, minimalist web framework
• axios - promise based HTTP client for the browser and node.js
• noble - a Node.js BLE (Bluetooth Low Energy) central module
• socket.io - node.js realtime framework server
• async - higher-order functions and common patterns for asynchronous code
• estimote-sticker: Estimote's library for beacons

For the UI again we used React. For tracking, we added the following information:

• the status of the connection to the main server (the one receiving the pings from the beacons)
• the list of beacons detected and the elapsed time since the last signal received

Note that more information can be obtained from the Estimote beacons, such as temperature, but you need to connect to the beacon and the Estimote cloud for that.

The last piece: Mobile App

For the mobile piece we wanted to have the following features:

• a quick way to determine if a room was available or not and book it right away, along with the room assets (because sometimes you need to know if there is a projector in in or not)

• to show a list of nearby rooms and their status, and be able to switch and book them

We used Microsoft’s Xamarin to create the mobile application as it allowed us to deploy it in iOS, Android and Windows. The development is done in C# and customisations can be added per platform. We used the Estimote libraries for the apps.

The following is a screenshot of the app running in Android:

Connecting all apps

At first we essentially did a pull version in which the apps would pull the info whenever the user requested anything. This happened for instance when we detected a new beacon and nothing was shown on the screen or when the user forced a refresh.

Whilst this was ok for the demo, we soon realised that to be more realistic we would need to update the information as soon as possible, otherwise we would have to deal with rejected bookings, etc.. Naturally we ended up using web-sockets (the reason why socket.io is listed as a dependency in the monitor app) which ended up working pretty well, specially for demos since always nice to see all devices updated as soon as one booking is made.

Conclusion

The concept was presented to the customer with positive feedback. Curiously, a similar concept had been attempted using tablets placed at the side of every meeting room entrance. We have actually heard of a similar scenario somewhere else and our first thought was that it seemed quite expensive, given the fact that everybody (well, almost everybody) seems to own a smartphone these days. By the way, the tablet concept failed not for costs reasons but for failed integration with Exchange.

For our concept to work we only need a smartphone and Bluetooth enabled for the discovery of beacons. Bluetooth is not really an issue anymore thanks to low emissions, so from a cost perspective it fits quite nicely.

Side note: integration with Exchange

After the initial prototype we ran a few tests to make sure integration with Exchange would work. It actually wasn’t that difficult and the final version of the mobile app was able to book a room through Exchange as well – pretty cool.

Final remarks

All in all, it seems like a very interesting landscape to explore. Our concept proved that the technology can be used, so the next step would be to integrate it with some Cloud offerings in order to make it scalable. We are targetting the Oracle cloud for now, with the following services:

• IoT Cloud Service to receive and analyse beacon signals. Using stream explorer would allow us to detect anomalies and process alerts

• Mobile Cloud Service to expose the back-end APIs and gather usage statistics

• Process Cloud Service to be able to schedule beacon and Raspberry PI maintenance as well as emergency maintenance calls

That's all for now. Stay tuned!