The Internet of Things Database – IoT APIs with David Janes

A deeper dive into why we are at a critical junction in the IoTs development, and how we are over complicating it’s definition.

Give us some background about your interest in the Internet of Things.

I started getting interested in this space about three years ago. I was initially drawn to the IoT hardware space.

As you know, to really do a good job selling a successful hardware product requires teams, along with a massive amount of financial investment and hard work. I went to Home Depot one day and was exploring, “What if I want to produce a smart wall socket?” Just realizing the economies of scale, where people can go to Home Depot and buy a wall socket for $3, and they sell them in the tens of millions, was overwhelming.

I think this is why you’re seeing a lot of stuff in the hardware space go sideways right now. They basically came around to the same conclusion as I have: that you can’t make money directly from the hardware, so they’re going to make it in software.

As a result, you’re seeing people creating an interesting product — but they’re not really open, everything has a proprietary API, and they are driving the consumers into being locked into using their cloud service.

The “one app for one device” issue?

Exactly. The whole point of all this stuff is to make the world simpler. The underlying vision of the IoT was not “I get to buy $50 dollar light bulbs”.

Right now the IoT is just making our lives more complicated. We shouldn’t care if it is an LG TV, or Samsung TV, or Philips Hue or some other bulb manufacturer just so that you get the environment that you want. Without a very high-level universal control language we can’t accomplish those things.

It turns out we don’t really need a whole lot of vocabulary to describe the world in terms of the home. I can turn my TV on or off. I can turn the stove on or off and set the temperature. I can lock or unlock a door. I can open or close a window or can set my thermostat to a certain degree.

I’ve also always been interested in the Semantic Web. The core of the Semantic Web is, rather than giving things IDs, everything is instead described by URIs. If you come up with a software system that uses Semantic Web terminology to describe things, then theoretically you could invent new words and phrases to eventually get the vocabulary right. Then your interaction with the connected device can be summed up as: “I want to do X.”

So with IoTDB, you’re trying to standardize that terminology?

We don’t need to have an “IoT Standard” if we can systematically describe what things actually do. In other words, IoTDB implements a Semantic Metastandard.

Everything inside of IoTDB is built around the mental model of APIs: that we manipulate and monitor Things by manipulating JSON dictionaries. IoTDB does all the hard bits in code, so the end programmer only has to do thing.set(“:on”, true); or thing.set(“:on”, false);

IoTDB is the vocabulary part of it, and HomeStar (the web interface and database management tool) handles the HTML user interface — presenting the RESTful API, hooking into notifications systems like MQTT, and installing and configuring IoTDB related modules.

These are both open source, correct?

Yes. If you go look at the GitHub repository, there’s a whole lot of probjects like homestar-wemo, homestar-sonos, homestar-nest, etc., that give you a glimpse of the individual drivers for talking to things. The nice thing about those Node.JS projects is that they’re independent.

In terms of this project’s evolution in 2015, I believe that the way to do things is following the path of how the Web works currently.

We’re good at APIs, so we can connect to services like Twitter or database APIs. Things have identifiers. You can inspect the thing to get a list of what’s there, you can write data to it to change its state, and you can read from it to get its status.

I find the concept very appealing as a simplifying maneuver. It seems like a recognition that we’re already sitting on a lot of the components and skills we need right now, and can leverage a massive developer community that’s already familiar with JavaScript from making web applications.

What we have to realize, and a lot of people have started to, is that JSON and JavaScript have won. I’m originally a Python guy, but in terms of scripting — if you go with JSON and JavaScript, you’ve got things covered. Just like people said HTML wasn’t the best thing in the world, or HTTP wasn’t efficient enough, they are there and they are good enough.

How would your project compare to some of the others in the space, like AllJoyn, W3C’s work, or others?

Right now I can’t really just jump in and start using Alljoyn or even understand what all of the elements are without a significant investment. I keep asking why, since we have a phenomenal model on the Web for manipulating resources and databases. I believe we can control all the things we need using exactly that same model, so why would we be using anything else?

