Personal clouds running the CloudOS provide a place where incompatible systems and technologies can meet, be programmed, and come together to form a complete, seamless solution. A personal computer can talk to any number of peripheral devices, regardless of manufacturer, so long as device drivers existed for each peripheral. This made PCs very flexible and consequently they provided a foundation for everything from desktop publishing systems, to point-of-sale systems, to manufacturing controllers. Similarly, a personal cloud running the CloudOS can link together systems from different manufacturers and various APIs to do useful work.

The Internet of Things will provide us with plenty of incompatible systems that need to work together. For example, last month I wrote about controlling a Philips Hue lighting system from my personal cloud. Recently Scott Lemon introduced me to the Universal Devices ISY-99i, a connected hub for Insteon and X10 devices. The CloudOS is the perfect way to make these incompatible systems work together.

I wanted to demonstrate how the CloudOS provides a programming abstraction that can bridge the Insteon and Hue worlds. The following diagram shows the system as-built. The Hue hub and ISY-99i serve as translators between the Zigbee and Insteon protocols and HTTP. My personal cloud has what amounts to device drivers for each. Apps running in my personal cloud allow me to program the interactions of these two systems as well as manually control them from devices like my phone or iPad.

Specifically, my goal was to control both Hue and Insteon lights based on the status of the door switch or motion detector. The remainder of this post will give some details about how all this works.

Philips Hue

As I wrote earlier, the Hue is a Zigbee controlled lighting system that Philips sells through Apple. There is a unofficial documentation and support for the Hue API. I wrote a Hue service for my personal cloud that understands the Hue API and can be configured to talk to a particular hub.

I also wrote a user program for my cloud that allows me to manually control the lamps:

The controller is simple, but it works sufficiently to demonstrate the Philips Hue.

Insteon Devices

The ISY-99i is a controller for a dual-band Insteon modem (power line and RF). The controller has a simple API. You configure and control it using a Java program running on your computer. The ISY-99i connects to various Insteon devices. I have a couple of LampLinc plug-in controllers, an open/close sensor, and a motion sensor.

The ISY-99i provides a simple, IFTTT-like programming interface for connected devices. You can respond status changes and change their settings inside the rules. With the software-based network module, the ISY-99i can make HTTP calls in response to status changes for a given device.

Putting Them Together

My goal was to demonstrate the ability of my personal cloud to serve as the meet point for these two systems. The idea is that the Insteon motion controller would be able to turn on both Hue and Insteon-controlled lights. The surprising thing is how easy this is to do.

As I mentioned, the ISY-99i can make HTTP calls, so making it raise events for status changes was easy. The only fly in the ointment is that Universal Devices doesn't support variables in the HTTP calls (the ISY calls these "resources") so rather than creating a single event resource that is parameterized by Insteon device and status, I had to create a "resource" for each event. For my experiment, that's not a big deal, but if I had 20 motion detectors or door switches it would be a major headache. Universal Devices needs to fix this.

For demonstration purposes, I used the door switch rather than the motion sensor so I didn't have to wait for the motion time out while I was experimenting, but in principle it's exactly the same. I created an ESL (event signal URL) with a channel to my personal cloud for each state of each device. For the door switch, I used the events office:door_open and office:door_closed. As a result, my cloud is notified when there is motion in my office or when the door is opened or closed.

While I could write any number of rules responding to those events, the rules for controlling the lights are simple:

rule turn_one_on {
  select when office door_open
  hue:all_on_in_group(0);
}

rule turn_one_off {
  select when office door_closed
  hue:all_off_in_group(0);
}

The first turns all the lights in group 0 on when the office door is open, the second turns them all off when the door is closed. It really is that simple once the device drivers are in place in my cloud. Once we had the devices connected to the ISY-99i and the ESLs in place, it was just a few minutes to make it all work.

Conclusions

Don't think of this as yet another "home automation" solution. While it certainly looks similar, it differs in an important way: the system doing the controlling, the CloudOS running in my personal cloud, is a much more general purpose platform than typical home automation solutions:

1. The system supports devices from different manufacturers
2. The system supports programmed interaction with other APIs.

The system could, for example, allow some other program I'm running to use the hours a room is occupied to determine usage patterns for the office or automatically queue up a furnace filter order based on how many hours a furnace has run. There's literally no limit on what can be programmed in the system.

This works because the CloudOS provides a programming model. While I wrote the drivers for the ISY-99i and Hue hub, there's nothing keeping engineers in those companies or any other from writing a driver for the CloudOS. The CloudOS provides an open platform with a well-defined programming model. No special permission required. That's vastly different from services like IFTTT where they pick the connections. What's more, third parties can provide drivers.

While companies would likely create drivers so they can create their own experience in the CloudOS for their product, once the driver exists, other programmers can take advantage of it to link things together. Just like the PC gave rise to incredible variety in application due to it's programming model, so does the CloudOS. The software becomes the key and represents the value. Cheap devices become powerful under the control of sophisticated software.

The Internet of Things will provide connections to most of the things around us in our lifetime. Will those connections allow my things to work together on my behalf? Only if they are connected to general-purpose programming environments under my control.