There are a lot of little things that can cause friction in an office, but one of my personal pet peeves is conference room hijacking. We have twelve conference rooms in our office these days, and even though we use Google Calendar to schedule access, we still struggle with rooms being hijacked.
It’s almost always an accident – two people start chatting, one inevitably says “Let’s grab a room,” and then they just walk around the office until they happen upon an unoccupied room. Unfortunately, it’s often the case that while the room is currently unoccupied, another meeting is scheduled there in the near future. In a few minutes, the rightful occupants show up and discover that someone is already using their room! If the squatters are just using the whiteboard, it’s easy to boot them out, but if they’re taking a phone call, the people who actually reserved the room have to find a new one. The ability to do ad-hoc meetings is something we want to keep. We just want to help room-grabbers know when it is OK to grab and when it isn’t.
To try and ameliorate this problem, I spent a few of my company’s hack weeks last year working on a system I decided to call The Roominator. I originally announced it over on our dev blog, but since then I’ve been pretty sparse on the updates. I wanted to summarize the design and status of the project here for posterity. (The actual code and schematics can be found on my GitHub account.)
The Design
The arrangement that I came up with involves three key components: a display unit, to be posted outside each conference room; a “master” unit, to be stashed in our wiring closet, that distributes power and data to the displays; and an application server, hosted wherever, that does all the heavy lifting as far as the Google Calendar things go. Let’s take a look at each component in more detail.
The Display
The display component of the Roominator is actually very simple. From a UI perspective, it’s nothing more than a
20×4 character LCD, a pair of
big, arcade-style pushbuttons, and three status LEDs. (And a handsome laser-cut acrylic enclosure!) The LCD displays details about who has booked a room and until when, while the LEDs give you a quick way to tell if a room is available when you’re standing at the end of a hallway.
The two buttons allow you to make and modify ad-hoc reservations. When there is no existing reservation, the left-hand button lets you make one, with a default duration of 15 minutes. If there is an existing reservation, then the left-hand button becomes an “extend” function, allowing you to add 15 minutes at a time, while the right-hand button offers you the ability to cancel the reservation.
Basically, the workflow I imagined is the following. You are walking around the office looking for somewhere to have a quick ad-hoc meeting. You look down the hallway and see a room with a Roominator that’s illuminating it’s green LED, meaning it’s open for at least the next 15 minutes. You walk up to the room for more information, and see that the next reservation isn’t for an hour, so you press the “Reserve” button once to get the room, then again to reserve it for a total of 30 minutes. You get done with your meeting early, so on your way out of the room, you press the “Cancel” button, which frees up the room for someone else.
The Master
The Master unit is a back-office component that serves as a go-between for the displays and the application server. The Master has a little bit of smarts in it, but not too much. It has an Ethernet jack on it which it uses to communicate with the application server over standard HTTP. Every second or so, the Master pings the app server to see what each display should display and to report in about button presses gathered from the displays.
To communicate with the individual displays, the Master has an array of RJ45 jacks. They look just like Ethernet, but actually carry a protocol called
I2C. It’s a very low-level serial protocol that doesn’t require all that much in the way of microcontroller smarts, but nonetheless supports master/multi-slave architecture, which is just what we need. Plus, it has
built-in support on Arduino!
In addition to a network connection, the Master also provides power to the displays. Each of the jacks on the Master has a 12V pin and a ground pin. This allows the displays to have exactly one plug and work 100% with existing wiring. This prototype is built out of the remains of an old Ethernet switch, which we gutted for the case and the power supply, and a pair of lovingly hand-soldered port arrays.
The Application Server
Rather than work hard to write all the Google Calendar interaction code on an Arduino, we chose to put all of our complex logic in a Ruby on Rails application that we would run on a spare computer in our office. (We already have other random applications running on the same computer, so it’s not really am additional cost.) The HTTP web interface of this Rails app serves a two-fold purpose: first, a particular URL that the Master will ping constantly, and second, a place for us to configure and monitor the system as a whole.
Since this app doesn’t involve very much data, we used the default SQLite database to hold a few simple tables for mapping displays to room names and Google Calendar IDs. The calendar integration did turn out to be a bit dicey, though – the APIs have strange behavior, particularly surrounding recurrent events and deleted events, and they can be REALLY slow to return. To work around the slowness issue, we do all the calendar API stuff in a separate thread, sharing a lot of state between the calendar thread and the update requests via the database.
But… does it work?
The answer is: kinda.
We fought through lots of problems and got as far as installing all 12 displays outside the conference rooms in our office, and while we did a pretty decent demo, we aren’t using it today. It came down to two key problems. The first problem was I2C. I2C is limited by the total amount of wiring in the network, and a few of the cable runs in our office were much longer than I expected. This meant that some of our conference rooms just couldn’t be served by the system. Additionally, the protocol proved fragile – if any one display had an issue, it would cause the entire I2C bus to freeze up, which could only be fixed by restarting all the units.
The other problem was in the application server. As I previously mentioned, the Google Calendar API didn’t prove easy to work with. There were edge cases we discovered that caused certain events to be displayed incorrectly through the system. And if our users couldn’t trust what the displays had to say, then the whole system would be useless.
Both of these problems are, of course, surmountable with more effort. However, the amount of effort required to redesign around a new communication protocol and to fight against an external API is pretty monumental in comparison to the actual value of the project. As much as it pains me to quit after so much effort, for now, this idea is going to be relegated to the back burner. I’d love to work with others who are interested in the concept to develop it into something everyone can use!
Like this:
Like Loading...
Related
Bryan Duxbury's Blog 