On Air. The meeting assistant
Creating a warning light for the Else studio
This post was originaly published on LinkedIn on March 22 2017.
At Else London we’re a small team. Our Studio is lovely; cosy, homely, very cool I would say. We don’t even have a meeting room. Not having a meeting room is part of the Else charm. It’s one of the things that makes our Studio feel as nice as it does. There are no closed doors. Conversations take place where everyone can see. I guess in a way that makes us all feel closer to the company and to each other.
Not having a meeting room does raise a problem though: whether it is for technical reasons or business reasons, some meetings require quietness, and sometimes, people who are not involved in those meetings don’t realise that and keep doing their business as usual, being less quiet than they should.
The Idea
Being often the cause of undesired noise during important meetings, I thought to myself: wouldn’t it be nice to have a way of telling people that a meeting is happening and that they should keep quiet?
And so, the idea of a warning light was born. The initial proposition was quite simple: a recording studio style ‘On Air’ light that could be switched on when silence was needed. Quickly though, the idea evolved.
Why not automate the system, so that it could detect meetings automatically by reading a Google Calendar?
Why not set the system so that it could also pause our Sonos setup?
Can we also allow for the system to be turned on manually from each of our devices? What about having physical buttons around the Studio?
This was going to be complicated…
The Execution
The above ideas were all great, so now it was time to figure out how to build this thing. So, what did this system look like? Well, in a nutshell, a controller would connect to several sources to determine whether or not it should activate the light and pause Sonos. The sources would be a Google Calendar, to activate the system automatically as needed (i.e. when a meeting was happening), device widgets and potentially physical buttons — these would allow for the manual activation or deactivation of the system.
Below is a very rough schematic of the idea.
To create the prototype I turned to a technology I’ve used frequently to develop small personal projects (and a couple of work projects too): PHP, running on an Apache server. A few Google searches revealed helpful libraries and APIs that I could potentially use to connect to the different parts of the system.
Google Calendar API
Google has a vast array of APIs for its various products. Amongst them is the Calendar API, which allows for ‘easy’ integration with the Google Calendars service.
Turning the On Air sign on/off
To be able to control the sign without the need for cables, I decided to use a wifi plug. A wifi plug is an electrical socket which operates via IP networks and can be controlled wirelessly (usually) through a mobile app. There are a few options on the market, the best known being the Belkin WeMo, which was my initial choice, given that there were several PHP libraries available out there. In the end I opted for using the Orvibo S20, a discontinued plug manufactured by Orvibo, which was still widely available to buy at an affordable price and, more importantly, it had what seemed to be a simple to use and solid PHP library available.
Controlling Sonos
Sonos is well known for its Smart Speakers, which like wifi plugs, also operate via IP networks. Being so well known, it was fairly easy to find a decent and simple PHP library to use.
Putting It All Together
The first step was to be able to read from a specific (private) Google Calendar. This turned out to be a lot trickier than expected, but eventually, with a lot of experimenting I was able to use a PHP script to connect and read data from the calendar.
Next up was Sonos. The library was very easy to use and in no time I managed to put a script together to be able to pause, play, mute it, etc.
In the meantime, the Orvibo S20 arrived. It was a bit fiddly to set up initially (done through the Orvibo app, called WiWo), but once it was done, it worked just fine. It was also fairly easy to get PHP talking to it, using the above mentioned library.
I now had a way to read from a calendar and remotely control our sign and Sonos. All I needed was some logic to turn these different parts into a system.
The way I achieved this was by creating a script that runs every 10 seconds, checking the designated calendar to see whether a meeting is currently happening or not. If it is, it fires the order to switch on the wifi plug (to which the On Air sign is plugged in to) and pause Sonos (if it’s playing at that moment). If no meetings are happening at that moment, the script will switch the plug off (if it’s on). It won’t un-pause Sonos at this point, as we don’t want the music to suddenly come on if a meeting’s overrun. The script will also check whether or not the system’s been manually turned on or off, via the manual controls (device widgets and physical buttons) and it will ignore any calendar events if that’s the case.
Manual Controls
Being able to manually operate the system was an obvious requirement. Two controls were thought out for this purpose:
- Individual device widgets — small standalone apps that could be installed on each machine at our studio.
- Physical buttons — these could be spread out throughout the studio to allow for easy access to the system.
The physical buttons seemed to be a bit trickier to achieve, so I decided to leave them out of the scope of the project for the time being. I’ll hopefully come back to it at a later date, time permitting, and create a nice wireless solution.
The individual device widgets were a lot simpler to achieve. The control button was on a simple webpage that can be accessed from a browser on any device on our network. The page reads the system status and displays an ‘On’ or ‘Off’ button, depending on that same status.
The tricky part was creating the Mac desktop apps. I initially looked for a solution that could turn any webpage into a standalone app. I found a few options out there, with various degrees of features and implementation difficulty. Unfortunately, for one reason or another, they all fell short of what I wanted or needed. Unfortunately? Maybe not…
Having failed to find an easy solution, I decided to go the hard way and create the app from scratch using xCode, Apple’s integrated development environment. What I set out to achieve was fairly simple: a status bar app, that once clicked, opened a popover where I would then load the control web page through a native web view. Naturally, I couldn’t find a tutorial to create exactly what I wanted, so I had to use information from about 5 or 6 articles and tutorials, in order to piece the app together.
Challenges
The main challenge on this project was having all the different parts working together as one happy system. The fact that I set out with just a set of features and a vague plan to achieve my goal, meant that I was basically improvising along the way. This was great in a way, because it meant I had to put my problem solving skills to a good test.
The bright side of this lack of polish is that there’s room for improvement. Exactly what should be improved and how to improve it remains to be fully defined and the ongoing use of the system will help determine that. But some ideas are already floating around in my mind.
Conclusion
So, that’s it. The system is now live in our Studio and future weeks and months will tell how useful it actually is. As for me, I had a great time and learned a fair bit working on it. I’m also — more than ever — excited about working on experimental projects like this. They’re a great way to step out of your comfort zone, learn new skills and build something cool and potentially useful.
