#node-iotdb

[imadeit-davidjanes]

Connecting Node-IOTDB to your Datastores

The last big component I'm adding to Node-IOTDB is the concept of a "store", basically a place you want to send data. Example data stores are Dweet.io, Xively, Zatar and Data.Sparkfun.com / Phant.

Here's a complete example - track everything I know about:

var iotdb = require('iotdb') var iot = iotdb.iot() iot .store('dweet.io') .track( iot.connect() )

That's it - every single thing in my home network (as discovered by iot.connect() will be sent to dweet.io (by the track method).

For example, here's the temperature from one sensor in my house:

http://dweet.io/follow/urn:iotdb:device:3ce6a7f8f8a75088f30122863067aa64

{ "temperature": 65, "@context": "https://iotdb.org/dpjanes/models/smart-things-temperature", "@type": "smart-things-temperature", }

The @context and @type are JSON-LD markers that tell you how you - or especially your code - can interpret the word temperature. If you go to the @context you can see the exact definition of that value.

There's support for metadata too. That'll be an upcoming post.

[imadeit-davidjanes]

Controlling devices using IOTDB facets

"Facets" are basically tags that can be arbitrarily added to Things. Take the following example:

iotdb = require('iotdb') iot = iotdb.iot() iot .connect() .set(':on', true)

That code fragment turns everything on. But what if you only want to turn on the lights? Facets let you do this:

iot .connect() .with_facet(":device.lighting") .set(":on", true)

This will select only Things tagged with the facet iot-facet:device.lighting and then turn those on.

The facets named device.* are roughly based on The Thing System's Device Class, but there's no need to restrict ourselves to that. For example, we could add facets for "zones" (similar in concept to Apple's Home Kit Zone) and then do things like this:

iot .connect() .with_facet(":device.lighting") .with_facet(":zone.party") .set(":on", true)

Node-IOTDB is a package that provides a universal interface for controlling and monitoring the Internet of Things.

[imadeit-davidjanes]

TCP Connected Lighting now supported by Node-IOTDB

We've added drivers and models for TCP Connected Lighting to Node-IOTDB.

Example - set all the lights to half-brightness

var iotdb = require('iotdb') var iot = iotdb.iot() iot .connect('TCPConnectedLight') .set(':brightness', 0.5)

Example - turn the the light named 'Bedroom' on

iot .connect('TCPConnectedLight') .with_name('Bedroom') .set(':on', true)

Example - turn off all Philips Hue and TCP Connected Lights

iot .connect('TCPConnectedLight') .connect('HueLight') .set(':on', false)

Node-IOTDB is a package that provides a universal interface for controlling and monitoring the Internet of Things.

[imadeit-davidjanes]

Node-IOTDB (v2) - Chaining 'connect()'

Node-IOTDB now allows chaining of the connect command. For example, let's say you want to turn on all the WeMo and Hues in your home. Here's how you do it.

iotdb = require('iotdb') iot = iotdb.iot() iot .connect('HueLight') .connect('WeMoSwitch') .set(':on', true)

What if you just want to turn on one particular Hue light but still the WeMoSwitch?

iot .connect('HueLight') .with_name('Hue Lamp 1') .connect('WeMoSwitch') .set(':on', true)

How if you want to connect a particularly named Hue with a particularly named WeMo? This is slightly more complicated, but still understandable

iot .connect('HueLight') .with_name('Hue Lamp 1') .merge( iot .connect('WeMo') .with_name('WeMo Light 2') ) .set(':on', true)

[imadeit-davidjanes]

The IOTDB Semantic Model with Schema.org

Summary

IOTDB's semantic model is built on top of schema.org's vocabulary. For ease of use, we have duplicated names into IOTDB's vocabulary and marked them as equivalent to their schema.org's equivalents.

The IOTDB semantic model can be browsed here: https://iotdb.org/pub/.

Node-IOTDB provides Javascript classes which compile into JSON-LD, make it very easy to author IOTDB Models. A number of examples of this can be found here in Javascript and here in JSON-LD.

I highly encourage you to browse those links above - everything should be hyperlinked and probably makes a lot more intuitive sense than the descriptions below.

Details

iot:Model

iot:Model are the semantic description of "Things": the data they produce (if they're sensors) or how to control them (if they're actuators). It's defined to be a (RDFs) subclass of schema.org's Thing. Yes, there's a slight bit of naming confusion here, sorry.

All the common properties of schema.org's Thing are available under the iot: namespace, e.g. schema:name → iot:name, schema:description → iot:description, etc..

Probably the most important property is iot:attribute. This links your Model to Attributes, described in the next section.

iot:Attribute

Each individual piece of data a Thing can produce and each way to control a Thing are described by an iot:Attribute.

There's a lot going on with Attributes, but here's the basic rundown:

name, description, etc. from iot:/schema.org are all there

iot:purpose links to one property from iot-attribute:, to describe why this attribute exists. I.e. is it to turn something on and off, open or close something, specify the channel, etc.. Please browse that link to find out more.

iot:role can be iot-attribute:role-control or iot-attribute:role-reading (or both) depending on whether the purpose of this Attribute is for describing values coming from a sensor or describing a value going to an actuator.

iot:related-role can be used to link an Attribute that's used as a reading to an Attribute thats used for control. E.g. one attribute is for setting a light on and off, another is for reading whether it actually is on or off.

iot:vector can be used multiple Attributes together, like for example x/y/z values

iot-js:type to specify the Javascript type of the value

iot:unit to specify the unit of measurement

and a lot more

Authoring these is fairly easy using our Javascript / Node code.

[imadeit-davidjanes]

Just a quick note that I'm revving Node-IOTDB do make setup simpler and to avoid the need for certain events to be mediately be callbacks. The benefit should be a major cutback in login in your programs and hopefully a lot more conceptual simplicity.

I'd appreciate your feedback.