Giving a Voice to IoT
The process of developing communications applications is changing, and changing fast.
"Don't tell me the moon is shining; show me the glint of light on broken glass."
The world of technology has changed immeasurably since I began writing software way back in the late 1970s. Devices are smaller, storage is nearly infinite, processors are orders of magnitude faster, programming languages are far more graceful, and systems have gone from proprietary and closed to standards-based and open.
Having recently returned to writing software after a hiatus of many years, I am especially struck by the changes in how one service speaks to another. While I've kept up with the technology from an academic standpoint, it is one thing to write about RESTful Web services and a completely different experience when you roll up your sleeves and write code that sends POST commands and processes GET requests. That is where the rubber hits the road and you begin to truly understand how things work in real life.
If you've been following my Avaya Breeze videos, you've seen how a drag and drop interface can now create applications as powerful as those that once took hundreds, if not thousands of lines of Java, C#, or C++ code. More importantly, these interfaces shield the developer from having to understand the more technical aspects of programming. For example, it becomes possible to make RESTful Web services without having to understand HTTP, response codes, or message bodies. Those things are still happening, but they are completely hidden.
Of course, even the best interface cannot anticipate every need. Case in point is my work with IoT technology and endeavors to connect communications workflows to temperature sensors, light gauges, and similar telemetry devices. Despite my best and somewhat heroic efforts to shield myself from the nitty gritty details, I found myself immersed in BLE (Bluetooth Low Energy), customized HTTP headers, and APIs far more complicated than what is available through the most comprehensive drag and drop toolkit. While knowledge isn't a bad thing, you reach a point when your brain can only handle so much new information. It's then that I am reminded of that line from the 1970s movie, Caddyshack, "Well, the world needs ditch diggers, too."
All of this brings me to what I really want to write about today -- the Silicon Labs Sensor Puck. This IoT device is probably one of the most exciting toys I've played with in a long time. In a nutshell, it's a 1.5 inch diameter circuit board that can measure temperature, relative humidity, ambient light, UV index, and heartrate. Powered by a standard 3 volt CR2032 battery, the Sensor Puck can be used as a standalone telemetry device, or be integrated into larger solutions that use telemetry, but are not necessarily focused on it.
The Puck uses BLE to broadcast real-time data to any interested party. Silicon Labs provides their own mobile apps for Android or iPhone (shown below). Additionally, third parties can develop middleware components that collect data from the sensor while providing a Web services API for systems integrators. This middleware approach is how I am using the product. While I have managed to learn how to spell BLE, programming to it is beyond what I am willing to undertake for fun or profit.
From Sensor to SMS
For me, the excitement over the Sensor Puck is not in a visual dashboard of climate data. The real power is feeding that data into a rules engine that allows me to set thresholds and actions. For instance, it's extremely important that the air temperature within a data center be kept between 70-75 degrees Fahrenheit. Anything colder is a waste of energy and might actually lead to moisture problems. Anything warmer can lead to overheating and catastrophic equipment failure. This temperature range allows servers and adjunct equipment to operate efficiently and reliably.
Combining the sensor puck with a rules engine and communications API allows for the creation of an alarming system when particular environmental conditions indicate a problem. For example, text messages can be sent to "first responders" whenever the temperature goes above or below a prescribed range.
Even better, a rules engine can report on trends, and actions can be taken before it might be too late to save valuable equipment and uptime. For instance, a two degree temperature change in two minutes may indicate that something is terribly wrong. In this case, a technician can be alerted before the temperature rises above the threshold maximum.
Looking beyond temperature, the Sensor Puck can be used to create alerts when a patient's heart rate is too high or too low. I envision an application that launches a video call when the rules engine determines that something is amiss. This would provide home-bound patients with better care without a 24-hour-a-day on-premises nurse. And at less than $30 a piece, the Sensor Puck can become part of a cost effective solution for overall health of people and things.Next Things Next
While Silicon Lab's Sensor is a really cool, inexpensive IoT device, it's only the tip of the iceberg. I have yet to do my homework, but there may be a similar device that reports more, is smaller, possibly cheaper, and supports a Wi-Fi interface. BLE is fine for prototyping and small scale solutions, but the devices that support it are clearly distance limited.
The marriage of IoT and communications is only in its infancy and I expect to see some very clever products as functionality increases on both sides of the house. Next-generation devices will deliver more features, and communications APIs will allow for extremely sophisticated ways to contact people and machines. The building blocks are there and it's only a matter of time before solutions are plentiful.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.