#iotdb

[imadeit-davidjanes]

When is it appropriate to use properties and when is it appropriate to use actions? See w3c/wot#247

Me explaining why Things shouldn’t have “Actions” and “Properties”, but instead just “Attributes” (as we do in IOTDB)

[imadeit-davidjanes]

A Sensor can hold or report a measurement or a bag of measurements.

I’ve brought forward the following proposal to Schema.org for classes related to the IoT:

Thing > Product > Sentroller

A sensor, controller or actuator or combination thereof. Multiple attributes may be sensed or actuated.

Properties from Sentroller attributes: Attribute: sensing and actuating attribute available to this Sentroller.

Thing > Intangible > StructuredValue > PropertyValue > Attribute A single logical sensor or actuator or combination thereof.

Properties from Attribute isSensor: Boolean: is a value from a sensor isActuator: Boolean: affects a change in an actuator purpose: URL: define the semantic purpose of the Attribute (cf here)

[imadeit-davidjanes]

Someone is proposing at IETF to do something very similar to IOTDB’s iot-purpose vocabulary, sent to schema.org here. Time to get typing again.

[imadeit-davidjanes]

IOTDB can now mute logging

Just do the following:

const iotdb = require("iotdb") const _ = iotdb._; _.logger.mute({ name: "iotdb-upnp" });

You can also mute a particular file's messages (confusingly called module, sorry):

_.logger.mute({ name: "iotdb-upnp", method: "upnp/upnp-device" })

[imadeit-davidjanes]

This:

{    "on": true,    "temperature": "24"    "mode": 8,    "fan": 2,    "timer": false,    "timer_value": "0",    "unitF": false, }

Is exactly what IOTDB solves: we can make a Semantic model of everything in this packet.

[imadeit-davidjanes]

FIWARE Data Models Documentation

These are a number of data models for Smart Cities data, including things like Parking, WeatherStation, AirQuality Station, Street Lighting, Weather, Waste Management

[imadeit-davidjanes]

IOTDB 'use'

IOTDB is designed to be a stand-alone package that you can build IoT projects from. Home☆Star extends IOTDB by adding a management interface and web interface.

However, sometimes it's easier to deploy IOTDB projects without installing Home☆Star. How then to load modules into IOTDB?

Let's say you want to use the WeMo module. Normally with Home☆Star you can just do:

const iotdb = require('iotdb') const hues = iotdb.connect('WeMoSocket')

However, without Home☆Star setting up things this won't automagically work.

To fix this we've introduced use:

const iotdb = require('iotdb') iotdb.use('homestar-wemo') const hues = iotdb.connect('WeMoSocket')

You'll have to $ npm install homestar-wemo but there's no need in this scenario for Home☆Star to set anything up.

[imadeit-davidjanes]

Changes to IOTDB Logging

IOTDB currently use bunyan to handle all of its logging. This is all buried deep within IOTDB so you don't have to worry it.

When our modules want to log, we do something like

const logger = iotdb.logger({ … });

which does all the Bunyan work behind the scenes.

Unfortunately, these leaves us with several problems:

it's really chatty

some people and packages prefer winston

The latest version of IOTDB has solved this.

To turn off all logging (except fatal errors)

const iotdb = require('iotdb') const _ = iotdb._; _.logger.silent()

To selectively shut down logging levels

_.logger.levels({ debug: true, info: true, trace: true, warn: true, error: true, fatal: true, });

To replace the logger altogether, make a function that looks like this:

_.logger.make = function(initd) { return bunyan.createLogger(initd); };

This function is lazy called so as long as you get to it before any logging happens, you should be good.

This has been added in IOTDB version 0.13.8. You can see the logging source code here.