(or what happens if you mash-up a Software-Defined Radio, a radio microphone, a Belkin Wemo, a fridge, Yammer and the Microsoft Exchange Server API)

Every few months at work (Red Gate), we have a ‘Down Tools Week’. This is a chance to divert ourselves from normal product ideas and to look instead at other things we could do and problems we could address. Our Down Tools Weeks generally have (optional) themes, like creating internal tools or coming up with product ideas. In this way, the Down Tools Week in March 2014 has been focused on ‘The Internet of Things’ (IoT). Specifically, we were interested in finding the problems with existing toolchains and ways of working, rather than coming up with something immediately productizable, which of course gives a greater amount of freedom for hacking things together.

If the IoT is really about the Internet of Everything (as it was put in the keynote at the recent Microsoft TechDays Paris), where better to start than looking at writing code for some daily problems in the office?

One such problem is that, as a company of around 250 people in the Cambridge office, we lack space for whole company meetings, although we still regard them as important. As a result, we often use our canteen area for larger events, which are also streamed on the intranet. But this has a problem: canteens have noisy fridges which can disturb the event. If you turn off the fridges, tomorrow’s lunch could be spoilt, and the canteen staff get upset.

Can the Internet of Things solve this?

Identifying when a large meeting is happening

The first issue is to work out when a larger meeting is happening. Our canteen is a bookable resource in the Exchange server, so on the face of it it’s easy, but ‘Lunch’ is also a recurring appointment in the room, as are some ad-hoc meetings between individuals.

One feature larger meetings share is that they are streamed as I noted above, and this also means they use radio mics. Radio mics are, of course, nothing more than a simple FM radio transmitter and in Europe at least, they tend to be at around 860MHz. Getting a cheap receiver that can listen to multiple radio channels simultaneously is also remarkably easy: the RTL-SDR dongle is ideal for this sort of application.

Once we have this receiver, we can use the GPL’d RTLSDR Scanner software to monitor for the presence of the radio microphone. This is a nice little Python script that can output a CSV file with frequency and strength – just what we need.

Writing a bit of code lets us see when the radio mic is on. While we’re at it, we also connect to the internal Microsoft Exchange Server’s API to find out what the current appointment is. We write the appointment’s ID into a SQL Server database table to ensure we don’t query the Exchange Server more than once.

If there’s an appointment that’s just starting, we can now post to Yammer to remind everyone, giving the link to the intranet stream. The Yammer post can also contain a still from the webcam that monitors the queues in the canteen.

Turning the fridge off

The last part of the task is to turn the fridge off. I’m using a Belkin Wemo switch for this purpose, which uses a very simple (un-authenticated!) SOAP protocol to query it. The program I’ve written just fires the ‘off’ command to the switch when the data comes back from the Exchange Server API.

Turning the fridge back on

Just as important as turning the fridge off is turning it back on again. We could do this when the Wireless Mic signal disappears but we frequently have multiple speakers swapping between different mics. It wouldn’t be great for the fridge to keep being switched on for a few seconds as they swap over. So, we record the time the mic went off in the database table too. A few minutes later, if the signal has not been re-acquired, we turn the fridge on again.

So, there you have it – the result of hacking together the unlikely combination of a Software-Defined Radio, a radio microphone, a Belkin Wemo, a fridge, Yammer and the Microsoft Exchange Server API!