At this point you’ve got Apple’s Homekit, Google’s Brillo and Weave, something probably from Samsung…they’re all proprietary stacks that don’t play well with others, and are going to suck a lot of the oxygen out of the room.

What I am proposing is what developers actually want. Something that can be infinitely flexible like the Web, reasonably efficient, and works exactly on the RESTful resource model — which is that you manipulate things using a few simple verbs against resources.

Of course there are other areas of the IoT, like the Industrial Internet, where they will have goals with different requirements.

Are you familiar with Scott Jenson’s Physical Web project?

Yes. There’s nothing wrong with the Physical Web. It’s a powerful, super-simple idea, exactly like the Web. I just don’t think it fulfills everything we are looking for. There’s no communication or connection to the device in the Physical Web, and being dependent on a website or cloud service is also a dealbreaker for many applications. It can’t be a requirement that the entire Internet be in working order for me to control my house.

How do you handle device discovery?

With the HomeStar system, once you have the app, you can walk into the room and inspect the network.

One of the inspirations behind the project came when I was sitting in a bar with my friend and I said, “Wouldn’t it be great if everyone in here could have a vote on which channels the TVs should be on?” — and that led to us discussing exactly what would be required for this to actually happen.

First is that people have to be able to discover the device. With the major players — Bluetooth Low Energy, Network Discovery System (NDS) and Universal Plug and Play (UPnP) — that’s all we really need for successful advertising.

Second is what the devices need to advertise. They have to say, “Here’s my API, and here’s a semantic description of how to operate me”. Then even though I don’t have an app for that device, I can still control it.

With a system like this, I can go into a bar that I’ve never been in before and can easily understand that the device is advertising “I’m a TV”, “Here’s how you change a channel and turn me on and off”. We don’t need a custom app to operate this, all we need is to discover it, manipulate it using HTTP and we get a status back.

Nothing needs to be more complicated than that. Discover, get status, and hook things up to it.

So HomeStar will need a hub?

Of course you need something to run this on. Right now Node.JS can run on Beaglebone Black, all kinds of Raspberry Pi, Intel Edison, etc. So I’m not worried about a world where we don’t have things that can run Node.JS.

For people that don’t have as much experience or the interest to deploy it themselves, there will be a Mac and Windows app that will allow people to deploy it and access it from a web page to begin controlling things around their home.

Let’s put on our “speculation hats”. Where will the IoT be five years from now?

I honestly think we will see a similar trajectory to the Web. I think we will have all of these things that will be incompatible until we have open APIs in order to control some of them.

At first no one actually wanted the Web. People wanted things like X.25 and other proprietary things that a telecom company sold.

We’re seeing this with texting standards now because the phone company had been charging 10,000x their unit price for SMS. So there is a glimpse at a possible dystopian future in terms of where the IoT could be in five years time, in that we could have three or four “stacks” that will be incompatible and will never work with each other. Although it might not be the worst case scenario, it certainly isn’t a good one.

Right now we are right on the knife’s edge on which way we are going to fall. Are you going to live in an Apple Stack world, a Google Stack world, a Xiaomi Stack world or a Samsung Stack world?

A better scenario is that you can walk into an environment and discover things, and based on your relationship to the owner you might be given certain rights for certain things. For example, if you come into my house you can shut off the lights in the room you are in, or you might be given some time-based permissions to the door lock if you are visiting for two weeks.

I think this vision is entirely feasible. If this world happens the way I would like to see — where everything has an open API, uses web standards, exposes an interface to the world and authenticates those wanting to use it — you could walk into any environment and use it. And that’s really where we want to go.

I assume an ideal case is that product developers jump on board with IoTDB, so it’s baked in from the get-go and you don’t have to develop these drivers.

Right now we have the driver discovery down so we can integrate new products using a base template and “things just work”, which is great.

What’s next?

Let’s put IoTDB at a strong “alpha” stage. I think we are onto some great concepts that will resonate with people.

We are looking for more Node.JS people. I would also like to get in touch with people who own connected products and actively use their devices, and would like to see their devices integrated into this system.