Part 1 in our trilogy spanning journey to create a smarter office with Amazon Echo’s Alexa. We’ve posted previously about the enjoyment we’ve found developing skills for the Amazon Echo. No stranger to this agreeable device, after finishing the last assignment we decided it would be cool to build something our Matchbox co-workers could use on a daily basis. After all, everyone is talking about smart homes but what about smart offices?

With this shared ambition we embarked on a project extensive enough to dwarf our previous Alexa-based efforts. In fact, its length is so epic we’ve had to split it into three manageable segments, you join us at the very beginning (see here for Part 2 & Part 3).

To get things started we compiled a small internal team; Megan Rabin (Director of sales), Georgia Edmonds (Producer), Giulio Ladu (Development), and Adam Thoms (Design).

Refining the initial idea

Adam Thoms – After creating a shortlist of Alexa ideas we opened up an office wide vote, honing in on ‘a screen and audio notification system for the Meeting Room’. It struck us as the most practical, efficiency-improving solution to our typical workday in the office.

A recurring dialogue you hear around Matchbox HQ is ‘Do you know if the Meeting Room is free?’, which then involves someone launching the shared calendar within Outlook. Or if already inside the Meeting Room, sometimes a little head might poke round the door to see if it’s available, a tad distracting when in the middle of a Skype call.

alexa meeting room assistant

We envisioned a better approach, not to replace the current PC-based creation and editing of meetings, but to offer a quick, hands-free and easily accessible reference point of information. It also had to be visible, conveying availability in just a glance. So in addition to Alexa’s conversational prowess, we would need some kind of visual display.

Technical Approach

Giulio Ladu – While planning the start of this project, we looked into how Alexa applications (Skills) could be hosted. We found that there are two ways to do this; the first is by creating a Lambda function which can be hosted using Amazon Web Services; the main benefit for doing this is that it is very quick to get a skill up and running, and all certifications and the authorization are handled by the Amazon cloud.

The second option was to host the service ourselves and handle all the interaction and authorization. In our previous projects we used the Amazon services to host our skills, however this time round we wanted to branch out and try something different – because, why not!

We decided that we would need a web service hosted somewhere which would be able to serve up our data. We knew what data we would be displaying, the final decision was to decide what hardware we wanted to use, and how we wanted to use it. I was keen to try out the office’s shiny new Raspberry Pi 2.

I also wanted an opportunity to check out the new operating system released by Microsoft called Windows 10 IoT core; a scaled down version of an operating system which could be used with our new Raspberry Pi. So with this in mind we set about thinking how this could all fit together.

Thoughts on the end experience

AT – Early on we could see colour would play a big part in communicating the meaning of information. Red and green are quite universally understood as negative (stop) and positive (go). So when it came to choosing an output display for the setup, we selected an LED board.

This gave us the functionality to present data in red (indicating the Meeting Room is unavailable) and green (if it is available).

Laying the foundations

GL – The next step was to load Microsoft IoT core on to the Raspberry Pi to host the new service, which will be called by Alexa. The service will connect to our shared calendars which would pull down and format the relevant data, and construct a response for Alexa to speak. At the same time the service will connect to an Arduino via Bluetooth 4.0 and update an LED Matrix with the current meeting room status.

How should it work?

AT – For the LED board, one source of inspiration was train station displays. With the limited space they occupy, but lengthy amount of information they need to present (destination stations, times, delays etc.) they seemed like an applicable subject to research e.g. what techniques do they employ to do this? Typically, the display will hold on the primary information, such as ultimate destination, then beneath (or sometimes on the same line) begin to horizontally scroll through a list of secondary items; in this example, the different stops the train will make.

From here we sketched out how this process could be applied to the information in our Meeting Room calendar. Passing this to Giulio, he was able to start investigating existing scrollable code libraries and report how these would affect the content displayed on the LED board, such as character limits and buffering speeds.

Creating a hosted service for Alexa

GL – I wanted the LED Matrix to be completely portable, and thus decided that the Arduino, with its small power footprint would be ideal. I also liked the idea of using Bluetooth communication as this would minimise the number of cables running out of the device, and would allow it to be hung from the meeting room door.

Hosting a service which Alexa can interact with requires following some strict guidelines, one of which is that all communication needs to be through port 443. This solution would have involved some major configuration issues in our office network, so we had to think of a work around. After further scouring through the Amazon Developer Forums (which is full of extremely helpful people) I came across a post where someone had previously had the same issue. It became apparent that a possible way around this would be to host a pass through Lambda function on the Amazon services. This is a function which packages up the request made by Alexa and passes it to a hardcoded URL to handle and process the data.

Although this wouldn’t be possible to use this approach for a skill which is going to be distributed via the Alexa store, it seemed to be just what we needed. This would allow us to call our own server and still handle data processing, as well obtain information about how Alexa interacts directly with a web service.

Onwards and upwards

We close Part 1 of our Alexa trilogy with a clearly defined project objective; having sketched out initial design considerations and even implemented the fundamental technical components.

Continue to Part 2; we tackle the issues of creating a custom web server, start outputting content to the LED display board and even find time to delve into the interesting world of 3D printing.

The service will connect to our shared calendars and construct a response for Alexa to speak. At the same time the service will connect and update an led matrix with the current meeting room status.
Giulio Ladu
/ Development


  • Bluetooth Developer Studio
  • 3D Printing
  • Windows IoT Core
  • Amazon Echo
  • Raspberry Pi 2
  • Arduino
  • LED Matrix