In this latest installment of our ongoing IoT blog series, we’re going to start discussing a more extended pipeline that we’ve installed here at SnapLogic HQ (as promised in the last post). Space prohibits us from showing all the details of how it works, but we’ll hit the high points in this post and the next.
You may have, at some point in your career, been in a meeting that has gone overtime. (You may be in one right now). You’ve probably wished for something to stop the meeting. Well, the Internet of Things is here to grant your wish.
We’re going to create a pipeline to activate a conference room meeting-is-over signal, the Luminescent Evanescent Apparatus for Voiding Engagements.
The pipeline queries the Google Calendar FreeBusy API to find out when meetings should end for a given conference room; the pipeline then processes this information into a “time-until-finished” variable and computes a unique hash for the meeting. If 5 minutes or less remain for a meeting the filter allows this information to pass on to the endpoint. This can be a POST to the microcontroller, or, for more generality, a push to a general queueing mechanism (e.g., RabbitMQ). The latter approach is similar to the additional abstraction layer an IoT hub service would give you. In that case, we’d also include in our document the id of the conference room we wanted the message to go to.
We use a particle.io Photon as our microcontroller. Photons are (mostly) Arduino-compatible, but have substantial native cloud functionality. In particular, we can expose functions in the firmware as REST endpoints. This means we can write the firmware (in a subset of C++) that causes things to happen in the real world, and we then can invoke that functionality with a simple POST.
We run this pipeline as a scheduled task once per minute. This is the reason for computing the hash – we can pass multiple messages to the Photon (or broker) about the same meeting but the device knows to ignore messages whose hash is the same as the previous message. This is a design pattern you may find useful – it can be easier to keep track of state on an endpoint than in a pipeline. (Executing every minute and looking for a delta under five minutes means we’d expect to generate the meeting-is-over message 5 times, and perhaps even 6 on an edge case).
The trickiest aspect of this pipeline is getting the GET request to Google Calendar correct. You’ll need to make sure you have the correct permissions on the Google account you’re using, and make sure you pass the right parameters in the GET request and also in the authorization. The final result will look something like this:
We convert the output of the FreeBusy API into ‘delta-times’ – the difference between the current time and the meeting end time. Lastly we generate a “hash” – really just an encoding operation – on the meeting end time. The time until the meeting ends and hash are passed through the Filter to the endpoint if the meeting ends in less than five minutes. Those are the only two pieces of data our microcontroller needs from us.
The next post will discuss the IoT device and its software. In the meantime, check out the rest of the IoT blog series, or to reach out to us for a demo.
