Architecture Diagram

Steward

When the main index.js runs on startup, it starts three modules: utility, database, and steward.

Utility module

On startup, the utility module creates pubsub mailboxes for:

As with any pubsub service, these mailboxes are used when it is "inconvenient" for a publisher to enumerate the list of interested subscribers.

The utility module also houses the logging function, which is a wrapper around winston. The most important aspect of this is the local variable logconfigs which contains the logging configuration for each module.

Finally, there are a small number of convenience routines.

Database module

On startup, the database module creates, if needed, the file db/database.db and initializes it:

Once the database is initialized, the database module_ starts the device module.

Device module

On startup, the device module creates an entry for the root of the actor tree ('steward.actors.device'), which is described in Actors.

Next, the category-specific prototypes are loaded by starting all files in the devices/ directory with a matching name of /^device-.*.js/. In turn, each of these category-specific files starts all files in an appropriately named subdirectory (e.g., devices/device-climate/.

The devicemodule implements a device-generic driver:

In addition, there are a small number of utility functions that can be used by device-specific drivers.

Steward module

On startup, the steward module examines the list of network interfaces on the system, ignoring those that are either local (i.e., the loopback interface) or associated with virtual machines. For each the remaining interfaces, it starts a packet capture session to examine ARP packets and primes the pump by attempting to connect to TCP port 8888 on five unpredictably chosen addresses. (Note that priming the pump is unnecessary when the steward is able to read the kernel's arp table.)

The steward then sets up the infrastructure to report aggregate state information and then re-schedules itself. This is done so the capture sessions can run to determine the MAC address of the machine that the steward is running on. Once that occurs, the steward computes its own UUID and starts the server module. It then loads the pseudo actors (e.g., 'place/1') and begins its observer-perform (or 'activity') loop.

The Observe-Perform Loop

In a sense, this is the heart of the steward. Once a second, the scan function in the steward module is run. This looks through the list of all events known to the steward. There are three possibilities:

Next, the scan function looks through the list of armed activities, and if the event associated with an activity has been observed, then the associated task is marked for subsequent performance. The scan function then looks through the list of all non-conditional events known to the steward and resets their "observed" status.

Then, the scanfunction then looks through the list of all tasks known to the steward, and constructs a list of tasks to be performed. For each task it publishes a request for the task to be performed. NOTE THAT TEMPORAL EVALUATION IS NOT YET IMPLEMENTED

Server module

On startup, the server module listens for http: and wss: traffic on an unused port. (If an HTTP connection does not upgrade to WebSockets, then static files are served from the sandbox/ directory.) The server module then advertises itself using multicast DNS, loads the discovery modules, and then loads the routing modules.

Discovery modules

There are four discovery modules that are started by the server module.

SSDP discovery

This module creates an SSDP instance, both to listen for SSDP announcements and to advertise itself as a basic device on each network interface discovered by the steward module. In addition to listening on port 1900 for multicast traffic, it also listens on an unused port for UPnP notifications. The module also creates a file called sandbox/index.xml that lists the (minimal) UPnP capabilities of the steward.

The device module is informed whenever a new device is discovered via UPnP.

For UPnP-based actors, the module provides routines for roundtrip'ing UPnP traffic and subscribing to notifications.

BLE discovery

This module turns on the system's BLE module and starts scanning. Upon discovering a device, it scans the services and characteristics advertised by the device, then determines the prototype associated with those characteristics, and then informs the device module.

The module's register method is used to associate BLE characteristics with a particular device-specific driver.

TCP port discovery

The module's pairing method is used to associate port numbers (and optionally OUI prefixes) with a callback in a particular device-specific driver. This callback determines whether the device module should be informed.

Every five seconds, the module does a port scan of registered port numbers on IP addresses that have not responded to those port numbers. If a connection is made, then the device-specific callback is invoked.

MAC OUI discovery

The module's pairing method is used to associate OUI prefixes with a callback in a particular device-specific driver. This callback determines whether the device module should be informed.

Whenever the steward module captures an ARP request, it invokes a method in this module to see if either MAC address has not previously been examined and whether the device-specific callback should be invoked.

Thing Sensor Reporting Protocol (TSRP) discovery

This module listens on traffic for UDP port 22602 on multicast address '224.0.9.1' which is where devices report information via the Thing Sensor Reporting Protocol. Upon receipt of a report, the module updates the steward accordingly.

Routing modules

At present, the steward has three API modules.

Console API

Authorized clients connect to the

/console

resource in order to receive logging entries from the steward as well as state updates. When a client first connects to this resource, most actors in the system will present a brief synopsis. Thereafter log entries will be sent to the client, e.g.,

{
  "climate": [
    {
      "date": "2013-06-18T08:12:12.787Z",
      "level": "info",
      "message": "device\/44",
      "meta": {
        "status": "present"
      }
    },
    {
      "date": "2013-06-18T08:12:12.788Z",
      "level": "info",
      "message": "device\/45",
      "meta": {
        "status": "present"
      }
    },
    {
      "date": "2013-06-18T08:12:12.788Z",
      "level": "info",
      "message": "device\/49",
      "meta": {
        "status": "present"
      }
    }
  ]
}

State updates look at little different:

{
  ".updates": [
    {
      "whatami": "/device/lighting/blinkstick/led",
      "whoami": "device/36",
      "name": "Blinkstick #3",
      "status": "on",
      "info":
        { "color":
          { "model": "rgb",
            "rgb": { "r":75, "g":0, "b":130 }
          }
        },
      "updated":1374521033437
    }

    // other state updates, if any, go here ...
  ]
}

As you might expect, any traffic sent from the client is ignored.

Inspection API

Authorized client may connect to the

/

resource in order to inspect available resources and API calls, e.g.,

{
  "requestID": 0,
  "result": {
    "\/console": {

    },
    "\/manage": {
      "\/api\/v1\/activity\/create": {
        "access": "write",
        "required": {
          "uuid": true,
          "name": true,
          "event": "actor",
          "task": "actor"
        },
        "optional": {
          "comments": true,
          "armed": [
            "true",
            "false"
          ]
        },
        "response": {

        },
        "comments": [
          "the uuid is specified as the create suffix",
          "the event actor must resolve to an event or a group of events",
          "the task actor must resolve to an event or a group of tasks"
        ]
      },
    },

    ...

    "\/": {

    }
  }
}

Management API

Authorized clients connect to the

/manage

resource in order to manage devices or activities, events, tasks, and groups.